Release Management: Unnecessary evil or Holy Grail?

Release management. Depending on where you sit in an organizational food chain, you might be terrified of these two little words. Maybe you’re dreading just having to deal with what those two words mean for your organization, or maybe you’re just relieved that some sort of organized process is going to be instituted where you are. Maybe you don’t know what it is, but you just want some of it.

So, what is release management?

According to varying sources, Release Management is everything, from just a final and formal support step in a software development lifecycle process, to the second coming of all things software engineering. It is neither of these things.

In a nutshell, release management does four basic things. It:

1. Takes some existing code for a software application or program from somewhere
2. Builds the code into a test environment
3. Facilitates testing the code
4. Puts the code into production

Along the way, a mature release management process will record what happened throughout each of these four steps so a manager can see how each of the events has transpired.

It is important to recognize what these four things show: Release management is an integral step throughout the software development lifecycle. It sounds simple, but these four basic steps are fraught with peril. Each of these steps, depending on how well each is managed, has the potential to fall apart and jeopardize the next one. Release management, at its core, aims to facilitate a process to keep that from happening.

Just to reemphasize: Release management is not just support. While it does have certain support functions, it is not limited by them and begins before production support is ever realized. Release management is not just a final checkpoint, as release management kicks in when code begins to live somewhere bigger than a local development machine.

Why is release management important?

Everyone creating software has some form of release management process, good or bad. It can be as simple as a developer writing some code, compiling it, then releasing it to a computer where it can be accessed without any other controls in place. While this can arguably be unhealthy, it is still a form of a release management.

There is a point to having a governing process over software creation, build, test, and release. It simply revolves around proactive injection of quality into your product. This quality improvement is not just of technical nature, it can even improve a group’s quality of life when it allows reactive changes to become proactive and more predictive. How?

There are at least four ways release management improves software quality, resource leveling and managing, and change forecasting:

• If a change is known during the development phase, it can (should) be recorded.
• As that change stabilizes, it gets tested to ensure the change works as designed. Those results can (should) be recorded.
• After a change is tested and results are recorded, it can be planned and scheduled for release into production. Planning, not reacting, is key. This step:
  • Can (should) involve user and project manager notification of upcoming changes.
  • Allows for any other environmental factors to be discussed (i.e. server patching, electrical outages) prior to a change needing to be released.
  • Gives a release manager the ability to plan resource requirements before the planned change is needed.
• As planned changes are released into production, related changes can be combined and bundled. This helps to minimize the impact on the end users.

At the end of any given release, assuming most of the steps were recorded, a full report of the changes, what they entailed, what testing was done to them, who released them, and when they were released can be provided. This becomes infinitely more important in more strictly audited software environments where an account of changes in production must be fully illustrated. Without a basic release process in place, providing such a record is nearly impossible.

As more changes to production are proactively managed, overall project failure also can be diminished. Staffing and unrealistic schedules are two big reasons projects crash and burn. Having an effective release management process helps projects move through build and test environments to a production environment successfully and in a scheduled, predicted manner. As these activities are recorded and therefore visible, better decision-making can result for future release cycles.

Release management is not a checkpoint, nor is it the end-all, be-all correction to bad development practice when it comes to releasing needed changes into production. I like to think of effective release management as an overall faculty for improving software quality. The better the process governing software changes, the better those changes can be managed. The better changes can be managed, the better quality those changes will have. Quality of software solutions is the end-goal and the real reason release management process exists.