CI/CD (CodeCommit, CodeBuild, CodeDeploy, CodePipeline)#

Shipping software manually — SSHing into servers, copying files, running scripts by hand — is slow, error-prone, and impossible to scale. CI/CD (Continuous Integration / Continuous Delivery) solves this by automating the entire journey from a code commit to a running deployment. AWS provides a suite of fully managed services that each handle one stage of this pipeline: CodeCommit stores your source code, CodeBuild compiles and tests it, CodeDeploy pushes it to your infrastructure, and CodePipeline orchestrates all of these steps into a single automated workflow.

CodeCommit#

CodeCommit 🔗 is AWS’s managed Git hosting service. It behaves like GitHub or Bitbucket, but runs entirely within your AWS account — meaning your repositories benefit from IAM-based access control, encryption at rest and in transit, and VPC isolation without any extra setup.

Key concepts to know:

• Repositories are the core resource. You create one per project and interact with it using standard Git commands.
• Branch policies let you protect branches (e.g., main) by requiring pull request approvals before merging.
• Triggers and notifications allow CodeCommit to invoke a Lambda function or send an SNS notification when specific events occur (push, pull request created, etc.) — useful for kicking off a pipeline or alerting a team.

Exam note: AWS announced in July 2024 that CodeCommit is no longer available to new customers. Existing customers can continue using it, and it still appears on the DVA-C02 exam. For new projects, AWS recommends using CodeStar Connections to connect CodePipeline to GitHub or Bitbucket (covered below).

CodeBuild#

CodeBuild 🔗 is a fully managed build service. You give it your source code and a set of instructions; it spins up a temporary, isolated container, runs your build, and tears the environment down when done. You pay only for build minutes used — there are no idle servers.

The buildspec.yml file 🔗 is the heart of every CodeBuild project. It lives at the root of your repository and defines exactly what CodeBuild does. Its structure has four main phases:

version: 0.2

phases:
  install:
    commands:
      - npm install
  pre_build:
    commands:
      - echo Running tests...
      - npm test
  build:
    commands:
      - npm run build
  post_build:
    commands:
      - echo Build complete

artifacts:
  files:
    - '**/*'
  base-directory: dist

cache:
  paths:
    - node_modules/**/*

• install — set up the environment (install runtimes, tools).
• pre_build — preparation steps like logging into ECR or running linters.
• build — the main compilation or packaging step.
• post_build — cleanup, pushing Docker images, sending notifications.

The artifacts block tells CodeBuild what to package up and send to S3 (or pass to the next pipeline stage). The cache block lets you persist directories — like node_modules — between builds to dramatically speed up build times 🔗.

Environment variables can be injected into builds as plaintext, or referenced securely from SSM Parameter Store or Secrets Manager directly in the buildspec, so you never hardcode credentials 🔗.

CodeDeploy#

CodeDeploy 🔗 automates the actual delivery of your application to its target compute. Unlike CodeBuild (which builds), CodeDeploy only deploys — it takes an artifact and installs it somewhere. It supports three deployment targets:

• EC2 / On-Premises — a CodeDeploy agent runs on each instance and pulls the revision from S3 or GitHub.
• AWS Lambda — shifts traffic between Lambda function versions using aliases.
• Amazon ECS — replaces task definitions in a service, supporting blue/green deployments.

The appspec.yml file 🔗 is CodeDeploy’s equivalent of the buildspec — it describes how to install the application and defines lifecycle hooks: scripts that run at specific points during the deployment (e.g., before installation, after installation, during validation). For EC2 deployments a typical appspec looks like:

version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/myapp
hooks:
  BeforeInstall:
    - location: scripts/stop_server.sh
  AfterInstall:
    - location: scripts/start_server.sh
  ValidateService:
    - location: scripts/validate.sh

Deployment configurations control the rollout speed for EC2/On-Premises targets 🔗:

• AllAtOnce — deploys to all instances simultaneously. Fastest, but causes downtime if something goes wrong.
• HalfAtATime — deploys to 50% of instances at a time. Maintains partial availability.
• OneAtATime — deploys to one instance at a time. Slowest, safest — availability is nearly uninterrupted.

Lambda deployment strategies work differently — they shift traffic gradually using Lambda aliases 🔗:

• Linear — shifts traffic in equal increments at regular intervals (e.g., Linear10PercentEvery3Minutes).
• Canary — shifts a small percentage first, waits, then shifts the rest (e.g., Canary10Percent5Minutes sends 10% of traffic to the new version, then 100% after 5 minutes).
• AllAtOnce — switches 100% of traffic immediately.

Linear and Canary are the safer choices because CodeDeploy can automatically roll back if a CloudWatch alarm triggers during the shift.

CodePipeline#

CodePipeline 🔗 is the orchestration layer that connects all the pieces. A pipeline is made up of stages (e.g., Source → Build → Test → Deploy), and each stage contains one or more actions that do the actual work (invoking CodeBuild, triggering CodeDeploy, etc.). Artifacts are the files passed between stages — stored in an S3 bucket that CodePipeline manages automatically.

A minimal pipeline for a web application might look like:

1. Source stage — watches a CodeCommit branch (or GitHub via CodeStar Connections) for new commits.
2. Build stage — invokes a CodeBuild project; the output artifact is a deployment bundle.
3. Deploy stage — calls CodeDeploy to push the bundle to EC2 or Lambda.

Transitions between stages can be enabled or disabled manually — useful for pausing a pipeline between environments. Manual approval actions 🔗 let you insert a human gate into any stage: the pipeline pauses and sends an SNS notification until someone approves or rejects via the console or API. This is commonly used before deploying to production.

Beyond CodeCommit/CodeBuild/CodeDeploy, CodePipeline integrates natively with CloudFormation (to deploy infrastructure stacks), Elastic Beanstalk (to deploy application versions), and third-party tools like Jenkins.

CodeStar Connections#

CodeStar Connections 🔗 is the mechanism for authorizing CodePipeline to pull source code from external providers like GitHub, GitLab, or Bitbucket. You create a connection once (which involves an OAuth handshake with the provider), then reference it as the source action in any pipeline. This is now the standard replacement for the deprecated GitHub v1 source action.

CodeArtifact#

CodeArtifact 🔗 is a fully managed artifact repository — think of it as a private npm registry, Maven repository, or PyPI index hosted inside your AWS account. It solves two problems: keeping approved packages internal to your organisation, and caching public packages from upstream registries (npm, Maven Central, PyPI) so builds don’t break when an external package disappears. CodeBuild can be configured to pull dependencies from CodeArtifact instead of the public internet, improving both security and build reliability.

CodeGuru Reviewer#

CodeGuru Reviewer 🔗 uses machine learning to analyse your Java or Python code and surface potential bugs, security vulnerabilities, and deviations from AWS best practices. It integrates with CodeCommit (and GitHub via CodeStar Connections) and posts findings as pull request comments — acting as an automated code reviewer that runs on every PR without any manual effort.

AWS Copilot#

AWS Copilot 🔗 is a CLI tool designed to make deploying containerised applications on ECS (and App Runner) straightforward. Rather than hand-crafting task definitions, services, and load balancers, you run copilot init and Copilot provisions the entire environment — VPC, ECS cluster, ECR repository, load balancer — and creates a CI/CD pipeline for you. It targets teams that want the power of ECS without the operational overhead of configuring every resource manually.