You Shouldn't Have to be Sherlock Holmes to be a Release Manager

Because uptime is so important, release management must be treated as a business-critical function, not an afterthought.

Effective release management brings speed, stability and auditability to your system, three things your company needs to keep the doors of the business open to customers. For a release to work as planned, you know what is changing in your system, how the changes you're releasing will affect your system, and whether the release has been properly tested and approved for production.

You shouldn't have to be a detective to figure this out.

Many times, you have to do real detective work to ensure you have all the files that were changed to create the new release, and that you have all the right versions of these files, with all the dependencies accounted for and tested.

With CM, you can fire Sherlock and get back to managing releases.

As a release manager, it's really not your job to do all of the impact analysis and configuration control associated with a release. This information should have been gathered during the development and testing phases of the project, by the people who are doing the work to describe, design, develop, test or approve the change. They could have done it if they had used a CM system that integrates its version control, change request and issue management functions, and which labels, identifies, tracks and appropriately associates versions, revisions, issues and related files, so that all information critical to a correct release is at your fingertips when you need it.

For even more effectiveness, you should be able to manage releases by their baselines. Integrated change management using baselines makes it easier to get repeatable results and avoid system downtime. If you ever need to issue that particular release again, the baseline makes it possible. The baseline is in essence a "bill of materials" listing of everything that went into your release, so you don't have to hunt and guess and find all of the correct objects.

Moreover, should you ever be audited, having baselines and (the audit trails that got you to that baseline), will make certification compliance a relative snap, because you will have already captured every aspect of any change to the system. 

It is hard to know what has changed if you don't know where you started.

Knowing where you started and where you ended in a release, and documenting it, establishes a baseline. Once this baseline is created, everything associated with a particular release is there, frozen in time.

A proper baseline will include all of your requirements specifications, design documents, prototypes, source code, object code, executables, build scripts, and a snapshot of the system file structure. Any digital asset, no matter how insignificant, must be included as part of the baseline. Once established, a baseline becomes an object in the system, with its own lifecycle, permanently captured at the point in time it was created.

When you work with baselines, you only have to answer one question, "What are we deploying?"

Instead of reinventing the wheel (gathering files manually, trying to ensure that you have the right version of each, verifying these versions were tested...), there is a better way.  It's called Change-Driven Release Management.

In change-driven release management, a separate "Change Document" describing each proposed change is created at the beginning of the change implementation process. The Change Document traces subtasks that may have been assigned to individual teams or developers, who make made their changes to various files and program elements in association to the change document that they were assigned. This creates a direct relationship between the change request, the process of making the change, and the actual changes to the source in response to the Change Document. Once such a permanent relationship is set between a specific change request and the response(s) to it, you can move the entire Change Document through a lifecycle, just like any other object in a release. Once that Change Document and its related modifications are tested and approved, a new modified baseline, reflecting all the changes, and only those changes, is created.

Now it is possible to stage a release with one command and KNOW it's right, the first time, every time.

Now a new baseline exists, made of only those changes that were related to the change document and approved by testing. The detective work that many of us endure to ensure the integrity of our production releases (and which takes so much of our time) is no longer necessary. All that remains is the act of issuing the command to release the now-completed object into the target environment. To do that, it is necessary to filter out all the components in the baseline that, while critical as baseline components, are not going to be a part of our production release. In most environments all we need to deploy are the production executables and any related end-user documentation.

This is the point in the process where the business aspects of the release management function become critical.

In order to be successful the release manager must decide: what is the impact of this release on the existing systems; what systems, departments, and individuals will be impacted and need to be notified; and when the best time to roll it out will be, from a business sense (Is it the end of a quarter? Will it interrupt our business processes?). As well, it must also be considered from a time-of-day and day-of-the-week perspective based on system use, security, and other environmental factors.

Congratulations. You are no longer Sherlock but a vital contributor to business operations.

Now the release management task is transformed from doing detective work to find all of the potentially thousands of files that may have been changed and need to be included, into only being concerned with higher-level strategic aspects of the job, including business and technology impact and timing as they relate to new deployment.

Because that is what release management is supposed to be about.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment