Plutora Blog - Deployment Management, Release Management
Even with Automation You Still Need a Deployment RunbookReading time 5 minutes
When you read about DevOps in the technical press you come away with the idea that infrastructure automation has solved the problem of complex releases.
These images of success are backed up by vendor assertions that businesses are no longer burdened by complex releases spanning multiple teams. We’re done. Just start using tools like Puppet and Chef, sit back, and enjoy the automation. All we needed were the right tools, and now that we have them, we’ve de-risked software releases and automated everything.
If only that were the case across most enterprises. It isn’t. DevOps is successful at the team level, but large enterprise releases are still full of risk. The trick is knowing how to track releases across multiple teams and provide individual teams with a smooth framework for cross-department collaboration. This is exactly what Plutora’s Deployment Manager does.
Most of the DevOps stories we’ve seen successfully implemented have been at the team level. One application development group, or one department has successfully stood up automation and, in isolation; these teams have been able to reach that ideal state of effortless, daily deployment. When a release process involves multiple teams and systems that span departments, this is when you require another level of sophistication.
Anticipating Release Risk
Most organizations tend to have that major, epic release process once or twice a year. These are the releases that replace multiple, major systems in an architecture at once. Maybe you are launching a new set of services for an e-Commerce site or you are moving a business to a new CRM system. Whatever your release challenge, there are some releases that call for fine-grained orchestration of high-risk activities across teams.
When you approach one of these mega-release events this is when you will require teams to detail the process they are going to use to mitigate risk during a release. This isn’t a simple, weekly release process, this is the kind of event that requires planning, several meetings to assess risk, and sign-off from the business. Everyone needs to be informed of the risks involved, and everyone needs to be given ample time to independently assess risk.
In this scenarios even the most automation process still needs to be documented, and individual teams need to understand the roles played by both environment management and release management as they instruct individual teams to coordinate against a master, shared schedule. This is not the sort of process you want to manage with an ad-hoc spreadsheet; instead, you’ll want to stand up Plutora and use the Plutora Deployment Manager as the tool to track runbooks across systems and teams. With Plutora you can ask your projects to consolidate release plans in a single tool and keep this tool updated as a release progresses.
Measuring Delay with Deployment Runbook
Another important aspect of releases at scale is the concept of ergonomics and efficiency. In any large organization it isn’t enough to just deliver software. When you have hundreds of people coordinating together to complete a complex process you need to have a tool at the ready that can track how much time people are spending on the various aspects of a release process.
Think of it this way – if you are a startup with a release team or one or two, it’ll be easy to identify inefficiencies and problems. Risks will make themselves known quickly and your team will be able to react accordingly because everyone is in the same room. Scale that process across three continents and every time zone on the Earth and you might be looking at an unanticipated delay keeping globally-distributed teams up all hours just to address a problem with a database or a system.
When a release is global and when your teams are very large, a simple delay can cause a cascading failure that will affect uptime. This is why you need to measure your historical releases to identify sources of unanticipated delay and to constantly refine your approach to releases. In other words, you still need a runbook especially when you have releases managed by hundreds of operations and development professionals.
Taking the Next Step: Cross-department Automation
In 2015, many complex systems are automated, but we’ve yet to see large enterprises automate across multiple departments. This is primarily because the focus of DevOps has been on self-contained systems. As developers primarily drive DevOps the movement has focused on systems that developers understand end-to-end.
As we transition DevOps to the enterprise – as we map the team-level success to these larger projects and enterprise that still have largely manual deployment stories this is where the opportunity for cross-department automation will yield the most benefits. Before an organization can do this they need to record what their deployment process is… in detail.
Plutora is that first step in the right direction. When you use Plutora Deployment Manager to start keeping track of your deployments you are setting the stage for continuous process improvement, and you are ultimately laying the foundation for an initiative to automate your deployments across the enterprise.