Home > Work > Release Management Lessons Learned – benefits of a working process

Release Management Lessons Learned – benefits of a working process

Some more lessons learned from my stint as release manager, this time looking at the benefits of having a well-defined but flexible process, which made sure that problems were surfaced early.

Our release process sought to verify that everything was in a fit stage to proceed, and to make sure that we didn’t forget anything important. My notes are drawn from a test release late in 2009, and highlight a few of the things that we found in a normal “problem-free” release.

The most important thing about this release is that despite being a major release, no significant bugs were found, so no subsequent defect fix releases were needed. The development teams learned from my constant harrying of them through the year; this was the first time we managed it during my year doing the QA role.

Benefit of getting it right first time

Quite apart from saving the overhead of fixing, testing, repackaging and retesting a bug fix release, delivering a high quality release through test at the first attempt gave us other very clear and tangible benefits. Firstly, we didn’t have to worry about code branches (the development team had already started work on the next release). Secondly, I was able to produce a draft Production Release note for this release in time for User Acceptance Testing. Because I didn’t have to merge the content of two or more test releases, manual errors were eliminated – I usually missed something out each time. UAT was then carried out against the Production release note, and also failed to find any defects.

A working process doing its job

Having a rigorous process proved itself time and again by identifying mistakes and omissions at an early stage. I’ve picked the following examples of relatively small things that were caught early, which contributed to what was ultimately a successful release. Of course, I also found quite a lot of small QA issues that are of no interest to anyone outside the team.

One very valuable check was to audit all changes in the source code repository since the last release, to make sure both that all expected changes were found, and no items were omitted. On this occasion the development team had made a minor change to a component and checked it back in to the repository, but hadn’t itemised it in the release note. The source control log correctly identified the defect number, which was in the release’s scope. On investigation I found a reference to this particular code item buried deep in the detail of the defect, and added it.

Our test team used to share the builds around between them, so each time the instructions were seen by a relatively fresh pair of eyes. As a result we usually found any obvious errors in the release note before the end users followed them at UAT. We also, as usual, found minor defects and suggested improvements to the documentation relating to changes made some time ago that had not been spotted at the time. Normally, by the time they reached the users they were pretty accurate.

Another issue that arose that hadn’t been considered before was how best to implement security privileges to the new functions added at the release. Following go-live, the business users took responsibility for maintaining system access via a set of UI screens, and we stopped updating our build scripts. This release added so much new functionality at once that doing it manually would have been too onerous. We realised that instead of simply listing new functions, we had to write a script to add them in dynamically. We recorded the business’s initial access requirements in a defect, which allowed us to test the script in the usual way. Including a check in the process made sure we addressed this before it was too late.

A final small issue that came to light was that one of the migration SQL scripts didn’t run from the ‘@’ prompt in SQL Plus. This identified that our development tools didn’t place the same restrictions on the code as the production environment, and led to a slight tightening of unit test procedure.

Nothing dramatic here, but hopefully a few illustrations of things that would have been annoying if we’d only uncovered them at the last minute, the difference between a smooth release and a fraught one.


From a completely different perspective, a review of an Agile project from David Larsen.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: