CodeDeploy and CodePipeline

AWS CodeDeploy is a fully managed deployment service that automates code deployments to any instance, including Amazon EC2, on-premises servers, AWS Lambda functions, and Amazon ECS services. It handles the complexity of updating applications with minimal downtime, supports rolling and blue/green deployments, and integrates with CodePipeline for CI/CD.

Before CodeDeploy, engineers had to manually script deployment processes using SSH, custom scripts, or configuration management tools like Chef/Puppet. These scripts were brittle, lacked rollback capabilities, and did not provide a unified view of deployment status across fleets. CodeDeploy provides a standardized, repeatable, and auditable mechanism that works across environments.

CodeDeploy uses a revision – a combination of an application specification file (appspec.yml) and the application files (source code, scripts). The appspec.yml defines: - files: which files to copy from the revision to the instance. - hooks: lifecycle event hooks where you run scripts (e.g., before install, after install). - permissions: file permissions.

The deployment process on EC2/on-premises: 1. Agent: CodeDeploy agent runs on the target instance, polling the CodeDeploy service for work. 2. Revision download: Agent downloads the revision from Amazon S3 or GitHub. 3. Lifecycle events: Agent executes hooks in order: BeforeBlockTraffic, BlockTraffic, AfterBlockTraffic, ApplicationStop, DownloadBundle, BeforeInstall, Install, AfterInstall, ApplicationStart, ValidateService, BeforeAllowTraffic, AllowTraffic, AfterAllowTraffic. 4. Success/Failure: Agent reports status back to CodeDeploy service. On failure, the deployment can be configured to roll back.

- Deployment Group: A set of instances (EC2 tags, ASG names) or Lambda functions targeted for deployment. - Deployment Config: Defines deployment speed and failure thresholds. - OneAtATime: Deploys to one instance at a time, waits for success before next. - HalfAtATime: Deploys to 50% of instances. - AllAtOnce: Deploys to all instances simultaneously. - Canary and Linear (for Lambda/ECS): Traffic shifting. - Default timeout for lifecycle hooks: 3600 seconds (1 hour). - Revision location: S3 bucket or GitHub repository. S3 bucket must have versioning enabled. - Agent polling interval: Every 1 second by default. - Maximum number of concurrent deployments per deployment group: 1 (default, but can be increased).

For Lambda, CodeDeploy manages traffic shifting between versions using Canary or Linear configurations. For example, a canary configuration Canary10Percent5Minutes shifts 10% of traffic to the new version for 5 minutes, then shifts the remaining 90%. For ECS, CodeDeploy works with the ECS service to perform blue/green deployments using Application Load Balancer target groups.

CodePipeline is a fully managed continuous delivery service that orchestrates the build, test, and deploy phases of your release process. It models the release pipeline as a series of stages (e.g., Source, Build, Test, Deploy), each containing actions that are executed sequentially or in parallel.

CodePipeline often includes a Deploy stage that uses CodeDeploy as the action provider. The pipeline passes the deployment artifact (e.g., a ZIP file) to CodeDeploy. CodeDeploy then deploys that artifact to the instances or Lambda functions defined in the deployment group. The pipeline waits for the CodeDeploy deployment to succeed or fail before proceeding.

# sample-pipeline.yaml
pipeline:
  name: MyPipeline
  stages:
    - name: Source
      actions:
        - name: SourceAction
          actionTypeId:
            category: Source
            owner: AWS
            provider: CodeCommit
            version: 1
          configuration:
            RepositoryName: MyRepo
            BranchName: main
          outputArtifacts:
            - name: SourceArtifact
    - name: Build
      actions:
        - name: BuildAction
          actionTypeId:
            category: Build
            owner: AWS
            provider: CodeBuild
            version: 1
          configuration:
            ProjectName: MyBuildProject
          inputArtifacts:
            - name: SourceArtifact
          outputArtifacts:
            - name: BuildArtifact
    - name: Deploy
      actions:
        - name: DeployAction
          actionTypeId:
            category: Deploy
            owner: AWS
            provider: CodeDeploy
            version: 1
          configuration:
            ApplicationName: MyApp
            DeploymentGroupName: MyDG
          inputArtifacts:
            - name: BuildArtifact

A large e-commerce company uses CodeDeploy to deploy microservices on ECS Fargate. They have a pipeline that builds Docker images, pushes them to ECR, and then uses CodeDeploy to perform blue/green deployments with a linear traffic shift (10% every 10 minutes). This allows them to monitor error rates and latency during the shift. If the new version causes a spike in 5xx errors, CloudWatch Alarms trigger a rollback. They configure the deployment group with a minimum healthy percentage of 50% to ensure capacity. The pipeline runs multiple times per day, and CodeDeploy manages the traffic routing via the ALB target groups. A misconfiguration of the appspec.yml (e.g., wrong container name) can cause the deployment to fail, but the automatic rollback restores the previous version within minutes.

A bank uses CodePipeline and CodeDeploy to deploy to EC2 instances behind an Auto Scaling group. They need to ensure that every deployment is audited. They enable S3 bucket versioning for the artifact store and use AWS CloudTrail to log all API calls. The pipeline includes an approval stage before production deployment. CodeDeploy's lifecycle hooks run security scans (e.g., antivirus, SAST) in the BeforeInstall hook. If a scan fails, the hook returns a non-zero exit code, stopping the deployment. The bank also uses CodeDeploy's deployment history to prove that only approved revisions were deployed. A common issue is that the CodeDeploy agent on spot instances may be terminated, causing incomplete deployments. They mitigate this by using lifecycle hooks in the ASG to gracefully handle instance termination.

A SaaS provider uses CodeDeploy to manage canary deployments for AWS Lambda functions. They have a pipeline that builds the Lambda zip, publishes a new version, and updates the alias to point to the new version. They use a canary deployment configuration Canary10Percent5Minutes to shift 10% of traffic for 5 minutes. During this time, they monitor invocation errors and duration. If the error rate exceeds 1%, they manually roll back by updating the alias to the old version. A common mistake is forgetting to include the appspec.yml in the revision; for Lambda, the appspec.yml must be present in the revision root. Another issue is that the Lambda function's reserved concurrency can cause throttling during the canary if not adjusted.