Every software developer and engineer who has released software onto the Internet has gone through some kind of release management cycle, whether formalized or not. Previously at Colony West, our release management was entirely informal – actually more or less disorganized.

For the longest time, I didn’t use a source control system. About four years ago I started using Subversion, and it’s companion Windows program Tortoise, and I won’t part with it for anything else. I love using it, and after using it, I can no longer imagine not using it, and I couldn’t see how I was able to actually develop software without it.

Release management obviously involves the source control system, so what does the release cycle here at Colony West involve? I’ll use the release cycle for the Trade Profiteer as the example of what I do. Now how I release software may differ from what you require, and will likely vary between projects.

New Release Branch

The first step in the release cycle is to create a new release branch in the repository. This step may or may not be optional. That will depend on the project itself. During the Trade Profiteer’s beta release cycle, this step was considered optional, but became mandatory with the first release. Keeping a separate release branch allows you to target fixes for that particular version, while also making sure to keep any fixes updated in the main source trunk.

Release test builds

When the decision is made to create a new release, final test builds are made to ensure the current source state will build without errors. Once this is verified, scripts are executed to update version numbers within various files in the source tree with a test build executed to ensure everything still builds clean.

A test installer is also built at this time. The installer is tested on multiple operating systems running through virtual machines as both upgrade installations and clean installations. Any installation issues are corrected and changes made to correct issues checked into the repository.

If the installer runs clean on all supported operating systems, the changed files containing the new version numbers are checked into the repository.

Tagging the release

Anyone who has used a source control system should be familiar with tagging. Subversion makes revision tagging easy. For those not familiar with tagging, I highly recommend reading the section in the Subversion manual on branching and tagging.

After everything is checked in, the new revision is tagged within the repository with the release version number (major, minor, and build) as the tag name. This tag ensures that the source is readily accessible should I need it down the road to troubleshoot a reported issue.

Release build

After everything is tagged, the tag is checked out of the repository into a new folder for a release build. Final release builds are performed for the executable and installer and the installer may be packaged into a compressed file.

Preparing the web site

There are multiple steps here. Obviously the first step is uploading the packaged installer to the web site and making it available in the download repository. That part is easy. Once uploaded to the web site, it is available immediately.

Along with uploading the file to the repository, other files are shifted around. Previous releases are moved to their appropriate folders on the repository so they are not immediately visible, but still available if anyone is interested.

The Colony West web site contains a version management system that is used to track version numbers easily. The Trade Profiteer queries this system when it checks for a new version, so we add a new entry into this system to reflect the new version. When the Trade Profiteer queries the system, it will see the new version and will alert the user to the new release.

With everything uploaded to and entered into the web site, the release cycle is now formally complete. However there are still a couple informal details left.

Publishing details

Informally, now we need to alert other communities to the new version’s availability as well as providing details as to what has changed in the new version. This occurs through this blog, which will always be the primary source of news information for this company, but also through other venues. For example, with the Trade Profiteer, I will also post updates to the Puzzle Pirates forum.

Concluding…

Well that’s pretty much what goes on right now. Since the Trade Profiteer is a small, independent application, this way of managing our release cycle is reasonable. As the Trade Profiteer grows in complexity, or more software is released, the release process may need to be modified, but for now things are working well.

One thing that will certainly complicate the release process will be the upcoming addition of globalization. There are two international oceans on Puzzle Pirates. As those oceans were designed to be populated and navigated by native German and Spanish speakers, though an English interface option is available, it doesn’t seem fair having support for Opal and Jade, respectively, without having a native German and Spanish interface.

Including globalization will complicate the release process a little, but it will likely more complicate the testing… We shall see.

If you have any questions on the release process here at Colony West, feel free to drop me a line and I’ll be happy to clarify anything.