Before we deep dive into the different deployment strategies that you should consider for your product, let's first understand what is a need for a smooth and fully functional deployment strategy.
With this rapidly changing user behavior and evolving products, companies must keep up with the market demands. DevOps here plays a crucial role in avoiding last-minute failures and downtime. To keep the users away from any negative impacts, engineers have been trying different deployment strategies for a smooth and effortless product release.
In this article, we will discuss eight distinct types of software deployment strategies. Every strategy comes with its own pros and cons which may also vary from company to company.
Let's begin our journey to understand when and where a particular strategy is used in application deployment.
It is considered one of the riskiest strategies of all as in Basic deployment, all nodes are updated at the same time with a new service or latest artifact version. It makes the rollback process very tedious.
- It is fast, simple, and cheap.
- Can be used if your application is not business or revenue critical.
- Can be considered if your application is not in use or you are deploying it during the off-hours.
- It is difficult to roll back to the previous version.
- It is not outage-proof and falls into the riskiest category.
It is also one of the riskiest deployment strategies. It is used when the target environment is updated with multiple new services all at the same time. It comes in handy when applications have service or version dependency. If you are using this strategy it is recommended to do it in the off-hours or when your application is not in use.
- This strategy is fast, simple, and cheap as well.
- Not as risk prone as Basic Deployment.
- It makes the rollback process slow and is not outage-proof.
- With this strategy managing, testing, and verifying all services is difficult.
Recreate Deployment Strategy
It is one of the basic ways of deployment in which the older version is completely shut down and then the updated version is made live. It brings huge downtime with it and can only be used when your application availability is not a major concern.
- It doesn't require a load balancer.
- Engineers get more time to complete the process.
- The downtime of the application will be based on the reboot time and the disk writing speed.
- Users will be impacted in real-time.
It updates the running instances of an application with the new release. Nodes are updated incrementally with the service or artifact version in integer N batches.
- Simpler to roll back.
- Less risky than Basic Deployment.
- Easy Implementation.
- Nodes are updated in batches hence services should support both old and new versions.
- Since the deployment is happening incrementally, it makes the verification and the deployment process slow.
It utilizes two identical environments, one Blue and another one is Green, and both are running parallelly in the production environment. Load Balancer can be used to switch the traffic from the old-Blue version to the new-Green version instantly.
Both the Blue and Green versions are available on the production, in case something went wrong, the Load Balancer can instantly switch traffic back to the old-Blue environment.
- It is simple, fast, and easy to implement.
- Instant rollback.
- Not risky compared to other deployment strategies.
- High Infra Costs.
- It can become complex and expensive to replicate the production environment.
Read more about the working of Blue-Green Deployments in the below article.
It involves slowly rolling out the changes to a subset of users instead of rolling them to all the users at once, this approach makes it one of the safest deployment strategies.
As a subset of users is targeted, deployment can be analyzed thoroughly to assess if it is ready to be incrementally (slower) rolled out to the other sets of users. In case of any issue occurs, the deployment can be rolled back easily, for troubleshooting.
- Faster rollback process.
- Provides more flexibility to developers to test the new feature and make them 100% sure to deploy the application for all the users.
- It is much cheaper than blue-green deployments there is no need for two production environments.
- The deployment cycle is much longer and slower.
- Scripting of canary release is complex and hence is time-consuming.
A/B Testing is a statistically motivated deployment strategy, different versions of the same service are run simultaneously, and data is gathered over a period which helps to decide if the updated version is good to go or not.
In A/B Testing user data is routed based on many factors like their demographics, user type, free/paid plan users, etc.
- Multiple versions can be tested at the same time with the help of different A/B testing tools.
- Routing decisions are based on real-time user data.
- There is a requirement for an expensive and complex Load Balancer.
- The experimental nature of this deployment can sometimes break the application.
Shadow Deployment Strategy
In shadow deployment, the previous version is present parallelly with the updated version, and a fork version of the traffic is routed towards the updated version for testing. Once the traffic and load testing are completed successfully, the updated version is then deployed to the production.
It is one of the complex strategies as SREs must maintain two versions and need to take care of the duplicate requests that are getting generated with the forked traffic.
- Accurate performance and stability tests.
- No impact on the users.
- It is expensive as it requires double resources.
- Setting it up is complex.
- Higher infrastructure costs.
How to Decide which Deployment Strategy to Use?
Now that you are aware of several types of Deployment Strategies, how can you decide which strategy you should follow? This depends on your application type and your target customers and environments.
We have gathered data, automating hundreds of product deployments. Companies prefer Blue-Green Deployments or Canary Deployments for critical application deployments. It is also quite common for teams to create a strategy by combining a lot of different strategies mentioned in this article.