CodePipeline Deployment Patterns

AWS CodePipeline is a fully managed continuous delivery service that helps you automate your release pipelines for fast and reliable application and infrastructure updates. It models the entire release process as a series of stages, each containing one or more actions. A pipeline is triggered by a source change (e.g., a commit to a CodeCommit repository, an S3 upload, or a GitHub webhook) and then moves artifacts through each stage sequentially. Each stage can have multiple parallel actions, and approval actions can pause the pipeline for manual sign-off.

When a pipeline is triggered, CodePipeline creates a pipeline execution. The execution transitions through states: InProgress, Succeeded, Failed, Superseded, or Cancelled. Each action within a stage also has its own state. Artifacts are passed between stages using Amazon S3. CodePipeline uses a series of polling or event-based mechanisms to detect source changes. For example, for a CodeCommit source, CodePipeline can use CloudWatch Events to trigger on repository changes. For GitHub, it uses webhooks.

CodePipeline supports several deployment patterns through its integration with CodeDeploy, Elastic Beanstalk, ECS, EKS, and Lambda. The most common patterns are:

Using the AWS CLI, you can create a pipeline with a JSON configuration file. Example command:

aws codepipeline create-pipeline --cli-input-json file://pipeline.json

A sample pipeline.json:

{
  "pipeline": {
    "name": "MyAppPipeline",
    "roleArn": "arn:aws:iam::123456789012:role/MyCodePipelineRole",
    "artifactStore": {
      "type": "S3",
      "location": "codepipeline-us-east-1-123456789012"
    },
    "stages": [
      {
        "name": "Source",
        "actions": [
          {
            "name": "Source",
            "actionTypeId": {
              "category": "Source",
              "owner": "AWS",
              "provider": "CodeCommit",
              "version": "1"
            },
            "configuration": {
              "RepositoryName": "MyRepo",
              "BranchName": "main"
            },
            "outputArtifacts": [
              {
                "name": "source_output"
              }
            ],
            "runOrder": 1
          }
        ]
      },
      {
        "name": "Build",
        "actions": [
          {
            "name": "Build",
            "actionTypeId": {
              "category": "Build",
              "owner": "AWS",
              "provider": "CodeBuild",
              "version": "1"
            },
            "configuration": {
              "ProjectName": "MyBuildProject"
            },
            "inputArtifacts": [
              {
                "name": "source_output"
              }
            ],
            "outputArtifacts": [
              {
                "name": "build_output"
              }
            ],
            "runOrder": 1
          }
        ]
      },
      {
        "name": "Deploy",
        "actions": [
          {
            "name": "Deploy",
            "actionTypeId": {
              "category": "Deploy",
              "owner": "AWS",
              "provider": "CodeDeploy",
              "version": "1"
            },
            "configuration": {
              "ApplicationName": "MyApp",
              "DeploymentGroupName": "MyDeploymentGroup"
            },
            "inputArtifacts": [
              {
                "name": "build_output"
              }
            ],
            "runOrder": 1
          }
        ]
      }
    ]
  }
}

Approval actions allow manual sign-off before proceeding. They are configured with a configuration object containing NotificationArn (SNS topic) and CustomData (optional message). The pipeline pauses until an IAM user or role approves or rejects. The approver must have codepipeline:PutApprovalResult permission.

You can view execution details in the AWS Console. Each action shows start/end times, status, and links to logs (e.g., CloudWatch Logs for CodeBuild). For failures, the pipeline can be retried from the failed stage. Use aws codepipeline list-action-executions to get action-level details.

CodePipeline supports cross-region actions. You can have source in one region, build in another, and deploy in a third. The artifact store must be in the same region as the pipeline, but actions can be in different regions. You need to create an S3 bucket in each region for artifacts, and the pipeline role must have cross-region permissions.

A large e-commerce company uses CodePipeline to deploy their web application to ECS Fargate. They have a multi-branch pipeline: feature branches deploy to a staging environment, and the main branch deploys to production using a blue/green strategy. The pipeline includes a source stage from CodeCommit, a build stage that builds a Docker image and pushes it to ECR, a test stage that runs integration tests in a temporary ECS service, an approval stage that requires sign-off from a QA lead, and a deploy stage that uses CodeDeploy to perform a blue/green deployment on ECS. Traffic is shifted gradually using a canary configuration (10% for 5 minutes, then 100%). If the canary fails, CodeDeploy automatically rolls back. The pipeline is triggered by CloudWatch Events on pull request merges. The team has set up SNS notifications for approval and failure alerts. Performance considerations: The artifact store S3 bucket is versioned to retain deployment history. The pipeline runs about 20 times per day, and the artifact size is around 500 MB. They have encountered issues with cross-region artifacts when they tried to deploy to multiple regions; they had to create separate pipelines per region with shared source.

A fintech startup uses CodePipeline to deploy multiple microservices independently. Each microservice has its own pipeline with a common source monorepo. They use a build stage that runs a CodeBuild project for each service, producing separate artifacts. The deploy stage uses Elastic Beanstalk for some services and Lambda for others. They use a manual approval stage before production deployment to ensure compliance. One challenge they faced was pipeline concurrency: when multiple commits were pushed simultaneously, some executions were superseded. They mitigated this by using a queueing mechanism with a custom Lambda action that serializes deployments. They also use CloudWatch Events to trigger pipelines on a schedule for nightly builds. The pipelines are configured with a maximum of 10 concurrent executions per pipeline (default limit is 1, but they requested an increase). They learned that artifacts are stored in S3 with a lifecycle policy to delete old artifacts after 30 days to save costs.