The Secret to Success: Detailed Release Planning & Preparation

When your company conducts a high-risk migration to a new platform or when you are faced with a challenge to preserve uptime on a critical day, you plan for every possible contingency and you look at every single facet of your enterprise to identify the weakest link. You prepare. Release planning requires much of the same.

Whether you are a media company preparing for the Super Bowl or an e-commerce company preparing for a record-breaking Cyber Monday your challenge is the same. You prepare for months for a big day, your teams are aligned and at high alert should something go awry. You’ve accounted for every possible contingency… or have you? That’s the million (or billion) dollar question.

Some companies fail to prepare, and every year we see a few companies fall by the wayside because they failed to plan and prepare properly for a big day. You can bet that the retrospective meetings and reorganizations at companies that fail during critical business events are intense. Release planning is a high stakes game and the pressure to maintain uptime for critical systems is intense. A seemingly small oversight in a system that causes failure on the wrong day can end careers and send whole departments walking.

Uptime and availability are the focus across industries increasingly moving toward online and self-service products. What are the secrets to maintaining availability and preparing for high-stakes events?

Release Planning for High-risk Deployments, Every Day

You prepare for high-risk days and high-profile releases by committing your organization to a rigorous planning and preparation process that treats every day as a high-risk day. You change the culture of your software organization such that every release creates a feedback loop that makes the next release more reliable and more stable. Tapping into that loop and leveraging it to refine your processes lays at the heart of great release planning.

If you have a year to prepare for a high-stakes event, start a continuous process improvement initiative today by using tools like Plutora to put a plan around a release. Don’t wait until a month before the big day. Identify and address risks as they are identified 365 days a year. The biggest software risk is change and your release process is your chance to define a structure to mitigate these risks.

Specific Steps Toward Reliable, Repeatable Releases

When you perform a release, treat them all with the same level of attention. Here are some of the steps you can start taking today to achieve more reliable and repeatable releases.

• Audit What You're ReleasingDon’t just sit back and passively accept, integrate, and release software. As a release manager, you need to understand the changes involved in any single release. What systems are affected by a release? What are the code changes required of proper release planning?

  • Plan for Release FailureRelease managers often assume that a release will succeed the first time, and with high-risk systems this is often a rarity. A release can cause unanticipated problems in unrelated systems. There can be several reasons why operations may want to roll a release back to a previous state. Avoid the temptation to take shortcuts with your release planning.If you're thinking about submitting release plans that don’t account for the possibility that a release may fail to deploy properly or that someone may encounter problems after it has been deployed, reconsider. Software breaks in unanticipated ways and it is your job to know how to react appropriately.

  • Plan for ContingenciesThis is different from planning for a release failure. When I say “contingencies” I’m talking about alternative ways to deploy software in response to anticipated and unanticipated events. When you deploy software to production make sure that all critical systems incorporate switches that let you enable and disable features.You can deploy your newfangled bank account management system, but if back-end services start having problems you’ll want to give your system operators a chance to switch off a feature should a database of a backend service fail.

  • Understand Your ArchitectureIf you work at a large enough company you’ll understand that release planning and management often turn into a group of non-developers blindly following process. This is a mistake. Your release engineering teams and you as a release manager should have a working knowledge of the architecture and a familiarity with the underlying codebase.You need to understand the weakest links in your architecture and you need to understand how your architecture is changing over time. If you don’t understand your software architecture you shouldn’t be supporting that particular software system. Know the software you support.

  • Have a Plan for Production SupportAll too often teams will release software into the wild without understanding production support requirements. If a system has problems in production you can see entire development teams suddenly consumed by late night support calls and a constant barrage of incidents that need to be managed.

    Instead of being surprised by production support requirements incorporate production support into your release planning. Identify resources that need to be available to support production and factor those resources into the long-term plan.

    Practice all of these steps for all of your releases no matter how small. Accompany your releases with a detailed plan (hopefully you’ll be using Plutora so this should be easy.)

Stand Up a New Structure with Plutora

Software doesn’t make itself. It requires active planning and coordination and Plutora was designed to make it easier for large organizations to get a handle on the risks associated with releasing software at scale. If you deal with high-risk software deployments supporting mission-critical systems start using Plutora for every release and lay the foundation for future success.