Best practice concepts are far from revolutionary. In fact, they permeate almost all aspects of our lives. Although they're not considered hard-and-fast rules, there's no doubting they're the guidelines to follow. After all, there are countless ways of baking a cake, but the likelihood is Duff Goldman's recipe is going to yield the best results. Why? Because it's tried and tested, written, rewritten, practiced, honed and perfected. It has built upon foundations laid by others and then refined. The same goes for release management best practices.
Like any process, release management has evolved over time. It's matured. There's now a whole host of software available, which seeks to manage and automate the release process. As a consequence, what was once considered "best practice" is now outdated, and far from optimal. The release process used to be near-enough entirely manual. Managers would spend their days making batch files, compiling checklists, running manual builds and configuring .ZIP files in order to deploy. As you can imagine, if a step were to go wrong... oi vey.
Although the means to an end have changed, the goal of any IT professional remains more or less the same and can be succinctly summed up: to move code from dev, test or staging to production. Yet, in reality, it's never as simple as it sounds. Unfortunately, unlike baking, there aren't hosts of recipe books to choose from. There's guidance to be found, but it's more abstract than whether you should add a pinch of salt here or a dash of lemon there. But these guidelines should form the foundations of release management best practices.
Teams who fail to follow these suggestions are likely to run into difficulties.
Collaboration Is King
Crucially, release management processes should never be established in isolation. They are critical to business strategy, objectives and governance. As such, everyone impacted must be in agreement on how they are implemented.
The notion of collaboration is a fundamental aspect of the DevOps mantra. DevOps seeks to introduce agility but is dependent upon complete control of the release process, inter-team communication, and collaboration. If the handoffs between development teams and operations aren't efficient and effective, they'll fail. These failures could result in incidents affecting release to production, which in turn could adversely affect revenue.
These issues are compounded by the fact that most IT teams use their own release management tools. This means there's often a lack of visibility between teams and that they continue to effectively work in silos. Ops are often unaware of the changes dev make to application code, and dev are frequently oblivious to the operational knowledge base.
A big cultural shift must be made to fully embrace DevOps and release management best practices, and this shift won't be without challenges. Teams will have gravitated toward certain tools and the existing processes will have become embedded within departments.
Luckily, understanding release management best practices isn't as daunting as it sounds. You simply need to take a step back from your current position, survey the landscape and consider a few key points.
Release Management Best Practices in 6 Steps
1. Name Your Leader
Communication is fundamental, but you still need someone to spearhead your efforts, a release management 'leader'. This can be anyone within the company, as long as they are able to successfully balance the needs of dev and ops. They must have the full support of senior executives, a thorough understanding of your SDLC and your organization's risk tolerance.
2. Define Success
Understanding the metrics and objectives of your release management process is key. Defining clear goals will help developers and operations better understand their shared objectives, so they can pull in the right direction.
Want an additional tip? Start at the end and work backward.
3. Define Processes
Define workflows, the flow of information and gates that will be utilized along the way. Ensure you cover all bases. For example, what happens when disaster strikes and you need to make a quick change? Have you thought about how you will deal with such an event, as well as major updates?
When releasing, who needs to be involved in the approval process? Ensure only vital team members are included, otherwise you will needlessly slow down your release cycle.
4. Control
Ensuring everything's in hand is crucial. This means all content involved in each release: artifacts as well as source code. Automation should be applied as much as possible to ensure consistency and eliminate errors from creeping into production.
5. Support
Only once the above have been clearly defined and approved by all affected parties should you consider your supporting infrastructure. The tools to support your release management are key and major investments. Serious time should be invested in researching vendors and their solutions before committing to anything.
6. Govern
Governance for release management needs to be implemented: but only once everything is in order can a change advisory board (CAB) be truly effective. CABs need accurate, up-to-date information, controlled environments and fluid release calendars. Implementing the preceding five steps should enable you to provide all that.
