everythingpossible - Fotolia
Release management best practices for every IT team
No one likes an app that implodes once it reaches production. IT operations teams can save themselves some headaches by implementing release management from the initial design on.
The IT pro's goal is to move code -- whether an infrastructure piece or updated application -- from assurance, staging and assessment to production. That simple move can be a big catch.
Developers build new code in a sandbox and move to production when ready. Horror stories abound about IT projects that require additional resources and licenses in deployment or that simply fail for other reasons. The team did not follow release management best practices, often making assumptions about the steps to get workloads released into production that result in mistakes at the final step.
A lot of focus has been on release management best practices -- and deviation from them -- over the years. Information Technology Infrastructure Library (ITIL), a service management framework, aims to align IT and its services with the need and direction of business. Checks and balances at multiple stages should protect the business from critical issues and unexpected changes and provide full event and problem resolutions. This comprehensive framework truly encompasses and contains many shortfalls of IT for business, and helps to address those gaps. The challenge is all of the checks and balances require resources, addressing the shortfalls requires resources -- it's a common theme with ITIL. To take advantage of what ITIL has to offer requires an investment in resources and staff, and that is something that many businesses have been unwilling or unable to allocate. For many companies, turning highly paid IT staff loose on paperwork, approvals and change orders becomes an expensive, time-consuming proposition. Paperwork isn't as valuable as engineering, IT support or design tasks that require specialized skills and expertise.
Implement release management best practices
Release management is critical, and ITIL does have a nice framework, but in its purist form it is simply too resource heavy for many companies to follow every step. However, release management best practices aren't completely out of reach.
Operations and management should sign off on designs. Engineers and architects can exist in a figurative vacuum, and may not always realize the complexity of their designs. Before spending money or time on a design, operations and appropriate management staff should sign off on the initial whiteboard discussions to ensure the scope and complexity are within reason. Additionally, the management contact should function as the effort's sponsor; the operational contact should be the individual slated as the operational handoff contact.
Outsiders provide the best quality control. Developers who wrote an application or code update cannot be the ones to do a quality assurance check on it. Everything needs a second pair of eyes before it enters production. Another developer or a systems administrator should get involved to make this release management best practice standard. The person creating code is simply too close to it to see any possible issues or conflicts.
Release management requires a release manager. Someone on the operations team should take ownership of new code once it completes development and quality assurance. Consider appointing a designated help desk person or IT administrator for the task.
The release manager must understand what the deployment is, how it should function and what to do if it goes wrong. They also must understand the release cycle into production. Release management best practices include tracking critical usage times, shutdowns and staffing levels and planning the release at an optimal time to create as little production disruption as possible. Document these factors in the application release manual as well.
A contact point in operations is critical for the initial handoff of code onto live infrastructure, as well as for the first 30 days that code lives in production.
Good application deployment manuals are thorough but usable. Follow these tips to create flexible but clear manuals that contribute to release management best practices.
The release is only successful if the customer says it is. The last and most critical piece of the entire process is the customer feedback loop. A production deployment is only successful when you have positive customer feedback. Closing that loop between the customer, operations and development helps to ensure success for the deployment -- and ultimately the business.
Moving any system or application into production is a risk, and failures can kick off crisis mode in operations to correct the issues. The goals of release management best practices are to create a plan that works for your company and minimize risks to production IT environments. While it's not possible to mitigate every unexpected issue, it is possible to reduce many by working with common sense milestones and handoffs. These best practices help developers, managers and operations support avoid tunnel vision when looking at production releases. If you don't have the resources to do a full scale ITIL service management structure, a hybrid approach to production releases will make the most sense.
