What kinds of tools are required to do effective release management?
Of all the projects I get asked to be involved in these days, release management comes at the top of the list. It has become a major focus area for many organizations, and this is being driven by three main factors:
- Increasing ITIL awareness, which is resulting in the operational area demanding to have a greater say over the deployment of code into the production environment.
- Agile development methods driving up the velocity and frequency of the release management process.
- Business pressure to meet time-to-market demands placed upon the organization.
And all of these drivers are demanding great visibility, more direct control and end-to-end collaboration.
As a result, many organizations are driving deep into release management and trying to work out how they can increase throughput, increase reliability, reduce risk, reduce errors and do all this with the same resources.
The solutions we are seeing are falling into a pattern:
- Detailed review of the current processes, practices and procedures
- Elimination of spreadsheets for tracking and replacing with online, workflow-based tracking
- Up-skilling existing staff
- Implementation of KPI and SLA monitoring through automation
- Implementation of automated test tools
- Implementation of automated deployment tools
So, once again, the unsurprising answer appears to be automation of the process. Throughout the SDLC we are seeing increasing use of process automation to link the silos of development together. The most critical boundary between silos has been, for decades, the one between development and operations. Through the simple use of process automation tools, we are now able to see dramatic improvements in release management in all sizes of organization.
What, then, are the must-haves in a technology-based, modern release management system?
- Visibility: We need to know real-time, what the status of the releases are. We need a release calendar that lets us see when things are happening so we can balance the release workload.
- Control: Every stakeholder must be able to give their electronic signature to approve, and it needs to be reportable and auditable.
- Reporting: We need to track our performance against our KPI’s and SLA’s, and we need early warning when we are out of range on these numbers.
- Vault: This should contain the master code that is destined for production: no more developers each having their own path to production, no more developers with root access.
- Deployment automation: We need a repeatable and predictable technology that consistently deploys our code and backs it out automatically if things go wrong.
In short, we need a lot. It starts with the process. It moves to automation. And it ends with binding in tools.
This was first published in September 2011