Planning a software release can be stressful task. With so many divisions of a company converging together at a singular point, it’s important to have a plan in place to mitigate any issues before they spiral into failure. The task of organizing a software release plan is normally designated to a company’s release engineering team, but the responsibility can also be assigned to a CTO, project manager, or software engineers. Regardless of your position, we at Release[Board] hope this article will guide you through the release planning process and enable you to design a successful release process for your company.
Before creating a release plan for an individual release, it’s important for your company or team to create an overall set of guidelines for releasing your software product. How frequently do you plan on releasing your software? Twice a year? Daily? It’s important to create a set of guidelines for the frequency you plan on releasing your product to ensure that all members of your team have the same expectations. An environment where software is released in an agile, iterative approach with soft, flexible release deadlines is very different from an all or nothing waterfall approach where there are hard deadlines that a team must meet.
The next step once release frequency has been agreed upon within your company is to create a software release template that will be a set of guidelines for release engineers, devops, and software developers to follow during each individual release. Releasing software to production can be an incredibly stressful task for teams. By creating strict, meaningful guidelines team stress can be reduced by the consistency and structure of a defined software release process.
One of the first tasks that should be part of your release process is determining which new features should be part of an upcoming software release. This task requires your company’s release engineer or planner to meet with project managers, marketing, and even sales to determine a group of features that meets your customers’ and your company’s requirements. If this step is skipped, a chance to market or sell to your customers that a highly requested feature has been released to them is completely lost.
After a group of features has been grouped as a release, it is important to meet with engineering and management to determine when these features can be realistically released to production. From these discussions, a release date and time can be set. Once a release date is set, the release time should be communicated to the entire company.
I have seen first hand the danger in skipping this step. At a prior position I held, I worked as a software engineer developing a new product that would replace the company’s existing flagship software product upon release. The deployment of the software to production occurred on a Sunday and went smoothly. The next day customer service started to receive a flood of calls starting at 5am with support requests about the new software. The customer service department was completely bewildered. They had never been told about our huge release that had been planned for months and worst of all had no idea how to use the newly released software. This lack of communication around a software release cost the company the trust of several customers and left the customer service department incredibly frustrated. As your direct line to customers, it is important to train your customer service department on any new releases and keep them informed about release schedules so they can best help your customers.
After communicating and agreeing upon a release date, it is important to meet with your engineering team and determine all of the tasks that need to be done on release day. Usually these tasks are things like deploying code to production, putting up a maintenance page, taking down a maintenance page, running database backups, having the QA team do acceptance testing on the newly released production code, and making database changes. Additionally, it is important to determine if these tasks will require “downtime”. “Downtime” means that your software product will be unusable to customers while portions of the release are in progress. To mitigate customer support requests, it’s common to put up a “maintenance” page when downtime occurs. This page explains to customers that your site is temporarily offline.
Once these release tasks are defined, your next priority should be to assign these tasks to different members of your company and plan the order in which to execute them. You should create a release timeline that lists the tasks, task owner, and the expected length of each task to plan out the release. This timeline will server as the guideline for a release and reduce any possible confusion around task ownership and release execution. In a prior position I held, our software team did a software release while the marketing team was doing a webinar. The scheduling conflict was missed by the company because we didn’t account for the length of pre-release tasks in our release schedule. This resulted in the site going offline in the middle of a demo to brand new customers. To avoid this embarrassing situation, your release timeline should be visible internally to your entire company to avoid any sources of misinformation.
One of the last steps when creating a release plan is also one of the most important. When creating a release plan, it is important to create a contingency plan in case anything goes wrong. If the newly released software is giving customers errors, you should have a defined plan in place ahead of time to rollback a release. A contingency plan usually consists of notes about the worst case scenario for a release along with steps to rollback the release. By having a contingency plan for your software release, you eliminate many possible stressors for your team. If something goes wrong, there is no confusion. Your team will know exactly what to do.
Finally, once a release and all release tasks are successfully completed, you should notify your whole company internally. Estimated times can be unreliable and giving a definitive result to the status of your release will ensure everyone is on the same page.
After reading this article, you should have the knowledge required to implement a release plan for your company. If you would like any additional advice or desire a critique of your release plan, feel free to click on our support link even if you aren’t a customer. We’re happy to help other companies and teams create a successful software release plan. I encourage you to join our free public beta of Release[Board] when you create your next release plan. Release[Board] will make it easier for you to follow the release planning guidelines of this article and bring even greater transparency to your software release process.