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, that 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.

So what 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: so that every stakeholder can give their electronic signature to approve and it needs to be reportable and auditable.
• Reporting: 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: containing the master code that is destined for production: no more developer’s each with their own path to production, no more developers with /root access.
• Deployment automation: a repeatable and predictable technology that consistently deploys our code and backs it out automatically too 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.