Releasing software today has many options, they vary in risk profile, and in the way they are performed. In this article we will do a summary of the main options available today. This is a valuable tool chest to have in mind in your road to better releases, less risk, and more peace of mind, in short in your road to DevOps.
High Risk – Big Bang Release
These are usually done or one or twice a year. They are high risk, high profile efforts, that may have a big positive, or a big negative consequence for a company. They also have set deadlines, and can be quite stressful for the whole organization.
Why do businesses still do this? Mainly because they lead to massive events, which can attract a lot of attention. Let’s detail the reasons why we still have Big Bang releases:
- Marketing can build a case for the new release, and highlight the best features they have to offer for current customers, or for people considering their product.
- Journalists and influencers are also invited to the release event. It’s the best time for the company to address their questions, and explain in detail what is being released, including new products.
- Customers usually enjoy participating in the event via news, live video feeds, and social media. Buzz is built in the market.
For these reasons many large companies like Apple, Google and Amazon still have some Big Bang events in a year, usually one per product category.
Personally I advice most companies to minimize these events, or avoid them if possible, however sometimes they are needed. Fortunately, all deployment options mentioned below can be used to reduce the risk of a big bang event. Use them.
Medium Risk – Beta Opt-In Release
Live in production, but done in public inviting users to participate in a public trial.
Apple frequently does this with the help of their registered developers to test pre-release software either for the iPhone or the Mac. Microsoft has also taken a similar approach with Dot Net core, releasing many beta versions to willing testers.
Low Risk – A/B Testing Releases
Live in production, but only for a percentage of users who are unaware they are part of a test. Marketing is usually behind the testing, working along with one or more software engineering areas.
This is typically done only for online web products, and it’s a widespread practice to improve the effectiveness of a website. On the web you never know if you are running the exact same software!
Low Risk – Canary Release
Live in production, but only for selected users who are willing to take the risk of using unstable software. Users selected are usually interested some key features, or they are willing to accept some risks. A typical example is Google’s Chrome Canary software.
If you wonder why the canary name, it actually refers to an old technique mining crews did whenever they went deeper into a mine, and air could be scarce. They would bring along a canary in a cage, as long as the bird was alive and chirping happy all was well, otherwise time to get out!
Lowest Risk – Feature Flag Release
Live in production, but dormant features. Ideal to put production tested code live, but dormant waiting for a date when the software will be revealed to the world. Even better the software can be turned on or off, if a failure is detected on actual enable day.
Special Case – Blue / Green Deployments
This is a strategy exclusively used for web based software. Green represents the latest stable reliable software in production now online. Blue is the candidate release. They are orchestrated through some kind of load balancer or reverse proxy.
When a new release is deployed, both versions of the software are left running online. If all goes well after a week or more, the new software is deemed Green, and Blue may be decommissioned. If anything goes wrong, the old software can replace the new one, and full rollback is done is seconds.
The key principle across all deployment options is this:
Releasing software more often, and having your software used by actual customers before you go live to production is the best and safest way to ensure high quality, reliable software. Moreover releasing high quality reliable software will lead you to gain loyalty from your customers, and gain new ones.
My advice would be to combine these practices, to create a Low Risk Deployment Strategy. The road to DevOps and agility aims to achieve high quality reliable software, these tools will help you get there, but it’s up to you and your organization to lead and embrace them.
Image Credit: Wikimedia Commons, Google IO Event 2019