Deployment pipeline, part 3: deployment onto an environment

The purpose of every deployment pipeline is… a deployment. So this final part of the series, will focus on just that. If you missed the intro, check out the video where I describe a typical pipeline here. You can find the other parts of this series, by checking out the tag ci-pipeline-series .

Once we create an AMI that we’d like to deploy, performing a rolling update on existing instances is fairly easy. Usage of Auto scaling groups and CloudFormation makes it even easier - since AWS Auto scaling groups support the rolling updates out of the box.

Or, if your applications requires blue-green deployments, using CloudFormation is almost essential.

Rolling updates with Auto Scaling Groups

The basic idea behind rolling deployment within a cloud environment is to replace existing (old) instances with new ( updated) ones without downtime. To do that, we can simply replace instances one by one - launch a new instance, add it to the load balancer and take an old one out. If your application uses more than one instance, you can perform this sequentially for each instance or in case of big amounts of instances, for a group of instances (launch an X amount of instances at once to replace the same amount of existing ones). All those options are supported by Auto Scaling Groups via the UpdatePolicy for AutoScalingRollingUpdate. If you’re using CloudFormation, all you need to do is update the AMI ID referenced within your template for the Launch Configuration.

Example of a basic policy for rolling updates:

1
2
3
4
5
6
7
8

"UpdatePolicy": {
    "AutoScalingRollingUpdate": {
        "MaxBatchSize": 10,
        "MinInstancesInService": 1
        "PauseTime": "PT30S",
        "WaitOnResourceSignals": "false"
    }
}

For details on all the options available, checkout the UpdatePolicy documentation . You can specify the size of the group (batch size) of the instances that are to be replaced at once, how many instances should always be in service during the update, and more.

Blue-green deployments

For blue-green deployments, there are two main options that can be performed within AWS. It depends on whether your applications requires a “full” blue-green deployment set up, where a completely new, duplicate environment is created, which (once ready and confirmed working) replaces the existing one.

For complete blue-green deployments (and usually for canary deployments), using CloudFormation allows to automate and simplify the process tremendously. You can simply create a new CloudFormation stack using exactly the same template as the existing environment (and simply using the new AMI). Commonly, the two stacks would exist concurrently all the time - if deployments happen often, re-creating the whole stack from scratch would take too much time. Within AWS, you’d then have a separate load balancer for each stack and re-point your domain to a new ELB, once the deployment is finished.

For simpler blue-green deployments, where your application cannot handle having two versions of the code running at the same time (which is the case with rolling updates) even for a short period of time, but where launching a whole new stack is too complicated, simply using AutoScalingReplacingUpdate policy for UpdatePolicy attribute may be a better option (as it does not require a whole separate stack to exist). Caveat with this solution is that it does not allow you to take a full advantage of the blue-green deployment scheme, as you do not have a lot of time to completely ensure the new code is running as expected. This usually isn’t a big issue, as that can be established with proper testing before live deployments and/or by using meaningful health-checks. Replacing update can be a good solution for smaller projects, where the rolling updates cannot be performed due to the nature of the code or the infrastructure, but complete blue-green deployments would be an overkill.

For more information on updating CloudFormation stacks, check out the AWS documentation on stack updates and CreationPolicy attribute and signals.