One of the questions I used to get asked all the time as a consultant was how to get started with Release Management. Most organisations start with Change Management and then as they mature; look to add additional governance and control with Release Management.
Here are some areas to focus on when looking at ways to formalise your Release Management process:
- Release Planning
- Design & Build
- Communication and training
- Distribution & installation
- Early life support
- Review & close
Release Management Policy
A solid policy is one of the most aspects of a good Release Management process. Put simply, your policy is a list of “thou shalts” and “thou shalt nots” regarding the Release process. No matter who the customer is; whenever I create a Release Management policy, I ensure the following three things are addressed:
- Definition of a Release
- Release schedule
Let’s start with the basics. ITIL terms a Release as “One or more changes to an IT service that are built, tested and deployed together. A single release may include changes to hardware, software, documentation, processes and other components.” In practice, every organisation will have a slightly different criteria for selecting the Release route. Some organisations have very defined release criteria, conversely, I’ve worked with organisations where anything touching the code of a transactional website was classed as a Release, everything else was a Change. Whatever your setup, I’d recommend a simple matrix that guides people as to which cycle to follow.
Scheduling needs to be addressed as part of the policy. How many releases do you need to have? Some organisations go for monthly or quarterly Release cycles; at the other end of the scale you have Amazon who deploy a new software release every 11.6 seconds. Make sure timescales are set in your policy and that it ties in with the related Change Management policy.
Appropriate levels of governance must be in place to support the Release Management process. The policy should set out what Releases can simply be approved at CAB and what Releases need a higher level of approval eg from a Project or a Release Board.
Make sure that the content and scheduling of each release is agreed early on; so regular meetings with both development teams and business representatives is a must. Make sure the Release schedule (documented in your policy) is combined with the Change Schedule. The easiest way to do this is to raise a Change for each Release and then link the information; that way it shows up on the schedule, CAB are aware of the timings and because the Change record contains a link to the Release documentation there’s no duplication of effort.
Effective Release planning means that downtime and inconvenience to the business is minimised as multiple Changes are packaged into one Release. This approach also saves money as avoiding multiple downtime windows means less overtime, external support call outs and paying out for service credits.
Design & Build
Carry out a review of your supporting players. Work with Configuration Management to ensure that the software in your Definitive Media Library (DML – or DSL; Definitive Software Library if you’re old school) and Hardware Store (HS) are consistent with the Configuration Management System (CMS). Wow – just reading back that sentence; that’s a lot of ITIL terminology – here’s a quick beginners guide if you’ve just read this and wanted to panic and / or cry:
DML: Definitive Media Library – one or more locations in which the definitive, authorised and licenced versions of all software Configuration Items (CIs) are stored. In practice; The DML is your application library or server; it’s there to make sure only authorised and safe software is installed across your company.
HS: Hardware Store – secure storage of definitive hardware spare components and assemblies. In practice this is your store of spare PCs and laptops for spares and “hot swaps”.
CMDB / CMS: A database used to store configuration records throughout their lifecycle. The configuration management system maintains one or more configuration management databases, and each database stores attributes of configuration items, and relationships with other configuration items. If that’s still making your head hurt, here’s a quick diagram to help explain:
Diagram 1: Scary Terminology Explained
Now that we’ve got the technology squared away; by checking that software from DML and hardware from DHS are consistent with CMS you may find unused, “spare” software licences and you may find hardware that can be used in production.
Look at the environments (if any) you have for testing Release content. If more are needed but money is tight could the cost be shared with other departments initially? A training environment could also double as a pre production environment. Tight management can reduce the need for multiple environments; someone (usually the Release or Test Manager) looks after who is using the environments using a “booking out” process and ensures that the environment is refreshed on a pre agreed regular basis.
Come back soon for Part 2 of this article; where I’ll give further tips on building a Release Management process.