BlogTop 6 Deployment strategies for releasing software + 11 Step Deployment Checklist

What’s your plan when releasing the new version of your app? Do you even have a plan? 

Releasing software should be just as structured and planned as the development it went through. If you have a poor strategy or no strategy, do you even know how much damage are you causing to your app’s reputation or users? 

Every time you release there is a chance you will either keep users or loose users, it’s really that simple. 

If you release and things go wrong, you will have a drop-off on users. If you release and things go well, you will keep your users happy. The last thing anyone wants when releasing software is to destroy their reputation and have their users lose confidence in the product – or worse leave the product altogether. 

If you’re releasing a mobile appA Mobile App/ Application is a program that you download from Google Play or The App Store. You then install..., the app stores will help with your release strategy. You can upload your files and then users will download them as they get notified, or they could have automatic updates on. But most apps run with a server or backendThe term backend refers to code on a server or serverless functions that run in the background. A user does... that feeds data to the apps and this is where the app stores can’t help. 

Whether you have an APIAn API is an Application Programming Interface. APIs are used to allow systems to retrieve data from other systems. It..., a WebApp, custom CRMCRM stands for Client Relationship Management. A CRM system is a digitised process of keeping your customer interactions and details..., CMS etc. There are just as many ways to release them as there are to build your product (not exactly true, but I think you get my point). Thinking about your product, budget and traffic will help you determine which of the following strategies are most suitable for you:

• Hot/Cold
• Incremental Rollover
• Blue/Green
• Canary
• Split Testing
• Shadow 

Hot/Cold

This is the simplest release strategy and involves taking your app down for a certain amount of time. If you don’t have large traffic this can generally be done out of office hours and have little-to-no impact on your user base.

Steps:

• Take your System offline
• Display a Maintenance Message (if you want to be nice)
• Deploy your new files to the Server
• Bring System online
• Take away Maintenace Window
• Traffic Resumes

Summary: Cheapest option and includes a period of downtime for your site. Problems can arise in production and can affect all users. If issues arise, rolling back can be difficult.

Blue/Green

A Blue/Green strategy, besides having an interesting name, involves deploying a Server B while you have Server A operational and then diverting all traffic from Server A to Server B. This strategy requires two identical environments to be set up with one data layer shared between both. 

Steps:

• Maintain Server B as a replica of Server A
• Deploy new Files to Server B
• Divert all traffic from Server A to Server B

Summary: requires replicating environments (thereby increasing costs), unknown problems can arise in production and can affect all users. No downtime for users.

Incremental Rollover

An Incremental Rollover strategy is exactly how it sounds, incremental. You take the Blue/Green strategy and maintain two environments but instead of diverting all traffic at once you slowly divert traffic, you might start at 10% an hour until it’s all diverted for example. 

Steps:

• Maintain Server B as a replica of Server A
• Deploy new Files to Server B
• Divert some initial traffic from Server A to Server B
• Continue to divert more traffic over time till it’s all going to Server B

Summary: requires replicating environments (thereby increasing costs), unknown problems can arise in production and can affect a subset of users. No downtime for users.

Canary

This strategy functions similar to a canary in a coal mine. It’s used to provide a warning in the situation that a release is bad. You would start diverting traffic to a small subset of users then if it’s all good and hits your KPI’s then you would release to all of them. 

Steps:

• Maintain Server B as a replica of Server A
• Deploy new Files to Server B
• Divert a subset of users from Server A to Server B
• Monitor performance and errors
• If no issues are found and the release operates against your KPI’s then divert all traffic

Summary: safest option only release when features are confirmed to be working in live environment. Requires replicating environments. No downtime for users

Split Testing

This strategy is similar to the canary strategy but rather than divert a random subset of users you are testing features against a subset. This is generally used to determine which features work with the user base and get uptake only releasing the successful ones. It’s a similar concept to testing content on web pages or heading and images on landing pages. For a short time show certain features to users and gauge their use, performance and conversion, then use this information to determine what to release. 

Steps:

• Maintain Server B as a replica of Server A
• Deploy new Files to Server B
• Divert users based on certain parameters or factors within your application from Server A to Server B
• Monitor performance, conversion and usage
• Asses after a period of time and then release the best version to all users.

Summary: Can help identify which features provide the most conversion but this process can be slow and costly. No downtime for users

Shadow 

A Shadow strategy is the most complex and the hardest to set up, as it involves having the duplicate environments of above but also mirroring the traffic from Server A to Server B but not allowing users to interact with Server B at all. This strategy is normally used in larger platforms to ensure the app performs the same, under load with the new version. There are certain times where load testing doesn’t provide enough insights or accurate enough testing and only live traffic can produce a confident result.

Steps:

• Maintain Server B as a replica of Server A
• Deploy new Files to Server B
• Send a copy of all Server A traffic to Server B
• Monitor for performance 
• If no issues are found then divert traffic to Server B

Summary: The most expensive option and requires deep integration and control of your architecture. No downtime for users 

As we’ve seen the release strategies available to you vary in complexity and cost. This is normally where I would wrap up the article and say which is the best strategy to use however it’s not that simple.  The most suitable strategy will depend on your budget, traffic and tech stack, as well as the goals of your application.