AWS CodeDeploy

Core Components of AWS CodeDeploy

Understanding the main components of CodeDeploy is key to using it effectively.

1. Application: An "Application" in CodeDeploy is a name or container that uniquely identifies the application you want to deploy. It groups together the deployment groups, revisions, and deployment configurations for a specific piece of software.

2. Deployment Group: A deployment group is a set of individual instances or target servers where you want to deploy your application. You can define a deployment group using:

   • Amazon EC2 instance tags.

   • Amazon EC2 Auto Scaling groups.

   • Amazon ECS services.

   • On-premises instances with tags.

3. Deployment Configuration: This defines the rules and success/failure conditions for a deployment. It specifies how the deployment should proceed, such as the number of instances to deploy to at once and the conditions for a healthy deployment.

   • Pre-defined Configurations:

     • CodeDeployDefault.OneAtATime: Deploys to one instance at a time.

     • CodeDeployDefault.HalfAtATime: Deploys to 50% of the instances at a time.

     • CodeDeployDefault.AllAtOnce: Deploys to all instances simultaneously.

   • Custom Configurations: You can create your own configurations to control the pace of the rollout.

4. Application Revision: A revision is a specific version of your deployable code and application specification file (appspec.yml). For EC2/On-Premises, it's typically a .zip, .tar, or .tar.gz archive stored in Amazon S3 or a Git repository.

5. AppSpec File (appspec.yml): This is the most critical file. It's a YAML-formatted file that you include in your application's source code. It defines the deployment actions that CodeDeploy should execute.

   • version: Specifies the version of the AppSpec file format.

   • os: The operating system (e.g., linux or windows).

   • files: Specifies the source files from your revision to copy to the destination on the instance.

   • hooks: This is the core of the file. It defines the scripts to run at different lifecycle event hooks during the deployment.

The AppSpec File and Lifecycle Hooks

The hooks section allows you to run custom scripts at various stages of the deployment. The order of execution is crucial for a successful deployment.

For EC2/On-Premises Deployments:

| Hook Name | Description |

| :--- | :--- |

| ApplicationStop | Runs on the previous revision before the new one is deployed. Useful for gracefully stopping services. |

| DownloadBundle | The CodeDeploy agent copies the revision files to a temporary location. (No user scripts) |

| BeforeInstall | Runs before the Install hook. Good for pre-deployment tasks like backing up data or removing old files. |

| Install | The CodeDeploy agent copies the files from the temporary location to the final destination. |

| AfterInstall | Runs after the Install hook. Used for tasks like setting file permissions or installing dependencies. |

| ApplicationStart | Starts the application services. |

| ValidateService | The final hook. Used to run tests to verify the deployment was successful. |

For Lambda and ECS Deployments:

The lifecycle events are simpler and focus on traffic shifting. For example, with a Lambda deployment, you have hooks like BeforeAllowTraffic and AfterAllowTraffic to run validation tests on the new version before and after it receives production traffic.

Deployment Types

CodeDeploy supports two primary deployment types:

1. In-Place Deployment

• How it works: The application on each instance in the deployment group is stopped, the latest application revision is installed, and the new version of the application is started and validated.

• Pros: Simple and fast for development environments.

• Cons: Causes downtime for each instance as it's being updated. A failed deployment requires a rollback on the affected instances.

2. Blue/Green Deployment

• How it works: A new, identical environment (the "Green" environment) is provisioned. CodeDeploy installs the new application revision on the green instances. Once the deployment is successful, you can reroute traffic from the original "Blue" environment to the "Green" environment.

• Compute Platforms: Supported for EC2/On-Premises, AWS Lambda, and Amazon ECS.

• Pros:

  • Zero Downtime: Traffic is only shifted when the new environment is ready.

  • Fast Rollback: If something goes wrong, you can simply reroute traffic back to the original blue environment.

  • Environment Control: You can keep the old blue environment running for testing or terminate it to save costs.

• Cons: Requires more infrastructure (and thus, cost) during the deployment process since two environments are running simultaneously.

Monitoring and Rollbacks

• Automatic Rollbacks: CodeDeploy can automatically roll back a deployment if a specified threshold of failures is met (e.g., if the deployment fails on too many instances). It will redeploy the last known good revision.

• Monitoring: You can monitor the status of your deployments in the CodeDeploy console. It also integrates with Amazon CloudWatch Alarms, allowing you to trigger automatic rollbacks if a metric (like high CPU utilization or application errors) breaches a threshold. You can also receive notifications about deployment state changes via Amazon SNS.