Deployment Groups – Establishing a Deployment Strategy – SAP-C02 Study Guide

Deployment Groups

CodeDeploy is meant to be used with existing compute resources, using which it can deploy application artifacts. Note that it does not create compute resources on your behalf. With that in mind, CodeDeploy organizes compute resources in deployment groups. When deploying application components to ECS, Lambda, and EC2/on-premises servers, deployment groups specify the various elements required by the target compute service as well as how a new version of the application components should be rolled out. For instance, a deployment group for ECS would specify when to re-route traffic to replacement tasks and when to terminate the original tasks after the successful deployment of an ECS application release. When deploying to Lambda, a deployment group would specify how to re-route traffic to the new version of a Lambda function. Optionally, deployment groups may also specify alarms (using Amazon CloudWatch), notification triggers (delivered by Amazon SNS), and automatic rollbacks. For more details on this, please consult the CodeDeploy documentation at https://packt.link/h36GV.

Deployment Configurations

CodeDeploy also needs to know about the deployment mechanism you want to follow and how to route traffic to the newly deployed application release. This is defined through the deployment configuration. This deployment configuration varies based on the compute resources you want to use.

When deploying to EC2/on-premises instances, you can either choose between the three pre-defined deployment configurations (all-at-once, half-at-a-time, and one-at-a-time) or specify your own custom configuration. If you don’t specify any deployment configuration, CodeDeploy defaults to the one-at-a-time deployment configuration. Now, for each of the pre-defined configuration options, you can also opt between an in-place deployment or a blue-green deployment. It is important to select the right configuration option for your needs as the success or failure of the deployment is defined differently according to different configuration options, as discussed here:

  • In an all-at-once deployment configuration, CodeDeploy deploys your new application release to all EC2/on-premises instances simultaneously. In this case, the deployment is considered successful if the new application release is deployed successfully to all of the instances and is considered failed otherwise.
  • In the case of an in-place deployment, the deployment is considered successful if the new application release is deployed successfully to at least one instance and is considered failed otherwise.
  • In the case of a blue-green deployment, the deployment is considered successful if traffic can be re-routed to at least one instance in the replacement environment.
  • In the half-at-a-time configuration, CodeDeploy deploys your new application release to half of the EC2/on-premises instances simultaneously. In the case of half-at-a-time deployment, the deployment is considered successful if the new application release is deployed successfully to at least half of the instances and is considered failed otherwise.
  • Finally, in a one-at-a-time configuration, CodeDeploy deploys your new application release to one EC2/on-premises instance at a time. A one-at-a-time deployment is deemed successful if the new application release is successfully deployed to each individual instance, one after the other.

Note that there is an exception when deploying to multiple instances: CodeDeploy considers that the deployment is still successful if the new application release fails to deploy to the last instance after having been successfully deployed to all the other instances before. When using a custom deployment configuration, you define how deployment takes place and what success looks like. The following command-line instruction shows an example of what you can do:

$ aws deploy create-deployment-config –deployment-config-name EightyPercentHealthy –minimum-healthy-hosts type=FLEET_PERCENT,value=80

This example creates a custom deployment configuration called EightyPercentHealthy requiring that at least 80% percent of the target EC2/on-premises instances stay healthy upon deployment.

When deploying to ECS, CodeDeploy always uses a blue-green deployment approach (unlike EC2/on-premises, it does not offer in-place deployment). Your deployment configuration then determines how traffic gets shifted to the new application release. You essentially choose between a set of pre-defined deployment configurations (either canary, linear, or all-at-once) or specify your own custom canary or linear configuration. When using one of the pre-defined canary deployment configurations, the traffic gets shifted in two increments: 10 percent of the traffic is initially sent to your new application release, and the remaining 90 percent is then shifted over after either 5 or 15 minutes. There are also two pre-defined variants of the linear deployment configuration: 10 percent of the traffic is shifted to the new application release either every minute or every 5 minutes (until all traffic has been directed to the new release).

When deploying to Lambda, CodeDeploy also always uses a blue-green deployment approach (similarly to ECS, it does not offer in-place deployment). The deployment configuration options are also similar to ECS: CodeDeploy deploys to Lambda following either a canary, linear, or all-at-once deployment. However, CodeDeploy offers many more pre-defined configuration options for Lambda. For canary deployment, CodeDeploy preset deployment configurations shift 10 percent of the traffic in a first increment and then the remaining 90 percent after either 5, 10, 15, or 30 minutes. For linear deployment, CodeDeploy preset deployment configurations shift 10 percent of the traffic every 1, 2, 3, or 10 minutes.