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:

Size and complexity of the project

If your project is on the smaller side and doesn't have too many dependencies, you might be able to get away with a simpler strategy like blue-green deployment or rolling deployment. But if you're working on something larger and more complex, a more advanced strategy like canary deployment or A/B testing deployment might be more your style.

Availability & scalability requirements

Making sure your application is available and can handle a lot of traffic is important, especially in a production environment. If you need to be able to update your app quickly or roll back in case of issues, you'll want to look at strategies that allow for rolling updates.

Resources available

Your team's resources will also play a role in choosing the right deployment strategy. If you're working with a small team or people who aren't as familiar with advanced strategies, you might want to stick with something simpler that's easy to set up and maintain.

Impact on end-users

It's important to keep in mind how the deployment strategy will affect the end-users. Some strategies like Big-Bang deployment can cause a longer downtime, so it's important to choose a strategy that allows for minimal downtime.

Deployment Best Practices

Modern application teams can follow a number of best practices to keep deployment risks to a minimum:

Use a deployment checklist. For example, an item on the checklist may be to “backup all databases only after app services have been stopped” to prevent data corruption.
Adopt Continuous Integration (CI). CI ensures code checked into the feature branch of a code repository merges with its main branch only after it has gone through a series of dependency checks, unit and integration tests, and a successful build. If there are errors along the path, the build fails and the app team is notified. Using CI therefore means every change to the application is tested before it can be deployed. Examples of CI tools include: CircleCI, Jenkins.
Adopt Continuous Delivery (CD). With CD, the CI-built code artifact is packaged and always ready to be deployed in one or more environments. Read more in our Low-Risk Continuous Delivery eBook.
Use standard operating environments (SOEs) to ensure environment consistency. You can use tools like Vagrant and Packer for development workstations and servers.
Use Build Automation tools to automate environment builds. With these tools, it’s often simple to click a button to tear down an entire infrastructure stack and rebuild from scratch. An example of such tools is CloudFormation.
Use configuration management tools like Puppet, Chef, or Ansible in target servers to automatically apply OS settings, apply patches, or install software
Use communication channels like Slack for automated notifications of unsuccessful builds and application failures
Create a process for alerting the responsible team on deployments that fail. Ideally you’ll catch these in the CI environment, but if the changes are deployed you’ll need a way to notify the responsible team
Enable automated rollbacks for deployments that fail health checks, whether due to availability or error rate issues.

Post-Deployment Monitoring

Even after you adopt all of those best practices, things may still fall through the crack. Because of that, monitoring for issues occurring immediately after a deployment is as important as planning and executing a perfect deployment.

An application performance monitoring (APM) tool can help your team monitor critical performance metrics including server response times after deployments. Changes in application or system architecture can dramatically affect application performance.

An error-monitoring solution like Rollbar is equally essential. It will quickly notify your team of new or reactivated errors from a deployment that could uncover important bugs requiring immediate attention.

Without an error monitoring tool, the bugs may never have been discovered. While a few users who encounter the bugs will take the time to report them, most others don’t. The negative customer experience can lead to satisfaction issues over time, or worse, prevent business transactions from taking place now.

An error monitoring tool also creates a shared visibility of all the post-deployment issues among Operations / DevOps teams and developers. This shared understanding allows the teams to be more collaborative and responsive.

Conclusion

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.

References: