AWS Developer Tools & CI/CD
CodePipeline
Fully managed continuous delivery pipeline for fast and reliable application updates
AWS CodePipeline is a fully managed continuous delivery service that orchestrates the steps required to release software - from source to build to test to deploy. It models your release process as a series of stages and actions, providing visibility into pipeline state and enabling fast, reliable, and consistent software delivery.
Pipeline Structure: Stages, Actions, and Transitions
A CodePipeline pipeline is made up of stages, each containing one or more actions. Actions can run sequentially or in parallel within a stage.
| Concept | Description | Example |
|---|---|---|
| Pipeline | Top-level workflow definition | my-app-pipeline |
| Stage | Logical grouping of actions | Source, Build, Test, Deploy |
| Action | Unit of work within a stage | CodeBuild build, CodeDeploy deploy |
| Transition | Link between stages - can be disabled | Pause before production deploy |
| Artifact | Data passed between actions via S3 | Source zip, compiled binaries |
| Input artifact | Artifact consumed by an action | Source code zip for build action |
| Output artifact | Artifact produced by an action | Build output passed to deploy |
Every pipeline needs at least two stages. The first stage must be a Source stage. Action categories include: Source, Build, Test, Deploy, Approval, and Invoke.
Actions within a stage can run in parallel by giving them the same "run order" value. Actions with different run orders execute sequentially within the stage. This is useful for running multiple tests in parallel before a deploy.
Source Action Providers
The Source stage defines what triggers the pipeline and where code comes from. CodePipeline V2 (the current version) supports these providers:
| Provider | Trigger Mechanism | Auth Method | Notes |
|---|---|---|---|
| CodeCommit | EventBridge rule on repository events | IAM service role | Native integration, no setup needed |
| S3 | EventBridge on bucket PUT | IAM service role | Good for pre-packaged artifacts |
| GitHub (via CodeStar Connections) | Webhook via CodeStar Connection | OAuth app or GitHub App | Requires connection approval in console |
| GitHub Enterprise | Webhook via CodeStar Connection | GitHub App on GHE server | Self-hosted GitHub support |
| GitLab (via CodeStar Connections) | Webhook via CodeStar Connection | GitLab OAuth | Same connection mechanism as GitHub |
| Bitbucket (via CodeStar Connections) | Webhook via CodeStar Connection | Bitbucket OAuth | Atlassian Cloud only |
| ECR | EventBridge on image push | IAM service role | Trigger pipeline when Docker image is pushed |
CodeStar Connections require a one-time manual approval step in the AWS console before they become AVAILABLE. A connection in PENDING state will silently block your pipeline. Always verify connection status after creating via Terraform or CloudFormation.
Integrations: Build, Test, and Deploy Actions
CodePipeline integrates with a wide range of AWS services and third-party tools as action providers:
| Category | Provider | What It Does |
|---|---|---|
| Build | CodeBuild | Run buildspec.yml in managed build container |
| Build | Jenkins | Trigger Jenkins job, wait for result |
| Test | CodeBuild | Run test suite, output test reports |
| Test | AWS Device Farm | Run mobile/web UI tests on real devices |
| Deploy | CodeDeploy | EC2, Lambda, ECS, on-premises deployments |
| Deploy | CloudFormation | Create/update/delete stacks |
| Deploy | Elastic Beanstalk | Deploy to EB environment |
| Deploy | ECS | Update ECS service (standard deploy) |
| Deploy | S3 | Sync static files to S3 bucket |
| Invoke | Lambda | Invoke Lambda function with custom logic |
| Invoke | Step Functions | Start a Step Functions state machine |
| Approval | Manual Approval | Pause pipeline, send SNS notification, wait for human |
The Lambda invoke action is extremely powerful - it lets you add any custom step (Slack notifications, custom validation, ticket creation) to your pipeline without needing a separate service. The Lambda function receives pipeline execution context and must call PutJobSuccessResult or PutJobFailureResult.
Pipeline V1 vs V2: Key Differences
CodePipeline has two execution mode versions. New pipelines default to V2.
| Feature | V1 | V2 |
|---|---|---|
| Execution mode | SUPERSEDED only | QUEUED, PARALLEL, or SUPERSEDED |
| Pipeline-level variables | Not supported | Supported |
| Stage-level variables | Not supported | Supported |
| Trigger filtering | Branch only (CodeCommit) | Branch, tag, file path filters |
| Pricing | $1/pipeline/month (first 1 free) | $0.002 per action execution minute |
| Rollout | Legacy | Current default |
Execution modes in V2:
| Mode | Behavior | Use Case |
|---|---|---|
| SUPERSEDED | New run supersedes in-progress run | Rapid commits - only latest matters |
| QUEUED | Runs queue, execute one at a time in order | Sequential releases, audit trail |
| PARALLEL | Multiple runs execute simultaneously | Independent feature branch builds |
Common Pipeline Patterns
Real-world pipelines often follow these proven patterns:
| Pattern | Structure | Use Case |
|---|---|---|
| Simple CI/CD | Source -> Build -> Deploy | Small apps, single environment |
| Multi-environment | Source -> Build -> Deploy Dev -> Manual Approval -> Deploy Prod | Controlled production releases |
| Parallel tests | Source -> Build -> [Unit Tests | Integration Tests] -> Deploy | Faster feedback, parallel test suites |
| Fan-out multi-region | Source -> Build -> Deploy us-east-1 -> Deploy eu-west-1 | Multi-region deployments |
| IaC pipeline | Source -> Terraform Plan -> Manual Approval -> Terraform Apply | Infrastructure changes with review |
# CLI - trigger a pipeline manually
aws codepipeline start-pipeline-execution --name my-app-pipeline
# Get pipeline state
aws codepipeline get-pipeline-state --name my-app-pipeline
# Approve a manual approval action
aws codepipeline put-approval-result \
--pipeline-name my-app-pipeline \
--stage-name Approval \
--action-name ManualApproval \
--result summary="Approved after testing",status=Approved \
--token <token-from-get-pipeline-state>Interview Focus Points
- 1What is the structure of a CodePipeline pipeline - stages, actions, artifacts?
- 2How does CodePipeline trigger on a GitHub repository - what mechanism is used?
- 3What is the difference between V1 and V2 pipeline execution modes?
- 4How do you pause a pipeline before production - what action type handles this?
- 5How do you pass data between pipeline actions?
- 6How would you design a multi-environment deployment pipeline with a manual approval gate?
- 7What is a CodeStar Connection and what can go wrong with it?
- 8How do Lambda invoke actions work in a pipeline and what must the Lambda return?
- 9How would you implement parallel testing stages in CodePipeline?
- 10What triggers a CodePipeline execution and how can you filter triggers in V2?