4 minute read
RIP Release Night
Today we remember the release night.
We gather (virtually) today not to mourn the death of the release night, but to celebrate the inception of its replacement. Release nights were once a standard for software development teams to have a set date to release their software to their customers. In the old days, companies didn’t have a choice but to gather all their new code and ritualistically release it on one specific day. Now, things are different.
Release night, in companies that practice waterfall processes, you were quite prominent. Usually, the release manager would spend days, or even weeks, organizing and planning you, while the QA team continued to find those last few bugs. When the time finally came for you, confidence on our team was usually not high because no one knew for sure what would happen once we deployed the new code to production. Our product team would then have to spend countless anxiety-inducing hours testing the critical flows in production after we released to make sure nothing broke.
You caused us lots of stress, release night. We need to know that our features are working in production before we release them to our users. The countless hours of triaging unforeseen production issues with you are over. It is so disheartening to test our features in staging, build our confidence that the feature is working, review all requirements, and then wait for you to happen only to show us that the feature doesn’t work in production. The data that’s in staging does not match the data that is in production, therefore the tests run in both places are bound to give different test results. What’s the point of putting so much pressure on ourselves to make it perfect in staging if it’s just going to fail in production? It makes our whole team stressed, and we don’t appreciate the pressure of one night to determine the success of our features.
Feature Flags: Our Newly Beloved
Release night, you once had your purpose, but now, we use feature flags to test our code in production before releasing to our entire user base. With feature flags, we can decouple code deployment from feature release. With this new practice, we can clearly specify who sees which features at runtime. This gives our team the ability to safely test our code knowing that whatever bugs we find will not impact our user base. Release night, you just don’t keep us safe like feature flags do.
Release night, you were too slow and didn’t happen often enough. With feature flags, we can release a new feature any time we want to with the click of a button. Feature flags come with an easy on/off toggle that lets anyone on the team adjust user experience. This means we don’t need a release manager anymore, nor do we need to wait a month, or multiple months for you – we can release new features whenever we want.
We also now have the opportunity to do canary releases, or percentage rollouts, which are impossible with you. Percentage rollouts allow our team to incrementally roll out a feature to a small subset of users before we roll it out to our entire user base. This is great for configuration changes, and more sensitive product changes. We did not have this flexibility with you.
We no longer need you, release night. You can rest easy knowing that although you were once the standard for software delivery practices, you are now a thing of the past, and feature flags have replaced you.
Long live continuous delivery and feature flags.
Learn More About Release Processes and Best Practices
- Read our Co-Founder and CTO’s On a Mission to Kill Release Nights
- Read more about feature flags in our free Feature Flag Best Practices eBook
- Watch this video on Feature Flag Best Practices
- Read about best practices of Testing in Production
To stay up to date on all of our content, be sure to follow us on Twitter @splitsoftware, and subscribe to our YouTube channel!