8 Deployment Strategies Explained and Compared

It’s common to hear people referring to their deployment strategy as "DevOps", but that's not quite accurate. DevOps is a philosophy and culture, while deployment strategies are more narrowly focused on the actual steps used to deploy software.

Still, it's important for your team to think about its deployment strategy before any code gets written or tests run because this will have an impact on every other aspect of development, from design through testing and into production.

Why you should carefully consider your deployment strategy

We believe that a well-considered software deployment strategy is crucial for the success of any software delivery team. There are several reasons for this:

• It ensures that software is deployed in a consistent and repeatable manner, reducing the risk of errors and downtime.
• It allows teams to easily rollback to a previous version of the software in case of issues.
• It enables teams to deploy software to different environments (e.g. development, staging, production) in a controlled and efficient manner.
• It allows teams to easily track and measure the success of their deployments.
• It enables teams to take advantage of modern deployment practices such as continuous delivery and canary releases.

Overall, a carefully considered software deployment strategy helps to ensure that software is delivered to customers quickly, safely, and with minimal disruption.

Deployment strategies: 8 explained in depth

When it comes to deploying software, there are various strategies to choose from. Each strategy has its own advantages and disadvantages and here are some popular options to consider:

1- Big Bang Deployment

A big bang deployment is a type of software deployment in which all of the changes are deployed to the production environment all at once. This is in contrast to a phased or incremental deployment, where the changes are deployed in stages or in small batches.

Big bang deployments can be risky because they require a significant amount of coordination and testing to ensure that all of the changes work together as intended. They also require a larger amount of testing and validation in a short period of time. The risk is often also increased since all the changes are deployed in one go and if something goes wrong it's harder to rollback.

2- Continuous Deployment

Continuous Deployment (CD) is a software deployment strategy that allows you to release new versions of your application to production at any time, without human intervention. It’s a good choice for many organizations because it allows them to get features into the hands of their customers faster.

It also helps companies reduce the risk of deploying new code, since it eliminates the need for a manual testing or approval process. This approach is especially useful for businesses that are constantly developing new features and want to get them into production as quickly as possible.

Continuous Deployment deploys software changes to production as soon as they pass testing and validation. It differs from Continuous Delivery (also abbreviated "CD"), which may include manual gates before deploying to production.

3- Blue-Green Deployment

With this deployment strategy, we'll have both the old and new versions of the software running side by side. You might also know it as the red/black deployment strategy. Just to clarify, the stable, or older version of the application is always referred to as blue (or red), while the newer version is green (or black).

Once the new version has been thoroughly tested and meets all the requirements, the load balancer will automatically switch traffic over to it.

For this to work, both environments must have the same database schema to share data seamlessly, or a system to synchronize different schema versions.

The big advantage of this approach is that it allows for quick updates and rollouts. However, it can be more costly as we need to run both versions simultaneously. If you're using AWS Lambda functions as part of your application architecture (or want more control over how they're deployed), blue-green deployments are probably right up your alley!

4- Canary Deployment

With canary deployment, we'll set up the new version and slowly shift production traffic from the older version to the new one. For instance, during the deployment process, the older version might still handle 75% of all traffic while the newer version handles the remaining 25%.

This approach helps us test the stability of the new version using live traffic from a subset of end-users at different levels as the deployment progresses.

• Phase 1: This phase deploys the new release to one user or a few users. These "canary" users are typically chosen randomly, but they can also be selected based on their current usage patterns or other characteristics that may make them more likely to respond positively to the change.
• Phase 2: This phase deploys the new release to all remaining users (i.e., anyone who hasn’t been given access yet). If metrics collected during Phase 1 show that things aren't going well, you can roll back at this point by switching back over your old (good) versions of code - and no harm done!

Canary deployment allows for better performance monitoring and makes it easier to roll back the software if the new version doesn't work out. But keep in mind that it requires robust Test Environment Management processes and can be a slower and more time-consuming process compared to other deployment techniques.

5- Shadow Deployment / Dark Launching

In this deployment strategy, we'll deploy the new version alongside the old one, but users won't have access to the new version right away. It's like the new version is hiding in the shadows. We'll send a copy or "fork" of the requests the old version receives to the shadow version to see how it will handle them when it goes live.

This technique allows testing new features without having to wait for them to go through QA testing, which can take weeks or even months depending on how large our company is and how many people are involved in the process.

It's important to keep in mind that this technique can be a bit complex, so as a DevOps engineer, you'll want to be extra careful to make sure the forked traffic doesn't create a duplicate live request since we're running two versions of the same system at once.

Shadow deployment allows us to monitor system performance and conduct stability tests, but it can be costly and complex to set up and can cause serious issues if not handled properly.

6- Ramped Deployment & Rolling Deployment

People tend to confuse Ramped Deployment and Rolling Deployment, because both deploy updates to a subset of clusters/servers/instances, and then to the rest of them.

But they go about it in different ways:

• With ramped deployment, we start by updating a small percentage of servers at a time and gradually increase that percentage over time. This allows for keeping an eye on how the deployment is going and making any necessary adjustments before rolling it out to more servers.
• Rolling deployment, on the other hand, updates servers one at a time in a round-robin fashion. This means we can test each server before moving on to the next, making the deployment process more controlled and predictable.

Both strategies offer zero downtime and allow for performance monitoring, but keep in mind that the rollback process can take a while in case of unexpected events since we have to go through the same process: one server/instance at a time.

Kubernetes simplifies rolling deployments by allowing teams to scale replicas and use the built-in "rolling updates" feature, which updates a subset of machines without interruption, enabling gradual rollouts of new versions of software.

7- Recreate Deployment

In this deployment strategy, you shut down the old version of the application completely, deploy the new version, and then turn the whole system back on. This means there will be a downtime while the old software is shut down and the new one is booted up.

It's a cheaper option, and it's mostly used when the software firm wants to completely change the application. It doesn't require a load balancer because there's no shifting of traffic from one version to another in the live production environment.

But here's the catch, this strategy can have a big impact on end-users because of the downtime. They have to wait for the application to go live again before they can use the software. So, not many teams use this strategy unless they don't have any other options.

8- A/B Testing Deployment

A/B testing deployment is a way for developers to test out new versions of their software. They do this by deploying the new version alongside the older version, but only making the new version available to a select group of users.

These users are chosen based on certain factors, like their location, device type, language, and operating system. This helps the team measure how well the new features are working.

Once they have the data they need, they can then roll out the version that performed the best to everyone. It's a great way to make informed decisions about your software, but it can be pretty complex to set up and requires some fancy tech like a load balancer (similar to the Blue-Green Deployment we showed above).

You may think it is similar to Canary Deployment, so what's the main difference?
A/B Testing Deployment focuses on comparing performance of new version against the old one, while Canary Deployment focuses on testing the new version in a production-like environment before releasing it.

How to choose the right deployment strategy for your software project?

Choosing the right deployment strategy for your software project is all about finding the best fit for your specific needs. Here are a few things to keep in mind:

In the end, the right deployment strategy will depend on your project's specific needs and constraints. It's important to weight the pros and cons and choose a strategy that's the best fit for your team and your project.

No matter what deployment strategy you're using, it's important to keep tabs on what's happening in your environments. You need to know which versions are deployed, and what the statuses of your environments are.

Jira Software, together with our Golive Jira App, gives you a complete bird's-eye view of everything right in Jira. It makes it easy to stay on top of things and make sure everything is running smoothly.