I’ve worked in places where software releases can be an event ridden with stress and anxiety. The cause of this stress comes from several sources, such as pressure to meet a release date, or an issue creeping up in production that was not caught during testing. I’d like to share with you a few steps that you can take to ensure that your release process is less stressful and not such a big deal.
Automate your release process!!
The first thing you should do is automate as much of your release process as possible. Every manual step in your release process is an opportunity for somebody to mess it up. I have been this person on at least one occasion and it’s not a great feeling to be the one who messed up a release.
Less documentation
The more automation there is in the release process, the less documentation needs to exist so people know what to do for the release. In an ideal world, documentation for a release consists of one step (“Step one: push the “Release” button!”).
The problem with documentation is that it can go out of date. A teammate of mine who headed our team’s release followed the release checklist to a T, only to be chastised for doing a step that was no longer necessary. But the release checklist wasn’t updated by the people who modified the release process.
Reduction of handoff between groups
When a release process has a lot of manual steps, there are usually a number of people involved with the process. These people can belong to groups like Dev, QA, and Ops. Steps in the release process may dictate that one group has to hand something off to another. For example, Dev might have to hand their release candidate over to Ops so they can install it on the production servers (this should be automated!). This is an example of where things can go wrong. The wrong deployables could be given to Ops, for instance.
Waiting for a group to do their part involves waiting for them to communicate that they have done their part. If a group does not communicate how things are going on their end, it can be frustrating. I’ve waited for Ops to do their part for over an hour, only to have them say “I see an error” in the Slack channel, with no further follow up. “I see an error” is very vague. What kind of error? Is it something that I, a developer, need to investigate? Communication breakdown between groups can be frustrating.
Automate your release process, folks. Continuous Delivery is a great resource for those who want to do this.
Release smaller pieces more often
Releasing a large chunk of functionality can be nerve wracking. Especially if you’re trying to do so close to a release date that you ABSOLUTELY MUST HIT™. With the clock ticking, people are more prone to getting stressed out and making mistakes, both in writing the software and in releasing the software. However, if you release smaller pieces of software more often, you’ll make it easier to idenfity issues and make it possible to get feedback from the work you’ve already done. Some companies like Etsy are able to release multiple times a day!
Smaller problem search space
Releasing smaller pieces of software more often provides a number of benefits. For one, the problem space of new produciton issues caused by a new release is much smaller. Your latest release caused some production issues, but you’re not sure of the exact cause? Sifting through two weeks of new work is a lot easier than sifting through 6 months of new work. Sifting through half a day of work is much easier than two weeks worth of new work. :)
Shipping earlier
Releasing smaller pieces more often gives you the option to let your customers check out what you’ve done so far and provide feedback. If you don’t want to show your customers what you’re doing, you have the option to perform “dark” releases. This can be done by putting code for new features behind a feature flag. The flag is set to false by default until you want to “turn the feature on.” At that point, you flip the flag from false to true and the new functionality is visible. At some point, you probably want to get rid of the feature flag altogether (delete any if(FeatureFlag) then {//blah} statements) and have the code as a normal part of your codebase.
Releasing pieces earlier also makes releasing not that big of a deal. Did something go wrong with the release? No big deal. Just rollback, fix what was wrong, and try again tomorrow. Speaking of rollbacks, it should be trivial to go back to the last ‘good’ state of your application. You should be able to rollback the application and be able to do so in a short amount of time.
Conclusion
By automating your release process, you remove from it the element of human error. By releasing your software often in smaller pieces, your releases become much more manageable and less of a daunting event. These two courses of action will result in you not getting so stressed out about your releases.