Deployment Strategies and Rollback

What it is

A deployment strategy decides how new code replaces old code and how much of your traffic is exposed to risk while it does. AWS CodeDeploy automates that process for EC2 instances, on-premises servers, Lambda functions and ECS services.

Rollback is the safety net. It returns users to the last working version, either automatically when a check fails or manually when you decide.

How it works

Strategies compared

In place deployments exist only for EC2 and on-premises servers. Lambda and ECS deployments are blue/green by nature, because the new version is a separate function version or task set.

CodeDeploy and the appspec file

Every revision has an AppSpec file that tells CodeDeploy what to do. The compute platform changes its content.

On EC2, the CodeDeploy agent must run on each instance. Lambda and ECS need no agent. Hooks point to scripts on EC2, or to Lambda functions on the other platforms, and they can fail the deployment, for example when a ValidateService script returns an error.

A deployment group names the target instances, tags or Auto Scaling groups. The revision is stored in Amazon S3 or in a GitHub repository.

Deployment configurations

For EC2 in place deployments, the predefined configurations are CodeDeployDefault.AllAtOnce, CodeDeployDefault.HalfAtATime and CodeDeployDefault.OneAtATime, and OneAtATime is the default.

For Lambda, the names show the shape: CodeDeployDefault.LambdaCanary10Percent5Minutes moves 10 percent first and the rest five minutes later, while CodeDeployDefault.LambdaLinear10PercentEvery1Minute moves 10 percent each minute. LambdaAllAtOnce shifts everything at once. ECS has matching ECSCanary, ECSLinear and ECSAllAtOnce options. ECS also offers a built in blue/green deployment with a bake time, during which the old revision stays ready.

In a SAM template, set AutoPublishAlias and a DeploymentPreference with a type, alarms and optional pre and post traffic hook functions. SAM then creates the CodeDeploy application for you.

Automatic and manual rollback

CodeDeploy can roll back automatically when a deployment fails or when a configured CloudWatch alarm goes into the alarm state. A rollback is itself a new deployment of the last successful revision. For Lambda it means the alias moves back to the old version. You can also redeploy an earlier revision by hand at any time.

CloudFormation rolls back a failed stack operation by default. A failed create leaves the stack in ROLLBACK_COMPLETE, which you must delete before trying again. A failed update returns to the previous state as UPDATE_ROLLBACK_COMPLETE. You can add rollback triggers, which are CloudWatch alarms watched during and after the update, and CloudFormation rolls back if one fires.

If a rollback itself fails (UPDATE_ROLLBACK_FAILED), fix the blocking resource and run ContinueUpdateRollback. To keep failed resources for debugging, disable rollback on failure when creating the stack.

Manual rollback usually means deploying the previous template or code version again, or moving a Lambda alias back to the old version.

How the exam asks about this

• "Send 10 percent of Lambda traffic to the new version, then all of it if alarms stay quiet." -> A CodeDeploy canary configuration, set through SAM DeploymentPreference.
• "Roll back automatically when the error alarm fires." -> Enable CodeDeploy automatic rollback on the alarm, or a CloudFormation rollback trigger.
• "A pre deployment validation script must run on EC2 before traffic returns." -> A lifecycle hook in the AppSpec file.