Release Engineering Best Practices
Good
build teams know that stewarding the production build process, is
only the beginning the of job. The real question is what
happens
after a build is done. How
are builds tracked? How do you track what was released? How do you
escrow your environment?
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, tracking which bugfix is in which copy of
the two versioned release is difficult. Understanding what the
differences exist between identical versions only adds to the
difficulty. Establishing the understanding the each build has its
own build number, and hence own version eliminates this entire can
of worms.
The
Build Process is Your Friend
As a given all source code is committed to a repository, 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:
[ReleaseData]
version = 1.0.0.1234
date = 2008/13/05 15:56
repository =
http://svn.mycompany.com/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 (interally) 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.
- Tag the build, if your build process doesn’t automatically do so.
- Create a separate release tag, for release tracking in particular.
- Check out a full copy of the sources, and compress them into a single file
- Create a single file containing build outputs, installers, libraries, etc.
- Archive any and all tools or files used from a network share.
- Checksum the outputs of steps 3, 4 and 5, storing them for later.
- Create snapshots of all physical or virtual machines used to build the software.
- Write everything to tape, keeping copies both locally and offsite.
- Test a restore from tape, and attempt to build the software