Release Management

Release Management refers to management of the release cycle within a software project, which itself is when the software engineers provide a uniquely identified set of files for others to use. The others may be their department at work, their classmates at university, or The World. The set of files (perhaps a single file) constitute the software release. Managing the release means the software release manager knows:

• What went into it
• Where it went
• Why it went there
• How to deal with it when bugs are reported

Building software is the generic term applied to the compilation or aggregation of sources into a usable utility or application. Sources needn't be compiled (built) in the classic sense, which relies upon a compiler linking files together; modern systems may consist entirely of interpreted source files (such as those for Perl or PHP). Still, putting everything together in a usable format may be considered "building".

The larger and more complex the software project becomes, the greater the need for an extremely well-managed Build and Release function.

Several features are characteristic of the Build and Release process. The most common are use of overnight builds, normalized build numbering, high degrees of automation, scheduling and reuse, use of notification, metadata capture and storage, and implementation of a project portal or viewer.

Overnight builds

This is a basic function that accomplishes two primary objectives:

1. It establishes the code-wise integration of the project.
2. It immediately alerts you to code-wise disintegration.

These may sound like the same thing, but they aren't. The software engineer expects to see code-wise integration as the project matures; the overnight build confirms he/she has it. He/she does not expect to see code-wise disintegration (the "it built yesterday, but not today" problem), and thus wants to know immediately when it is encountered. Engineers should be the only ones who see legitimate code-wise disintegration. They should catch it during their unit tests and fix it prior to committing to the project. By running overnight builds, the engineer has no more than 24 hours of source code changes to review and/or back out if the build breaks.

Overnight builds also give the QA department something against which to execute test cases and to target for specific bug regressions. Overnight builds help the software project team stay on schedule by reducing the amount of time required to resolve real code integration issues.

Competent Build Numbering

When the team builds the project every night (or continuously), the need exists for a build numbering scheme along with rules for build publication. Build publication rules refer to what builds get published for QA consumption and the target for that publication. A special directory structure on a specific machine is sufficient for this purpose. Project team members determine this up front, start using it, and do not change it over the course of the project. Throughout the entire project cycle, any interested party can quickly look at any build. The numbering scheme must be flexible enough to provide specific, built-in meaning in the number itself. For example:

foobar20110

This build "number" allows for visible identification of its contents. Anyone on the project may look at this number and know the build contains:

• Foobar
• Version 2 source
• Internal build # 110

The release manager and the build engineer must establish a numbering scheme that is easily incremented via automated build scripts.

Automation

Human error is an acceptable risk on trivial, performed-once operations such as writing an email message. Human error is not an acceptable risk when building and releasing your software. If the steps for the procedure may be entered into the keyboard, the procedure can probably be automated. Well designed automation modules may be reused elsewhere in the project, as well as in other separate projects.

Auto-generated Build Numbers

Embedding build numbers in the source code is common. This allows a user of the software application to open an "About" or "Version" screen and receive information about the application's version and build number. This is useful in support and upgrade situations. The user sees something like "Version 12.3 Build 1234". Those strings came from the source code, often from hand-editing prior to that build. That process - the generation of the build number and its insertion into the source code - may be automated. The release engineer must develop a script or other piece of automation code that reads the master build number file, increments and caches it, opens the source file with the build and version string in it, greps or searches for the string in the file, does a replace, closes the file, commits it, and tags it. The build number is now in the source code prior to build process.

Scheduling

Well run release management is similar to other aspects of the software development project in that it is highly dependent upon the completion of scheduled tasks. Builds are the single most important scheduled task that produces artifacts for the release management process. The release manager must ensure that the build schedule is predictable and maintained. One mechanism for achieving is through use of job schedulers like cron or at. This allows the release manager to establish a schedule for builds, publications and deployments that is automatically enforced.

Reuse

Reuse of automation modules allows the release manager to compress more activity into available time, increasing productivity without a corresponding increase in hands-on work. Examples of automation modules that may be reused within and across projects include those for email notification, source code checkout and checkin, file copying, and deployment.

Notification

It is advantageous for the release engineer to be notified of the success or failure of any given release or build procedure. Automatic notification from within the release process provides this. At the conclusion of a build, a simple "Build OK" message may be sent to the project team. The message may include a hyper-link to a log file with details and the team benefits from quickly receiving status. Similarly, when the build is broken, the notification immediately alerts the team with a "Build Broken" message that can be investigated.

Project Portal

Web servers can be easily deployed and have come into popular use as a presentation manager for build and release metadata. Projects members and other interested parties may obtain project status, with the proper level of detail for their purposes, by viewing a page in their web browser. Several well developed tools exist for this purpose, including Anthill, CruiseControl, and BuildMaster.

Database storage

Building and releasing software produces significant metadata, both in volume and importance. The release manager is interested in

• build and release trends, which provide insight into improving future release cycles
• audit logs which provide historical records on the migration of specific software changes.

Examples of build metadata include:

• Build number
• Build date
• Build version
• Source code label or tag used
• Overnight build (Y/N)
• QA tested (Y/N)
• QA test results (Pass/Fail)
• Location of full logs

The release manager may use any RDBMS; several are freely available and can be quickly set up on a low-cost computer running any of the free operating systems. Existing build logs may be imported for historical data housing. Build metadata may vary from project to project, and it is generally accepted that there is a practical limit to the amount of metadata to be stored. For example, even though the release manager may capture and store data like "Number of binary files included in the build", it must be considered whether the data is meaningful. Simply because a piece of data is available, it doesn't automatically become information.