This posting, the latest in a series focused on a disciplined agile approach to release management, overviews the activities associated with release management. The Disciplined Agile (DA) toolkit promotes an adaptive, context-sensitive strategy. The framework does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique. In this blog we present the goal diagram for the Release Management process blade and overview its process factors.
The following process goal diagram overviews the potential activities associated with disciplined agile release management.
The process factors that you need to consider for release management are:
- Plan IT release schedule. Your organization’s overall release schedule needs to be planned and communicated. Many organizations have blackout periods where teams are not allowed to deploy into production (for example, many retail organizations will not allow non-critical production releases near the Christmas holidays). There are many strategies that organizations may choose to adopt when it comes to scheduling releases, including release trains, release streams, ad-hoc releases, and release windows.
- Schedule solution release. The release of an individual delivery team’s work needs to be scheduled so that it does not conflict with the releases of other teams who want to deploy into the same operational environment.
- Manage infrastructure configuration. The release management team will work closely with your operations team, in fact they are often members of your operations team, to perform configuration management of your operational environment. To safely deploy into production you must know what is currently in production and how those hardware and software elements depend on each other. The more complex your operational infrastructure, and the more IT delivery teams you have, the more important this process factor becomes.
- Determine production readiness. Part of the release process is to verify that the solution is ready to be deployed and that the stakeholders are ready to have it deployed to them. The bigger and more infrequent your releases, the more this becomes an issue.
- Support delivery teams. The release management team, when a separate one exists, will work closely with the IT delivery teams to help them deploy successfully. This help may take the form of coaching the team on deployment techniques, on planning, and even working with them to automate their deployments. The release management team will often help with deployment testing, the verification after the fact that a deployment was in fact successful.
- Govern releases. Your organization’s overall release efforts should be governed, ideally with the aim to streamline those efforts as much as possible. This governance will include the development of policies and guidelines pertaining to the release process as well as the identification and collection of pertinent metrics.
Release Management and DevOps
Release management is an important part of your Disciplined DevOps strategy. Having said that, many IT departments are still in their early days of adopting a DevOps approach yet still effective release management. The implication is that the way that you approach release management will vary depending on how far down the DevOps adoption path you are. For example, with no DevOps in place at all your release management activities are likely to be performed by a team that is completely separate from your IT delivery teams. When you are in the process of adopting a DevOps mindset release management is likely to be a collaborative effort between the IT delivery teams and the release management team. When you have fully adopted DevOps strategies release management is mostly performed by the delivery teams themselves.