Wave Goodbye to Release Nights – InApps Technology 2022

As Marie Kondo taught us in her popular show “Tidying Up With Marie Kondo,” everyone needs to assess their possessions, keep the things that speak to their hearts, and discard the things that no longer spark joy. So, while you toss out that dodgeball participation trophy from middle school, think about how you might apply this same lesson to your software delivery process.

For many developers, the answer is simple: it’s time to say goodbye to the release night.

While it may be a stretch to claim release nights ever brought us joy, there was a time when they served a purpose and had value. It used to be standard practice for software development teams to set a specific date on which they released software to customers. Because of the early stages of software development, organizations had no choice but to gather all the new code and ritualistically release at one time.

By replacing release nights with feature flags, you now have the freedom to release new code as quick and as often as you want.

For companies that practiced waterfall processes, release nights were very important. Release managers would spend days or even weeks organizing and planning these special nights, while the QA team continued to scour the code to find any remaining bugs. Once the big night finally arrived, teams weren’t necessarily filled with excitement and pride to show the world what they had been working on. Instead, they felt hesitant and doubtful about the release. Once the code went live, the team would have to spend hours anxiously testing the critical flows in production to make sure nothing broke.

Release nights are also stressful in part because developers need to know that features are working in production before releasing them to users. They no longer have the bandwidth to spend countless hours triaging unforeseen production issues deep into the night. There’s nothing more discouraging than testing a new feature in staging, building confidence that the feature is working, reviewing all requirements, and then seeing everything fall apart on the release night because the feature doesn’t work in production.

Release nights also have a major flaw when it comes to data: the data that’s in the staging environment rarely matches the data in a production environment. This means you will more than likely end up with contradicting test results. It’s counterintuitive to put so much pressure on the development team to make a new feature perfect in staging if it’s bound to fail in production.

Feature Flags as a Replacement

Now that it’s been decided to discard release nights, what can you use in its place to spark joy in the software delivery process? The answer is to test the code in production with feature flags before releasing it to the entire user base. This way, you can decouple code deployment from feature release and clearly specify who sees which features at runtime. It also allows you to safely test the code and be confident that, even if you do find a bug, it will not affect the user base.

By replacing release nights with feature flags, you now have the freedom to release new code as quick and as often as you want. Literally, with a click of a button, you have the power to turn on a feature when it’s ready to test and turn it off when the test is complete, or when that feature is causing a negative user experience.

With feature flags as the main tool for releasing new code, you’re now free to do canary releases — also called percentage rollouts — which are impossible to do on release nights. Canary releases give the team flexibility to incrementally roll out a feature to a specific group of users before it’s available to the whole user base. These kinds of releases are perfect for configuration changes or product changes of a sensitive nature.

Just like businesses moved on from using outdated technologies like typewriters and faxes, it’s time to move on from release nights, embrace feature flags and start enjoying the code release process again.

Featured image via Pixabay.