QA tagging

A QA tag is a construct that I invented over a period of time to deal with another concept called slushing. Slushing is to refreeze an intermediate "QA release". Conceptually, you freeze your code, then thaw it slightly to make a change, refreezing the code with the new change (bug fix during QA), repeat each time there is a QA iteration. At the end of QA testing, the QA tag is used to make the release tag.

The QA tag is a label (or tag) that breaks the typical definition of a label - it repeatedly gets changed, much like a branch would.

In Subversion, I create a new peer directory to the standard "branches", "tags", "trunk" directories called "qa". This directory holds the QA tags. The QA tags are copied from trunk as the release tag would have. Changes are merged as needed. When QA approves the product for release, the release engineer will make the release tag from the QA tag.

This has the advantage that development can continue without directly affecting the QA engineer and selective revisions can be merged into the QA tag as needed (not taking HEAD every time).

Types of files to be released

One issue that I have seen come up again and again in badly conceived projects is the mixing of files that should have been properly partitioned when the distributions were created. One very simple example is that log files are created in the application's root directory. This makes it more difficult for various utilities and system maintenance routines to operate as well as for upgrades within the release engineering framework.

I have divided files in the application into four possible types:

• program - binary executables, shell scripts and library files. A library file is code that is being used by another program, but is not executed directory.
  
• configuration - files that define values specific to this installation, e.g. db source, appl dir, peer hosts, etc.
  
• persistent - files that would need to survive upgrades and/or backups, e.g. databases
  
• transient - files that are created for temporary use, e.g. log files, caches
  

Each of these types of files should be separated into different directory trees and should not be mixed. With proper design, this should be easy to achieve.

Program and configuration files could be set to read-only by the install program; configuration files changed to read-write as needed. The directories for the persistent and transient files should be read-write for the owner of the application and any other application that needs access.

With this simple separation, upgrades and upgrade programs can be made much more easily. Backups can be tailored as needed. And the application's release structure is similar to its memory structure: program code separated from data, separated from heap, separated from kernel, etc.