How to improve release management on the road to DevOps
Release management issues provide much of the impetus for adopting DevOps practices, both in terms of release quality and release frequency, but the required cultural changes in terms of alignment, communication, and automation can be daunting to consider. Getting buy-in across the organization can be difficult for anyone who isn't in senior management, but that doesn't mean you need to sit around waiting for your executive staff to kick into action. You can incrementally adopt DevOps practices around release management to improve the quality and frequency of your releases as a step toward a less-siloed and more fully integrated organization. Even better, as you incrementally adopt these practices, the resulting improvements will help build the business case for wider change across the organization. Release management is central to DevOps. For many companies, it's literally the first time that developers and operations staff come into contact, as the applications developers build are deployed on the infrastructure that operations owns. Even if production releases are the first time that developers and operations folk interact on a project, there are achievable steps you can take in an ops team to significantly improve release management. This article about the Navy Federal Credit Union does a good job of identifying the small steps you can take:
- Put controls in place to manage code changes. Refusing to make ad-hoc changes requested by the business and implemented haphazardly, Navy Federal locked down a structured process for code changes using change management tickets in a centralized repository.
- Develop a business case for code changes. For each change requested, a line of business manager had to answer this question: “What is the impact on the business if this change is or is not implemented?”
- Allow for concurrent development. Holding up development everywhere to clear resources for one project never achieves the business-technology alignment you need. Have the courage to manage concurrent development on projects with a true business case.
- Do user acceptance testing in a pre-production environment. A software release should be considered as vital to your organization’s continued functioning as a fire drill. Navy Federal didn’t mess around – they had 70 employees, split between IT and business, run through the entire process of rolling out the software.
- Plan for rollback – and pray it doesn’t happen. The best results come from preparing for the worst. Navy Federal captured an image of the previous configuration and rehearsed how they would roll back to that configuration, even though it would mean changes to millions of database tables.