# Continuous Delivery with AWS CodePipeline and CodeDeploy

> Chapter 10 of the Courseiva AWS-DEVOPS-PROFESSIONAL curriculum — https://courseiva.com/learn/aws-devops-professional/continuous-delivery-with-codepipeline-and-codedeploy

**Official objective:** 1.3 — Automate release pipelines using CodePipeline and CodeDeploy

## Introduction

If you cannot deploy new software features to customers quickly and safely, your business falls behind competitors who can. This chapter explains how AWS CodePipeline and CodeDeploy automatically move your code from a developer's laptop to live servers without human errors or late-night emergency rollbacks. For the DOP-C02 exam, mastering these two services is essential because the test expects you to design and troubleshoot automated release pipelines that deliver changes reliably.

## The 14-Day Subscription Box Fulfilment Analogy

14 days is the exact lead time for a subscription box service to design, manufacture, and ship a monthly crate to 10,000 subscribers. 

Before automation, a warehouse manager named Priya manually handled every step. She received design files by email, printed labels on a shared office printer, walked the printout to the assembly line, watched workers pack boxes, then drove the finished pallets to the shipping dock herself. One missed email, one smudged label, or one traffic jam on the way to the dock delayed the entire batch. Subscribers complained, and Priya worked 14-hour days. 

Then the company adopted an automated fulfilment pipeline. Now, when a designer uploads a new crate blueprint to the shared drive (CodePipeline source), a sensor automatically triggers the 3D printer (build stage), the assembly robot picks items from bins (test stage), a label printer fires automatically (deploy stage), and a conveyor belt delivers crates to the right truck bay (production deployment). Every stage has a rollback button — if the label printer jams, the conveyor reverses, and the system alerts Priya on her phone. The pipeline processes the 10,000 crates in 4 hours, not 14 days.

## Core explanation

Continuous Delivery (CD) is the practice of automatically preparing every code change for release to production so that a human can approve deployment with one click. AWS CodePipeline and AWS CodeDeploy are the two AWS services that make CD possible. 

CodePipeline is a fully managed continuous delivery service. Think of it as a conveyor belt for your software. You define a pipeline that has stages — source, build, test, deploy — and each stage contains one or more actions. When a developer pushes new code to a source repository like GitHub or AWS CodeCommit, CodePipeline automatically detects the change, fetches the code, runs it through each stage, and either deploys it or stops if something fails. You do not have to manage servers or scripts to orchestrate this flow. CodePipeline replaces the old way: a team member manually copying files to a server or running deployment scripts by hand. 

CodeDeploy is a deployment service that automates the actual process of putting your application onto compute resources. Those resources can be Amazon EC2 instances (virtual servers), AWS Lambda functions (serverless code), or on-premises servers. CodeDeploy tracks which version of your application is running on each target and can roll back to a previous version if the new deployment fails health checks. 

How they work together: CodePipeline triggers CodeDeploy as an action in the deploy stage. CodePipeline passes the built application artifact (a zip file or container image) to CodeDeploy, and CodeDeploy pushes that artifact to the target servers according to a deployment strategy you choose. 

Key concepts in CodeDeploy: 

- Deployment Group: A set of target instances or Lambda functions that receive the same application revision. You can tag EC2 instances with environment names (e.g., 'Production', 'Staging') and CodeDeploy deploys to all instances that match the tag. 
- Application Revision: The version of your code plus an AppSpec file (a YAML or JSON configuration file) that tells CodeDeploy how to install and start the application. 
- AppSpec File: The instruction manual. It defines lifecycle event hooks like BeforeInstall, AfterInstall, ApplicationStart, and ValidateService. CodeDeploy runs your custom scripts at each hook. 
- Deployment Strategies: 
  - In-Place: CodeDeploy stops the application on each instance, installs the new version, and restarts it. Traffic is briefly interrupted. 
  - Blue/Green: CodeDeploy launches a new set of instances (the green environment), installs the new version there, then shifts traffic from the old instances (blue) to the green ones. This allows zero-downtime deployment and easy rollback by switching traffic back. 
  - Canary: A linear or percentage-based traffic shift from old to new instances. Useful for testing new code with a small percentage of users before full rollout. 

CodePipeline stages and actions: 
- Source Stage: Connects to your code repository (CodeCommit, GitHub, Bitbucket, S3). Whenever a new commit or pull request merge occurs, the pipeline starts. 
- Build Stage: Uses a build service like AWS CodeBuild to compile code, run unit tests, and produce a deployable artifact. 
- Test Stage: Runs integration tests, security scans, or performance tests using services like AWS CodeBuild or third-party tools. 
- Deploy Stage: Calls CodeDeploy (or AWS Elastic Beanstalk, AWS CloudFormation, Amazon ECS) to push the artifact to the target environment. 
- Approvals: You can add manual approval actions between stages. For example, require a senior developer to click 'Approve' before the deploy stage runs. 

Why this replaces the old way: Before automated pipelines, teams used scripts that ran on a single engineer's laptop. If that engineer left the company, the deployment process broke. Pipelines also eliminate the risk of 'configuration drift' — when a production server has different software versions than what was tested. CodePipeline ensures every deployment uses the exact artifact that passed all automated tests.

## Real-world context

An IT professional, let's call her Maria, works for an e-commerce company that sells handmade furniture. The website runs on 20 Amazon EC2 instances behind an Application Load Balancer. Maria's job is to ensure that every update to the website — new product pages, payment gateway changes, security patches — happens without downtime and without manual copying of files. 

Here is how Maria uses CodePipeline and CodeDeploy in her daily work: 

Step 1: Maria creates a CodePipeline named 'Website-Release-Pipeline'. The source stage connects to a GitHub repository where the development team stores the website code. Every time a developer merges a pull request to the 'main' branch, the pipeline triggers automatically. 

Step 2: The build stage runs a CodeBuild project. CodeBuild compiles the static assets (HTML, CSS, JavaScript) and runs unit tests. If a test fails, the pipeline stops, and Maria receives an email notification from Amazon SNS (Simple Notification Service). She can inspect the logs in CodeBuild to find the failing test. 

Step 3: The deploy stage uses CodeDeploy with a Blue/Green deployment strategy. CodeDeploy launches two new EC2 instances (green fleet) from a golden Amazon Machine Image (AMI). It installs the new website code on these instances using the AppSpec file, which runs a script to clear the CDN cache. CodeDeploy then registers the green instances with the load balancer and deregisters the blue instances. The load balancer gradually shifts traffic — first 10%, then if health checks pass, 100%. If the ValidateService hook fails (e.g., the homepage returns a 500 error), CodeDeploy automatically terminates the green instances and re-registers the blue instances, rolling back in under two minutes. 

Step 4: Maria monitors the pipeline through the AWS Management Console. She can see a visual flow diagram showing each stage's status — green checkmark for success, red X for failure. She also sets up a CloudWatch alarm that pages her if the pipeline fails more than twice in an hour. 

Common tools Maria uses alongside CodePipeline: 
- AWS CloudFormation: To define the EC2 instances, load balancer, and security groups as infrastructure as code. The pipeline can deploy CloudFormation stacks to update the infrastructure. 
- AWS Systems Manager Parameter Store: To store database connection strings and API keys. The pipeline retrieves these at deploy time rather than hardcoding them. 
- AWS CodeArtifact: A package repository for dependencies. The build stage pulls dependencies from CodeArtifact to ensure version consistency. 

Maria's real-world benefit: Before pipelines, a deployment took 3 hours and required two people. Now it takes 12 minutes and happens automatically. Maria can focus on improving the deployment playbook rather than babysitting manual steps.

## Exam focus

The DOP-C02 exam dedicates a significant portion of questions to CodePipeline and CodeDeploy, especially in the context of designing automated release pipelines. Here is exactly what you need to know. 

Exam topics tested: 
- Pipeline structure and stage types (source, build, test, deploy, approval) 
- CodeDeploy deployment strategies: In-Place vs Blue/Green vs Canary — when to use each 
- AppSpec file hooks (BeforeInstall, AfterInstall, ApplicationStart, ValidateService) and their order 
- Integration with other services: CodeCommit, CodeBuild, CloudFormation, Lambda, EC2, Auto Scaling Groups 
- Rollback mechanisms: automatic rollback on health check failure vs manual rollback 
- Cross-account and cross-region pipelines (they love testing this) 
- Artefact storage: S3 bucket policy requirements for artefacts 
- Pipeline notifications via SNS and CloudWatch Events even

Traps the exam sets: 
- They will describe a deployment scenario and ask which strategy achieves zero downtime. The trap: Blue/Green does, In-Place does not unless you use a rolling update with careful health checks. 
- They will present a scenario where a pipeline stage fails, and ask what happens to the artefact. The correct answer is usually that the artefact remains in the S3 artefact store but the pipeline stops. 
- They will describe an AppSpec file with hooks in the wrong order (e.g., ApplicationStart before BeforeInstall). The exam tests whether you know the correct sequence. 
- They will ask about IAM permissions for CodePipeline to access CodeDeploy. The answer involves a service role with a trust policy allowing codepipeline.amazonaws.com and permissions to deploy. 
- They will test cross-region pipelines: the source region stores artefacts in an S3 bucket in that region, but the deploy stage must have access to a bucket in the target region. The correct pattern is to use separate S3 buckets per region with appropriate bucket policies. 

Key definitions to memorise: 

- Deployment Group: A logical grouping of instances or Lambda functions that receive the same application revision. 
- Application Revision: A specific version of the application code and AppSpec file. Identified by a label or timestamp. 
- Lifecycle Event Hooks: Scripts that run at specific points during deployment. The default order is: ApplicationStop, DownloadBundle, BeforeInstall, Install, AfterInstall, ApplicationStart, ValidateService. 
- Blue/Green Deployment: A deployment method that launches new instances alongside the old ones, shifts traffic, then terminates the old instances. 
- In-Place Deployment: A deployment that updates the existing instances one by one, stopping the application on each instance during the update. 

Question types: 
- Scenario-based multiple choice: 'A company wants to deploy a new web application to 50 EC2 instances with zero downtime. Which CodeDeploy deployment configuration should be used?' 
- Troubleshooting: 'A pipeline fails at the deploy stage with an insufficient permissions error. Which IAM role needs to be updated?' 
- Best practice: 'A team uses an S3 bucket for pipeline artefacts. What configuration prevents accidental deletion of artefacts during deployment?' (Answer: bucket versioning enabled). 

What you must memorise: the exact order of AppSpec hooks, the difference between 'run order' and 'fail condition', and the fact that CodePipeline does not perform the deployment itself — it invokes CodeDeploy or another deploy provider.

## Step by step

1. **Source Stage Triggered** — A developer pushes new code to a GitHub repository. CodePipeline detects the change via a webhook or periodic polling and fetches the code from the repository. This replaces manual file transfers and ensures the pipeline always uses the latest approved code.
2. **Build and Test Stage** — CodePipeline invokes AWS CodeBuild (or a third-party build tool like Jenkins). CodeBuild compiles the code, runs unit tests, and produces a deployable artefact (e.g., a .zip file). This stage is critical because it catches errors early, preventing broken code from reaching production.
3. **Artefact Stored in S3** — The build output artefact is uploaded to an S3 bucket designated as the pipeline artefact store. By default, artefacts are stored with a version ID. Enabling bucket versioning allows you to retrieve any previous artefact, which is essential for rollback.
4. **Deploy Stage Execution** — CodePipeline triggers the deploy action, which calls CodeDeploy. CodeDeploy retrieves the artefact from S3 and pushes it to the target deployment group using the instructions in the AppSpec file. The deployment group could be EC2 instances tagged with 'Environment: Production' or a Lambda alias.
5. **Lifecycle Event Hooks Execute** — CodeDeploy runs scripts at each defined hook: BeforeInstall (e.g., backup old version), Install (extract artefact), AfterInstall (set permissions), ApplicationStart (restart service), and ValidateService (check if the application responds correctly). If any hook script fails, the deployment can be configured to roll back automatically.
6. **Traffic Shift and Health Check** — For Blue/Green deployments, CodeDeploy registers the new instances with the load balancer and shifts traffic gradually. The load balancer performs health checks on the new instances. If the health check fails, CodeDeploy automatically terminates the new instances and re-routes all traffic to the old ones, completing a rollback.
7. **Final Notification and Clean-up** — After successful deployment, CodePipeline can trigger an SNS notification (e.g., email to the release team). For Blue/Green deployments, CodeDeploy can optionally terminate the old instances after a cooldown period to allow quick rollback if needed. The pipeline remains ready for the next code change.

## Comparisons

### CodeDeploy In-Place Deployment vs CodeDeploy Blue/Green Deployment

**CodeDeploy In-Place Deployment:**
- Updates existing instances one by one
- Application stops briefly during each instance update
- Rollback re-deploys the old version on the same instances

**CodeDeploy Blue/Green Deployment:**
- Launches new instances alongside old ones
- Zero downtime during traffic shift
- Fast rollback by re-directing traffic to the old instances

### CodePipeline Source: AWS CodeCommit vs CodePipeline Source: GitHub

**CodePipeline Source: AWS CodeCommit:**
- Fully managed by AWS within your account
- No external webhook configuration needed
- Native integration with other AWS services (e.g., IAM)

**CodePipeline Source: GitHub:**
- Third-party service external to AWS
- Requires a GitHub App or OAuth token for connection
- Webhook or polling triggers the pipeline

### Manual Deployment via SSH vs Automated Deployment via CodeDeploy

**Manual Deployment via SSH:**
- Requires an engineer to manually copy files
- High risk of human error (wrong server, wrong version)
- No audit trail of who deployed what

**Automated Deployment via CodeDeploy:**
- Fully automated via pipeline triggers
- Consistent deployment process every time
- Full audit log in CodeDeploy and CloudTrail

### CodePipeline Manual Approval Action vs CodePipeline Automated Deploy Action

**CodePipeline Manual Approval Action:**
- Requires a human to click Approve before proceeding
- Used for compliance or high-risk changes
- Pipeline pauses until approval is granted

**CodePipeline Automated Deploy Action:**
- No human intervention needed
- Used for routine, low-risk changes
- Pipeline proceeds immediately after previous stage succeeds

### CodeDeploy EC2 Deployment Group vs CodeDeploy Lambda Deployment Group

**CodeDeploy EC2 Deployment Group:**
- Targets specific EC2 instances by tag
- Uses lifecycle hooks to install/stop/start services
- Supports In-Place and Blue/Green strategies

**CodeDeploy Lambda Deployment Group:**
- Targets a Lambda function alias
- No lifecycle hooks — uses traffic shifting only
- Supports Canary, Linear, and All-at-Once strategies

### CodePipeline Artefact Store (S3 with versioning) vs CodePipeline Artefact Store (S3 without versioning)

**CodePipeline Artefact Store (S3 with versioning):**
- Preserves every version of the artefact
- Enables rollback to any previous artefact
- Prevents accidental overwrites

**CodePipeline Artefact Store (S3 without versioning):**
- Only the latest artefact is kept
- Cannot roll back to a specific version
- Risk of losing artefact if overwritten

## Diagram

_A flowchart showing the steps of a CodePipeline from source code push through build, artefact storage, deployment, health check, and rollback._

```mermaid
flowchart TD
    A[Developer Pushes Code] --> B[Source Stage: CodeCommit/GitHub]
    B --> C[Build Stage: CodeBuild]
    C --> D[Artefact stored in S3]
    D --> E[Deploy Stage: CodeDeploy]
    E --> F[Deployment Group: EC2 / Lambda]
    F --> G[AppSpec Hooks Execute]
    G --> H{Health Check Pass?}
    H -->|Yes| I[Traffic Shift to New Version]
    H -->|No| J[Auto Rollback to Old Version]
    I --> K[Success Notification via SNS]
    J --> K
```

## Common misconceptions

- **Misconception:** CodePipeline deploys the application directly to servers without needing any other service. **Reality:** CodePipeline orchestrates the flow but does not perform the actual deployment. It passes the artefact to a provider like CodeDeploy, Elastic Beanstalk, CloudFormation, or ECS. (New learners see 'pipeline' and assume it includes the deployment mechanism. In reality, CodePipeline is just the coordinator; you must configure a deploy action that points to a separate service.)
- **Misconception:** A Blue/Green deployment in CodeDeploy requires manual traffic switching. **Reality:** CodeDeploy automates traffic shifting using the load balancer. You configure a percentage shift or a linear ramp, and CodeDeploy handles the routing. (In some older deployment tools, traffic switching was manual. AWS CodeDeploy fully automates it, so the exam expects you to know this.)
- **Misconception:** CodePipeline can only use AWS CodeCommit as the source. **Reality:** CodePipeline supports multiple source providers: AWS CodeCommit, GitHub (including GitHub Enterprise), Bitbucket, and Amazon S3. (The exam often presents a scenario with a GitHub repository and asks how to integrate it. Beginners might assume only CodeCommit works, but the exam tests multi-provider awareness.)
- **Misconception:** Rollback in CodeDeploy restores the previous version immediately with zero downtime. **Reality:** Rollback in CodeDeploy re-deploys the previous revision, which takes time. During the rollback, the application may experience downtime depending on the deployment strategy. Blue/Green rollback is faster because it re-uses the old instances that are still running. (The word 'rollback' sounds instant. But it requires a full deployment cycle, so the exam tests whether you understand the time cost.)
- **Misconception:** You must write custom scripts for every deployment action in CodeDeploy. **Reality:** CodeDeploy provides built-in actions like 'DownloadBundle' and 'Install' that handle standard tasks. You only need custom scripts in the lifecycle event hooks for special behaviour. (Documentation emphasises the AppSpec file hooks, so beginners think they must script everything. CodeDeploy automates the core steps; hooks are for customisation.)
- **Misconception:** CodePipeline stages must run sequentially, one after another. **Reality:** You can configure parallel actions within a stage. For example, you can run integration tests and security scans at the same time in the test stage. (The visual pipeline diagram shows a linear flow, so people assume it is strictly serial. The exam tests whether you know that parallel actions are allowed to speed up the pipeline.)

## Key takeaways

- CodePipeline orchestrates the release workflow but does not deploy code itself — it delegates the deploy action to CodeDeploy or another service.
- CodeDeploy uses an AppSpec file (YAML or JSON) to define lifecycle event hooks that run custom scripts during deployment.
- Blue/Green deployments launch new instances alongside old ones, then shift traffic, enabling zero-downtime deployments and fast rollback.
- In-Place deployments update existing instances one by one, which may cause brief downtime if the application stops during the update.
- CodePipeline artefact store is an S3 bucket — you must enable versioning on that bucket to prevent accidental overwrites and support rollback.
- When a pipeline stage fails, the pipeline stops and the artefact remains in the S3 bucket; no automatic retry occurs unless you configure a retry action.
- Cross-region pipelines require separate S3 artefact buckets in each region with appropriate bucket policies for cross-account access.
- Manual approval actions in CodePipeline block the pipeline until a specified approver clicks 'Approve' or 'Reject' — useful for compliance gates.
- CodeDeploy can deploy to EC2 instances, on-premises servers, Lambda functions, and Amazon ECS services — not just EC2.

## FAQ

**What is the difference between CodePipeline and CodeDeploy?**

CodePipeline is the orchestration service that manages the overall release workflow from source to deployment. CodeDeploy is the service that actually installs your application onto the target compute resources. CodePipeline calls CodeDeploy as one of its actions.

**Does CodePipeline support GitHub as a source?**

Yes, CodePipeline integrates natively with GitHub, GitHub Enterprise Server, and GitHub Cloud. You set up a connection using a GitHub App or OAuth token, and the pipeline triggers when a new commit or pull request merge occurs on the specified branch.

**How do I roll back a failed deployment in CodeDeploy?**

You can configure automatic rollback in the deployment group settings by specifying a CloudWatch alarm or a failed health check as the rollback trigger. You can also manually trigger a rollback from the CodeDeploy console or CLI. Rollback re-deploys the previous application revision.

**What permissions does CodePipeline need to access CodeDeploy?**

CodePipeline uses an IAM service role with a trust policy that allows codepipeline.amazonaws.com. The role must have permissions to call CodeDeploy actions (e.g., CreateDeployment, GetDeployment) and pass the CodeDeploy service role if required.

**Can CodeDeploy deploy to Lambda functions?**

Yes, CodeDeploy supports Lambda deployments. You create a deployment group for a Lambda alias, and CodeDeploy shifts traffic between the old and new Lambda versions using canary, linear, or all-at-once traffic shifting.

**What happens if a pipeline stage fails?**

The pipeline stops and does not proceed to the next stage. The artefact remains in the S3 bucket. You can view the failure reason in the pipeline console, fix the issue (e.g., fix a test failure), and retry the stage manually. No automatic retry occurs unless you configure a retry action in the stage.

**What is the AppSpec file in CodeDeploy?**

The AppSpec file is a YAML or JSON configuration file that tells CodeDeploy how to install and start your application. It defines lifecycle event hooks (scripts that run at specific points), file permissions, and container image information for ECS deployments.

**Can I use CloudFormation with CodePipeline?**

Yes, you can add a CloudFormation deploy action in CodePipeline. The pipeline can create or update a CloudFormation stack as part of the deploy stage, allowing you to manage infrastructure and application code together.

## Check your understanding

1. **A company wants to deploy a new web application to a fleet of EC2 instances with zero downtime and the ability to roll back instantly. Which CodeDeploy deployment strategy should they use?**

   Answer: Blue/Green deployment, because it launches new instances alongside the old ones, shifts traffic, and allows instant rollback by switching traffic back to the old instances.

2. **What is the purpose of the AppSpec file in CodeDeploy?**

   Answer: The AppSpec file tells CodeDeploy how to install and start the application, including lifecycle event hooks (e.g., BeforeInstall, ApplicationStart) and file permissions.

3. **If CodeDeploy is configured with automatic rollback and the ValidateService hook fails, what happens?**

   Answer: CodeDeploy automatically re-deploys the previous application revision to the instances. For Blue/Green deployments, it terminates the new instances and re-routes traffic to the old ones.

4. **A CodePipeline's build stage fails because a unit test fails. What happens to the pipeline?**

   Answer: The pipeline stops and does not proceed to the deploy stage. The artefact from the last successful build is still available in the S3 artefact store.

5. **What IAM configuration does CodePipeline need to invoke CodeDeploy?**

   Answer: CodePipeline must have a service role with a trust policy allowing codepipeline.amazonaws.com, and the role must have permissions to call CodeDeploy actions (e.g., CreateDeployment, GetDeployment).

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/aws-devops-professional/continuous-delivery-with-codepipeline-and-codedeploy