Release Engineering Best Practices

Never Version Twice
The most important best practice is to never version twice. That means that two builds of x.y.z.a can never be produced. Producing multiple builds with the same version, makes release tracking quite difficult. Tags start to make less sense and tracking which bugfix is in which copy of the two versioned releases is difficult. Understanding what differences exist between near identical versions only adds to the difficulty. Establishing the understanding that each build has its own build number, and hence constitutes a new version, eliminates this entire can of worms.

The Build Process is Your Friend
As a given, all source code is committed to a repository and every build comes from a specific revision, changeset, or tag. Similarly, every build has a build number. Every build, we generate a VERSION or meta information file. This file always contains the repository path, revision, version number, and date. The format I favour is an ini file, as below:

version = 1.0.0.1234

date = 2008/13/05 15:56

repository = .../svn/Repository

revision = 12345

From a tracking perspective, it's relatively easy to create a web page, or other tracking tool to display release data. The build process does your work for you!

Tracking Releases
Organizations frequently spread releases (or builds) across multiple destination machines, never collecting everything in one place. Unfortunately, this makes release tracking more difficult. If every customer release sits in a single tree, the version file method described above, becomes even more powerful. The simple act of moving software into the release tree, means that a record exists of what was released, and when. Sharing this information in an (internally) public web page will dramatically reduce the amount of time spent answering the age old question, " When did we release
version x, and what was in it?" .

Escrowing for Safety
The biggest issue post-release is what to do with release sources. How do you ensure that you can always reproduce the release? How do you ensure that a build doesn't need to be reproduced?

This is where best effort becomes a living concept. Scripting the process below helps solve the above problems, at least to a reasonable best effort.

1. Tag the build, if your build process doesn't automatically do so.
2. Create a separate "release tag," for release tracking in particular.
3. Check out a full copy of the sources, and compress them into a single file.
4. Create a single file containing build outputs, installers, libraries, etc.
5. Archive any and all tools or files used from a network share.
6. Checksum the outputs of steps 3, 4 and 5, storing them for later.
7. Create snapshots of all physical or virtual machines used to build the software.
8. Write everything to backup media, keeping copies both locally and offsite.
9. Test a restore from backup, and attempt to build the software.