IT Employment

Release Management: Unnecessary evil or Holy Grail?

Release management is 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.

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.

Erica Henson is based in Houston, Texas and has 15 years in the software industry. She has worked in all areas of software development and delivering worldwide solutions. She currently works as a build, integration, and release manager for a Fortune 500 company. You can email Erica at erica.j.henson@gmail.com or catch her on Twitter @ericajanine.

17 comments
ITSM Consultant
ITSM Consultant

For more practical information on ITIL Release Management, visit:itsmspot.blogspot.com.21

tellyround
tellyround

Good article, Erica. You're right that the release management process can be a catalyst for improved software quality. And we've got 3 overlapping terms in play - release, project, and change. I find it helpful to use the term 'change' to refer to the release into production process, i.e. the tail end of the release process. I usually have releases being managed as projects and incorporating project management disciplines, and then the release or project manager having to produce a change request before the release can be implemented into production. The release process itself involves defining, building, testing, and validating the release content. Effective release and change management need to incorporate configuration management, but they're all different things, and all inter-related.

gerard_schmidt
gerard_schmidt

RM doesn't work if you don't have true managment support. In all the organisations I have worked in, most releases have been buggy, unstable and hard to manage - all the while running under the supposed Rm philosiphy. Like TQM - its the ethos and support of the management itself that count. Anything else is just wind.

yodi.collins
yodi.collins

Release management is just a fancy way of saying configuration management or build management. This is not by any means a novel concept; it is, however, a vital process and can in fact amount to the Holy Grail when executed well.

Carlos.Barajas1
Carlos.Barajas1

Hola, great article, could be posted in PDF? Thank you

kdoerner
kdoerner

Erica, you look at release management from a software development point of view. How do you see release management in the context of IT Services (according to ITIL)? I'd be interested to learn your opinion about that. With regards Klaus Doerner

erica.j.henson
erica.j.henson

I completely agree. I have seen where an idea that everyone believes is right just falls apart because the upper echelon didn't buy into it.

erica.j.henson
erica.j.henson

I am not sure I agree with this, mainly because it ignores the actual release-to-production processes that must be considered, especially the part where the release planning and communication is in play. Building changes or configuration of those changes does not mean a release process exists. Just my thoughts...

QAonCall
QAonCall

Since ITIL is about managing change overall, the release management component would be a piece of the larger ITIL strategy. For example, not all ITIL requests would require software changes, and in the same vain, not all software changes would involve 'development'. (OS upgrades, adding new functionality for a COTS application etc) What is important to remember is that the ITIL process would be essentially a wrapper for this component that may have several pieces to it. After this component is executed, the ITIL process would continue with the migration to the end users and notification of resolutions etc. So essentially you would have ITIL process (change requests) represented as follows: #ITIL Process# [Change activity][Release Mgt][Deployment Activity (includes delivery to end users and training updates etc)]#ITIL Process# That model is very simplified; however, it does give a representation of the wrapper nature of the ITIL process as it relates to release mgt (as well as other SDLC disciplines and their associated tasks).

erica.j.henson
erica.j.henson

Good morning, I see that the majority of the process breakdown with regards to Release Management begins with how well development processes and the initial integration of the code changes are managed. I did not go into operational aspects (i.e. the business management coordination), but I believe it is a great follow-up topic.

cwhchen
cwhchen

I fully agree that release management is a key to provide quality products. However the pre-request is to have a mature environment that people understand why you do this. I had experience that people enjoyed simple release because the time required is limited. Of course, the users suffered low quality and need continuous patching after.

morake_elias
morake_elias

Dear sir or madam, I like to make request to you, to send me material on ITIL

cwhchen
cwhchen

In a mature environment I used worked, there are 3 categories of release defined. All are intended to provide quality product. 1. Major release: for main functional changes. It can be once a year or twice a year. 2. Minor release: for minor changes. Normally it's a quarterly release. 3. Emergency release: for bug fixing and security fixing. This is something to be implemented immediately. However the same concept was hard to implement in a pre-mature environment which prefer to have "low cost, quick but dirty solution", sometimes to make several changes to one application in parallel in order to gain market share. Any comments or suggestions to bring release manage to the pre-mature environment?

erica.j.henson
erica.j.henson

In my environment, the release management process (and the change management it entails) helps to structure a more mature environment. It unfortunately is a lot like the tail wagging the dog and is not ideal, but it seems to have focused the development groups and the business users into a schedule. Once the schedule was publicized of "this is when stuff will happen or else" and everyone finished complaining, it was adopted pretty well. I will address this in a follow-up post, but flexibility of the release process is key and must be tailored to the environment it supports. I agree that there should be levels of 'release' that center around critical/break-fix/unscheduled items and those that can be planned a lot better. We do that here and, while the actual technical pieces of the release are pretty much the same, the reporting and discussion surrounding unscheduled vs. scheduled activity is different.

Ron_007
Ron_007

What the article calls "release management" is what I think of as "change management" ("you say potatoe, I say potat"). And yes, proper control of production implementations is a sign of a mature environment. cwhchen, the example you defined is the perfect argument for proper release/change management. Take a little more time time, do it right the first time and move on to the next thing or do it fast and dirty and put up with production outages to fix "minor" errors. Your example is proof of the concept "Pay me a little to do it RIGHT NOW! Pay me a little more to do it properly a little bit later. Or pay me (and many others) a whole bunch later to RE-do it RIGHT". Actually, in the places I have worked, "release management" has implied bundling multiple changes, testing them together and releasing them together. Also implied in that concept is the idea that some changes finished "early" are going to be held back until the rest of the release is ready. The most commonly known example of this type of "release management" is "Microsoft Patch Tuesday" (or Oracle quarterly releases). Personally I disagree with Patch Tuesday for the simple reason that I don't think MS should be delaying releasing security patches that are ready to go. Heck, there is already "bundling" implied in MS Patches. A single MS patch rarely fixes only a single vulnerability. Read the descriptions, almost all of MS patches fix more than one thing. And that is not limited to logically related vulnerabilities. They are like legislation with all sorts unrelated "riders" tacked on. The Patch Tuesday release concept is "better" for corporations who have to be careful about what they implement, in other words they already have release/change management in place. And since they do, they do not need the superfluous change management of Patch Tuesdays. They can simply implement a little self control and aggregate individual patches within their change management system. The thing is, for the small business and personal user it is better if they install patches as they come available, to limit the amount of time they are exposed to vulnerabilities

Editor's Picks