CI/CD Deployment Strategy

3 min readJan 10, 2023

As an IT Engineer, you are likely already familiar with the concept of CI/CD.

In this post, I’ll skip the basics and dive into different ways to deploy CI/CD pipelines.

1. In-Place Deployment

To update the instances in your deployment group, first stop each instance, then apply the changes to all of them, and finally restart the instances to finish the update process.

If necessary, you can also revert to a previous version after the deployment, but keep in mind that this will require temporarily halting the service.

In-place Deployment

2. Rolling Update Deployment

A method for updating multiple running instances by a set number and distributing a newly updated server.

This is a gradual shift of traffic to the new instance, and instances of the older version are also gradually deleted.

This method does not interrupt the service, however, it’s important to consider the reduction in server processing capacity ahead of time.

Rolling Update Deployment

3. Blue/Green Deployment

The Blue/Green deployment is a seamless way to update applications by gradually shifting user traffic from an older version to a new release that is nearly identical.

This process is achieved by creating a new updated server, known as the “green” version, and redirecting new incoming requests to green while the older version, known as the “blue” version, continues to serve ongoing sessions.

Once all sessions attached to the blue version are completed, they can be terminated.

This method of deployment allows for quick rollback to a previous version if necessary, and can be combined with load balancing and Auto Scaling to manage traffic distribution. In an Auto Scaling scenario, when both blue and green are in progress, new autoscaling comes up and the existing one will disappear.

Blue/Green Deployment

4. Canary Deployment

It’s a deployment technique that focuses on updating a specific server at a time, gradually increasing the traffic flow to the newly deployed server.

Initially, most traffic goes to the original server (blue), and a small percentage (e.g., 20%) is redirected to the updated server (green). If everything’s functioning as expected, more traffic is shifted to the new server until it eventually handles all traffic and the old server is terminated.

This roll-out approach helps detect any potential errors early on and allows for a quick rollback if necessary.

Canary Deployment




Partner Engineer at Google | Solutions Architect | Cloud Engineer | AWS & GCP Certified