Release Management in a Nutshell

Release Management is an interesting topic.  It is a subject that has many different interpretations depending on the person and indeed the organisation that is implementing it.  The industry-standard definition (as prescribed by ITIL) of Release Management has the following goals:

• Planning the rollout of the software
• Designing and implementing procedures for the distribution and installation of changes to IT systems
• Effectively communicating and managing expectations of the customer during the planning and rollout of new releases
• Controlling the distribution and installation of changes to IT system

Source: Wikipedia

Looking at each of these in further detail gives some additional facets of Release Management that will contribute to the success of implementations.

Planning

As part of the planning process, it is too easy to focus solely on the project's implementation.  However, this could potential miss out an external project dependency.  While a Project Manager may be tracking direct project dependencies, what about those further down the implementation line? A Release Manager worth their salt will be undertaking this tracking, being aware of all relevant projects and their respective statuses.

Procedures

Procedures for implementing releases should be relatively straightforward.  Ideally, the procedures should be:

• Repeatable: if you have a system in its operational life, you want the release procedures to repeatable so that the implementation team become familiar and proficient with them.
• Segregated: strictly speaking, segregation is not necessary in a non-regulated environment but it is extremely good practice (i.e. as good as mandatory) that your implementation team are not your development team.  Why? Imagine the scenario: a project is implementing for the first time, as part of the check-outs, an issue is identified and one of the implementation team (who is one of the developers) thinks to themselves "I can fix this" and makes the requisite changes.  Unless the developer is disciplined, there is the risk the changes are not reflected in the source code control tool where the release was published from.  Do this too many times, and the production, test and development environments will diverge, exposing the organisation to significant risk.  Implementation teams should be drawn either from the production support team or ideally completely independent of the team's management chain.
• Testable: for simple implementations in a mature environment, this is probably not a necessary.  However for complex releases, testing the entire release process will be beneficial.  This may be a "talk through, walk through", where all implementation team members, the Project Manager and the Release Manager will work through each step of the implementation plan or (if the luxury of time and environments is available), then performing a dress rehearsal will verify the implementation steps, giving comfort before the actual "big bang".  Whether a dress rehearsal or a talk through, walk through is used, it is important to document any findings and experiences, while making any changes to the implementation as necessary.  It sounds obvious, but it does get forgotten!

A Release Manager is ultimately responsible for these procedures and may well be asked by Project Managers to help with the implementation plans. 

Communications
Release Management communications can be thought of as in three phases:

• Pre-Implementation: typical examples of pre-implementation communications are:
• Release testing status (especially for releases with a number of integrated projects)
• Implementation plans along with checkpoints and contacts
• Go/no-go decisions
• Implementation: during the release, the implementation teams will need to be keeping in contact with one another, handing over to the next step, etc.  For an implementation spanning a number of hours, checkpoint reports to key stakeholders will give them the warm, comfortable feeling that everything is proceeding smoothly.  If it is not, don't hide it - come clean and let stakeholders know how it is being addressed.
• Post-Implementation: Following a successful release, typical comms would be:
• Release Notes, detailing the changes introduced
• Observations about the release, for example hotfixes that had to be applied to get it working, any implementation team issues, etc
• A "Thank you" to the implementation team.  This is very important if the release has been conducted over unsociable hours - it recognises the efforts of everyone and costs nobody a thing.

Note: this list is not exhaustive. Each of these will be the responsibility of the Release Manager to either produce themselves or ensure is produced; hopefully they are very chatty!  I will go into each of these types of communications in detail later.

Installation

I have touched on installation in the procedures section above.  As before, the installation process should be repeatable, segregated and testable.  Wherever possible, an organisation should use appropriate automated deployment tools - this limits the opportunities for incorrect builds to be deployed or artefacts to be missed.  The Release Manager can be considered to be the custodian of the build and release tools.  His success is linked intrinsically to how well these perform.

Coming soon: putting this into practice and Release Management in an Agile environment