Deployment methods - Practicing Continuous Integration and Continuous Delivery on AWS

Deployment methods

You can consider multiple deployment strategies and variations for rolling out new versions of software in a continuous delivery process. This section discusses the most common deployment methods: all at once (deploy in place), rolling, immutable, and blue/green. AWS indicates which of these methods are supported by AWS CodeDeploy and AWS Elastic Beanstalk.

The following table summarizes the characteristics of each deployment method.

Method Impact of failed deployment Deploy time Zero downtime No DNS change Rollback process Code deployed to
Deploy in place Downtime
Re-deploy Existing instances
Rolling Single batch out of service. Any successful batches prior to failure running new application version.
Re-deploy Existing instances
Rolling with additional batch (beanstalk) Minimal if first batch fails, otherwise similar to rolling.
Re-deploy New and existing instances
Immutable Minimal
Re-deploy New instances
Traffic splitting Minimal
Re-route traffic and terminate new instances New instances
Blue/green Minimal
switch back to old environment New instances

All at once (in-place deployment)

All at once (in-place deployment) is a method you can use to roll out new application code to an existing fleet of servers. This method replaces all the code in one deployment action. It requires downtime because all servers in the fleet are updated at once. There is no need to update existing DNS records. In case of a failed deployment, the only way to restore operations is to redeploy the code on all servers again.

In AWS Elastic Beanstalk this deployment is called All at once, and is available for single and load-balanced applications. In AWS CodeDeploy this deployment method is called In-place deployment with a deployment configuration of AllAtOnce.

Rolling deployment

With rolling deployment, the fleet is divided into portions so that all of the fleet isn’t upgraded at once. During the deployment process two software versions, new and old, are running on the same fleet. This method allows a zero-downtime update. If the deployment fails, only the updated portion of the fleet will be affected.

A variation of the rolling deployment method, called canary release, involves deployment of the new software version on a very small percentage of servers at first. This way, you can observe how the software behaves in production on a few servers, while minimizing the impact of breaking changes. If there is an elevated rate of errors from a canary deployment, the software is rolled back. Otherwise, the percentage of servers with the new version is gradually increased.

AWS Elastic Beanstalk has followed the rolling deployment pattern with two deployment options, rolling and rolling with additional batch. These options allow the application to first scale up before taking servers out of service, preserving full capability during the deployment. AWS CodeDeploy accomplishes this pattern as a variation of an in-place deployment with patterns like OneAtATime and HalfAtATime.

Immutable and blue/green deployment

The immutable pattern specifies a deployment of application code by starting an entirely new set of servers with a new configuration or version of application code. This pattern leverages the cloud capability that new server resources are created with simple API calls.

The blue/green deployment strategy is a type of immutable deployment which also requires creation of another environment. Once the new environment is up and passed all tests, traffic is shifted to this new deployment. Crucially the old environment, that is the “blue” environment, is kept idle in case a rollback is needed.

AWS Elastic Beanstalk supports immutable and blue/green deployment patterns. AWS CodeDeploy also supports the blue/green pattern. For more information on how AWS services accomplish these immutable patterns, refer to the Blue/Green Deployments on AWS whitepaper.