Release Processes

At various points in the software development lifecycle it is deemed necessary to release a version of software. This may be for testing within the organization or outside of it (internal release or external release), or because the software is ready (final release). Large intervals between releases will result in less time used up for releases and more time for development. The release process should be as automated as possible to reduce this lost time. Smaller intervals between releases will result in better communication and feedback between developers and the release stakeholders. A balance between these two should be reached and an appropriate release interval should be agreed on for any given project. This document presents a set of requirements that must be met by a release and describes a release process that is intended to meet the requirements in conjunction with a versioning policy and a CM tool.

Release Requirements

Following is a list of requirements that must be met by each release.

1. Each release must be uniquely and easily identifiable with respect to older and future releases.
2. All sources (including code, resources, external libraries, etc) that go into a release are safely marked and stored, and the release can be reproduced from them. This is so that both a) when bugs arise, they may be investigated and solved with respect o the code that the bug was discovered in and b) releases may be made based on old versions of the software.
3. The release that (or at the least, the source of) a released artefact can be easily identified. This is so that both mismatches that may accidental occur on a target system may be identified and to enable the correct version of software to be examined and debugged when investigating a bug.
4. The changes that have been made since the last release can be identified. This is to help testers identify the areas of the system where testing should have a higher priority.
5. Future releases can be made based on old release with minor changes only.

In order to achieve these requirements the following needs emerge.

1. A Software Configuration Management (or Source Control) tool and usage guidelines to manage changing source code.
2. A Versioning Policy for the software produced.
3. A process for releasing software that relates the CM tool, the versioning policy and the steps needed to perform a build so that the release may meet the above requirements.

Release Process

The following diagram shows a release process aimed at meeting the previous requirements in conjunction with a CM tool and versioning policy. Each step in the process is described next.
Following are descriptions of each of the stages in the release process.

Retrieve Build Source

All the files that are needed in order to perform a build must be retried to insure that they are all up to date.

Build Code

Build all code that needs building. If the code can’t be build, the release process cannot continue. If the release is intended for eventual use outside the organization, then it can be build without debug information (release build) and with optimizations enabled. If the release is intended for testing within the organization, then it may be build with debug information to assist debugging and testing.

Compile Release Notes

Use comments from the CM tool to build a set of release notes that describe what has changed since the last release. These notes are intended for use buy testers to identify what areas of the software must have higher priority in terms of testing than others. These notes may also eventually be used to inform clients of changes made since the last version they have.

Move compiled artefacts to setup source folder

It is assumed that the setup project for takes its source folder (or folders). The compiled output must be moved into the source folder for the setup project.

Configure

Any configuration in terms of tracing etc must be performed here. For example , if the release if intended for eventual use outside the organization, then tracing must be removed or lowered so that it does not cause problems with disk usage etc on client machines.

Obfuscate

If the release is intended for eventual use outside the operation it should be obfuscated to prevent it being disassembled.

Build Setup

The setup project must be built. The output of this build will eventually be released.

Mark/ Tag/ Backup Source

Mark, tag, or backup (according to CM tool) the source that was used to produce the build.

Increase Versions

Increase versions of artifacts and the setup project in accordance with the versioning policy being used.

Commit New Versions

Commit new versions to the CM tool to prevent any future versions having the same version number as the one that will be released.

Release

Release the build setup by placing it in a known location with its version clearly visible and inform all the relevant people of the new release location.