CodePipeline Design and Triggers

What it is

AWS CodePipeline is a managed continuous delivery service that models a release process as a series of stages. Each stage holds one or more actions, such as pulling source code, running a build, deploying, or waiting for a person to approve.

Continuous integration (CI) means every change is merged and built often. Continuous delivery (CD) means every change that passes the pipeline is ready to release. CodePipeline does not build or deploy anything itself: it orchestrates other services such as AWS CodeBuild, AWS CodeDeploy, AWS CloudFormation, Amazon ECS and AWS Lambda.

How it works

A pipeline needs at least two stages, and the first stage must contain a source action. Actions in the same stage run in parallel unless you give them different run orders. Stages run one after another.

Artifacts

Actions pass data to each other as artifacts. CodePipeline stores them in an Amazon S3 artifact bucket, encrypted with a key from AWS Key Management Service (KMS). A later action names the earlier output as its input artifact.

The core principle is to build once and promote the same artifact through every environment. Rebuilding for production means you ship something you never tested.

Sources and triggers

Change detection should use Amazon EventBridge events, not polling. Pipeline type V2 adds triggers with filters on branches, tags and file paths, plus pipeline level variables. V2 also lets you choose how overlapping executions behave: queued, superseded (a newer run replaces a waiting older one), or parallel.

Action categories

The categories are Source, Build, Test, Deploy, Approval and Invoke. Deploy providers include CloudFormation, CodeDeploy, ECS, Elastic Beanstalk, S3 and others. The Invoke category runs a Lambda function or a Step Functions state machine for custom logic.

Action output variables can be read later in the pipeline with the syntax #{namespace.VariableName}, for example the commit ID from the source action.

Manual approval

An approval action pauses the pipeline and can publish to an Amazon SNS topic. The reviewer needs the codepipeline:PutApprovalResult permission. An approval that nobody answers eventually times out and counts as rejected.

Cross account and cross Region

Production usually lives in a separate account. The pipeline runs in a tools account and assumes a role in the target account for the deploy action.

Three things must line up. The artifact bucket policy must let the target account read artifacts, the KMS key must be a customer managed key whose policy trusts the target account, and the target role must be able to use both. The default AWS managed S3 key cannot be shared across accounts, which is the classic failure.

For a cross Region action, CodePipeline needs an artifact bucket in each Region the pipeline uses. You declare these in the pipeline structure.

aws codepipeline get-pipeline --name my-pipeline
aws codepipeline start-pipeline-execution --name my-pipeline
aws codepipeline retry-stage-execution --pipeline-name my-pipeline \
  --stage-name Deploy --pipeline-execution-id <id> --retry-mode FAILED_ACTIONS

Pipeline as code

Define pipelines in CloudFormation with AWS::CodePipeline::Pipeline or in the AWS Cloud Development Kit (CDK). CDK Pipelines can modify its own definition when the pipeline code changes, which is called self mutation.