Boy was I naïve.  I don't know if that one-man band is still in business or not, but soon after I left the company, they dropped his software like a hot potato.  After getting involved with software development, I found out that this particular problem occurs quite often and in organizations that are much larger and more reputable.  I learned how easily old source files could creep back into the latest build, especially in undisciplined organizations where configuration management is mostly ignored or even nonexistent.  I also discovered that a solid build and release process combined with the proper use of a good Software Configuration Management tool could readily solve these problems.  It's not brain surgery, but ignoring good release management can result in the premature death of a product or even a whole software organization.

What are the key components of a good release policy?  I might not be the most knowledgeable person on the subject, but the projects I have worked on have had a clean build record when it comes to delivering what's expected.  So far, I've never been haunted by the specter of a previously solved problem (knock on simulated wood grain).

A release is basically when a software build is completed by development and the built objects and documentation (i.e., the deliverables) get passed on to parties outside of development.  As I cover the aspects of a release process, I would like to make it clear that by a release, I am referring to an internal release from development to the testing organization and finally a release to the end user. This is probably the most important and fundamental aspect of a good release process.  Don't hand anything to your customers until it's fully tested.  As obvious as this sounds, this is often overlooked, especially when the project is running behind schedule. Some organizations let their customers do the testing rather than deliver something late.  This happens so often that most people who are know anything about software won't touch an initial release, even products from well-known software companies.  Let it sit on the market a few months until they work out the major bugs, right?  Wait until a couple of service packs are out before mangling your system with the latest and greatest.  Testing is an entire topic in itself, but it is an essential part of the release process.

It's very difficult to control code that's lying around in different directories on a server somewhere, or even worse, on the developer's work stations.  Even a project with one developer should use a configuration management tool to keep things straight.  The tool you use should have the ability to clearly and easily create a baseline of code. A baseline is a collection of file versions that make up a build.  This baseline should be locked down so that either it can't change, or changes to it are traceable and limited to users with administrative privileges.  Once the baseline is created, you should be able to recreate the same build from that baseline even if new file versions have been added.  It is also important to have the ability to create changes from a baseline that preserve the original baseline, but do not interfere with the latest development efforts.  You should be able to merge these changes back into the latest code if desired.  Finally, a good tool should also post the current market value of your favorite stocks (current within 20 minutes, that is).

Create a documented process that defines how your builds and releases are done.  The act of putting this in writing will help the organization to design and agree on a process that makes sense and meets the goals of the project.  It can also be very useful if the build person flies off to Aruba and never returns.  Once the procedure is written, a person who is not familiar with the details of the build process should test it by following the steps to create an actual build.  This dry run is often ignored, but it's important because it helps to ensure that the process is clear and repeatable.

For each release, the baseline should include more than just source code.  You should include, the Release Notes, all design documentation, project documentation (such as your build procedure) and anything else that might be delivered with the release (such as user manuals).  All this information should be stored in your SCM tool under version control if possible.  At the very least, enough items should be included to carry on the project if you lost everything else but the baseline.  If it's all under source control, it can be easily included in the baseline.

The development environment should be defined in your build document, and should include things like the proper platform version (i.e., the operating system), compiler version, and the version of any IDE (Integrated Development Environment) tools used. It should also include a procedure on how these tools are installed.  I have seen how using different installation options of a compiler can impact the final executable of a build. As an SCM coordinator, I inspect the developer's machines during major baseline audits to make sure they are following the environment requirements.  Using an OS with a different service pack than everyone else probably won't have any noticeable effects, but why take the chance?  At the very least, you should keep a list of any machines that are different.

Automate your build process as much as possible using scripts and other tools.  The automation process should be documented in your build document so everyone understands what is going on, but the more automation you have, the less chance there is for human error.  It also frees up the builder's time so they can delete mortgage and credit ads from their email inbox.

Official builds should be executed on a clean build machine.  Each release build should be done on a designated build machine, NOT one of the developer's machines.  The build should take place in a location that starts out empty (i.e., no lingering files from a previous build), then get populated with the code that is designated by the baseline in your SCM tool. Doing a clean build will find any missing files or improper file versions. Especially early on in a project, some developers forget to put all their files back into the database.  If the build works, your baseline has just passed its first test.  Some organizations run nightly builds to make sure that the files in the database can be built.  This approach depends on many factors, such as the size and nature of your project, but I have never needed to use it. We run our builds live and in person.  When actually doing the builds, playing some inspirational, heart-thumping music can help things go smoothly.  I prefer movie theme music such as Braveheart and Gladiator.  This did get me in trouble once, however, when I got a little too excited and ran a broad sword through my monitor.

And they'll be carrying pitchforks and torches, chanting,  "Where's the release! Where's the release!"  How to you control the distribution of a release once it's built? Should the actual deliverables be stored under source control?  I personally believe this is a good policy.  You spent all this time and effort controlling what went into the build, why not control what you built?  It might eat up a little disk space, but disk space is cheap.  Keeping the deliverables under source control allows you to control access, and therefore who can get at the deliverables.  Just as important, it controls who can't get at the deliverables.  If a build fails a test, you don't have to worry about recalling it, because the tester is the only one who has it.  Storing the deliverables also provides something to compare with if you go back and rebuild the baseline at some point.  We use a utility that creates a CRC (Cyclic Redundancy Check) value on the data portion of the executable file which is a great way to verify the reproduction of a build.  It also allows to the tester to verify what version of the binary they are working with.  Storing the binaries can also come in handy if you use an installation program such as InstallShield.  You can include the deliverables in the baseline and then further control exactly what your installation program is including when it creates a setup program.

For any release that goes to the customer, its a good idea to perform a baseline audit on the baseline used for the release. A baseline audit is conducted to ensure that the build can be recreated and that it is actually delivering what was planned.  In addition, the audit verifies what changes have occurred since the last baseline audit in order to prevent any surprise changes from slipping in.  After the full set of tests have been passed and the baseline audit is complete, then the built objects can be released to the customer. The actual release could be the act of placing it onto physical media such as a CD for delivery or by placing it on a shared server location for internal customers.  However you do it, the release takes place when the deliverables leave the safe womb of configuration control and go out into the cold world on their own, wherever that might be.

Having a solid build and release procedure is a fundamental part in producing quality software.  If you or your management feel that configuration management is a waste of time, this is one area you should not ignore.  Neglecting your release process can have serious consequences.  Following the simple steps above will help a great deal in knowing what it is that you are distributing.  At least you should be able to sleep at night knowing that no one should find any old problems that have been fixed.  Then all you have to worry about are all the problems that your testing missed.  Don't worry, your customers will find those.

Trackback(0)

TrackBack URI for this entry

Comments (3)

Subscribe to this comment's feed

Stephen Griffiths said:

	... Thank you for this article. The hardest stage of learning any process is at the beginning - you're document has started to get me think how to Release Services faster, better and more efficiently.
	report abuse vote down vote up

April 22, 2010
Votes: +0

Dave Van Dyke said:

	... very good article. A good approach to help explain the process to our CIO and Business sponsor on how important release management is.................. thanks, dv
	report abuse vote down vote up

April 09, 2010
Votes: +0

Shivabc said:

	... very good article on the basics of build and release management. Easy to undertand for a non technical manager.
	report abuse vote down vote up

November 09, 2006
Votes: +0

Write comment