Deployment Runbook: 8 Reasons Why You Still Need Them

Identifying the Risk

Runbooks: The Challenge in the Vision

  1. Planning Complexities. The interdependencies of the enterprise environment mean that when a tier one application is updated, those interdependent tier two applications often need to be updated as well. Then, because the tier two applications are updated, the tier three applications may also need to be updated, and so forth. Managing the madness of these interdependencies is not for the faint of heart and can take weeks and months of planning.
  2. Collaboration. When dealing with a network of development teams, contractors, stakeholders, and impacted customer groups, the challenge is to coordinate the planning of each of the different entities. The scheduling and sequencing of the deployment plan needs to make sense, not only for the enterprise but also for the individual teams. This can be a monumental task when you factor in that each team has a completely different set of deployment tasks, interdependencies, requirements and procedures that only that one team knows about. After all, for most of these large organizations, it’s not like you can just get everyone with a role in deployment into a conference room to work it out in an hour or two.
  3. Approvals and Governance. The complexities of system interdependence and the high-risk nature of enterprise environments and operations mean that there are typically a lot of cross-functional stakeholders that participate in the oversight to ensure system and operational stability. All this means that there is a never-ending list of people that participate in the governance and whose approvals are needed before any deployment can move forward. The challenge is to get these approvals in place before the newly developed code becomes obsolete. That means that each of these individuals needs to understand at least the basics of the software development lifecycle, including the checks, gates and general methodology being used by their respective development teams. It seems like all too often we catch ourselves saying things like, “I’m sorry, but the developers won’t be shipping code directly into production. There’s a process that needs to be followed.”
  4. Scheduling. Scheduling for a single development team can be enough of a challenge. Now compound that by the dozens of development teams and potentially hundreds of applications that not only have their own deployment to manage but also need to interweave and coordinate their deployment schedules to ensure that they don’t bring the systems and general operations to a screeching halt. Then, as if that wasn’t challenging enough, this all has to be coordinated and executed as quickly as possible to minimize blackout periods and system downtime.
  5. Orchestrating. The conductor of an orchestra has the benefit of working with each of the sections of the orchestra individually for days or weeks before bringing them together to practice their ensemble, only to practice several more times before a live performance. Deployment managers have no such luxury. Because it takes so much time and money to organize and orchestrate a rehearsal deployment with each of the various participants, they typically will get only one shot to execute the cutover; with the high-stakes objective being that their performance has to be absolutely flawless the first time. System crashes, extended downtime, production-side issue resolution, and deployment reversals are the things that nightmares are made of.
  6. Failure Remediation Planning. If a deployment goes sideways and creates problems of various levels of severity in the production environment, what then? Can it be backed out? Can the previous release of code be re-installed? What does that plan look like? This is where risk mitigation experts go bonkers trying to calculate impact and recovery scenarios.
  7. Executing. With a nervous gulp and a leap of faith, you press the button to kick off the deployment plan execution. Will everything go as planned? What if a critical step was left out? What if something just doesn’t work as expected. How will your teams communicate the completion of one milestone, and the beginning of work on the next? How can you track the status of where things are at? How would you know if there was an issue or delay, and how would you coordinate the change in the schedule with the rest of the impacted teams? Then, as if those questions weren’t bad enough, what if that one senior executive happens to stop by in the middle of the deployment and asks those seemingly simple questions: “What’s the status of the deployment?” or “How much longer will it take?” Would it be possible to accurately track deployment status and answer those questions?
  8. Audits. With so much at risk with these large-scale deployments, there are often high standards of regulatory compliance that need to be met and tracked to ensure that system protocols are followed. But in order to have reliable audit trails, the data being tracked needs to be 100 percent accurate and complete. It also needs to be in a format that minimizes human error and the possibility of tampering. The challenge is that if everything is tracked on a spreadsheet, SharePoint or Word document, how reliable can those audit trails really be?

The Enterprise Runbook Solution

Plutora Deployment Plan Library



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store



Learn how to improve the speed, quality, and visibility of your software delivery.