CI/CD Pipelines and Advanced Deployment Strategies

Learning Objectives

After studying this guide, you should be able to:

• Distinguish between Continuous Integration (CI) and Continuous Delivery/Deployment (CD).
• Evaluate the trade-offs between all-at-once, rolling, blue/green, and canary deployment strategies.
• Identify the appropriate AWS service (CodeDeploy, Elastic Beanstalk, App Runner) for a given deployment requirement.
• Implement immutable infrastructure principles using Infrastructure as Code (IaC) tools.

Key Terms & Glossary

• CI (Continuous Integration): The practice of frequently merging code changes into a central repository, followed by automated builds and tests.
• CD (Continuous Delivery/Deployment): The process of automatically packaging and preparing code for a release to production (Delivery) or automatically releasing every change that passes the pipeline (Deployment).
• Immutable Infrastructure: A strategy where servers/resources are never modified after they are deployed. If a change is needed, new servers are built from a common image.
• In-Place Deployment: Updating the application code on existing running instances.
• Traffic Shifting: The process of migrating requests from an old version of an application to a new version using a load balancer or DNS.

The "Big Idea"

The primary goal of CI/CD is to increase velocity without sacrificing stability. By automating the build, test, and deployment phases, organizations reduce human error and ensure that software is always in a releasable state. The choice of deployment strategy is the final "risk management" lever, allowing a team to balance cost, speed, and the impact of potential failures.

Formula / Concept Box

Hierarchical Outline

• I. The CI/CD Lifecycle
  • A. Continuous Integration (CI)
    • Code Commit (Source Control)
    • Automated Build (Compiling/Unit Testing)
    • Quality Gates (Linting/Security Scanning)
  • B. Continuous Deployment (CD)
    • Staging/UAT (User Acceptance Testing)
    • Production Rollout
• II. Deployment Strategies
  • A. In-Place Updates (All-at-once, Rolling)
  • B. Side-by-Side Updates (Blue/Green, Canary)
• III. AWS Tooling Spectrum
  • A. Opinionated/Managed: AWS App Runner, Elastic Beanstalk
  • B. Full Control: AWS CodeDeploy, CloudFormation/CDK

Visual Anchors

CI/CD Pipeline Flowchart

Blue/Green Environment Architecture

\begin{tikzpicture}[node distance=2cm, every node/.style={rectangle, draw, minimum width=2.5cm, minimum height=1cm, align=center}] % Elements \node (elb) [rounded corners] {Elastic Load \ Balancer}; \node (blue) [below left of=elb, xshift=-1cm, fill=blue!20] {Blue Fleet \ (v1.0 - Active)}; \node (green) [below right of=elb, xshift=1cm, fill=green!20] {Green Fleet \ (v1.1 - Idle)};

% Connections \draw[thick, ->] (elb) -- (blue) node[midway, left] {100% Traffic}; \draw[thick, dashed, ->] (elb) -- (green) node[midway, right] {0% Traffic};

% Labels \node[draw=none, below of=blue, yshift=1cm] {Existing Production}; \node[draw=none, below of=green, yshift=1cm] {New Release}; \end{tikzpicture}

Definition-Example Pairs

• Canary Deployment: Releasing to a small subset of users before the general public.
  • Example: A social media app rolls out a new UI to 5% of users in the US to monitor error rates before updating the remaining 95%.
• Linear Deployment: Increasing traffic to a new version at a steady, fixed rate over time.
  • Example: Using CodeDeploy to shift 10% of traffic to a new Lambda function every 10 minutes.
• Infrastructure as Code (IaC): Defining your environment using machine-readable files.
  • Example: Using an AWS CloudFormation template to ensure the Production environment is identical to the UAT environment.

Worked Examples

Scenario: High-Stakes E-commerce Release

Problem: A company needs to deploy a major update to their checkout service. They cannot afford any downtime, and if a bug is found, they must be able to revert to the previous version in seconds.

Solution:

1. Select Blue/Green Deployment.
2. Mechanism: Use AWS CodeDeploy with an Application Load Balancer.
3. Steps:
   • Provision a new "Green" target group with the new code.
   • Perform health checks on the Green fleet.
   • Update the Load Balancer listener rule to point to the Green fleet.
   • Keep the "Blue" fleet running for a short period (e.g., 1 hour) to allow for an instant rollback if metrics drop.

Checkpoint Questions

1. What is the main disadvantage of a Rolling deployment compared to Blue/Green?
2. Which AWS service is considered "opinionated" because it abstracts the underlying infrastructure for web apps?
3. Why is it important to use the same rollout mechanism in UAT as in Production?
4. In CodeDeploy, which infrastructure targets support Blue/Green deployments?

[!TIP] Answers: 1. During a rolling update, the cluster runs at reduced capacity. 2. AWS Elastic Beanstalk or App Runner. 3. To ensure the rollout process itself is tested and functional before the milestone release. 4. EC2, Lambda, and ECS.

Muddy Points & Cross-Refs

• Rolling vs. Rolling with Additional Batch: A standard rolling update reduces capacity (if you have 10 servers and update 2, you only have 8 active). "Rolling with Additional Batch" (available in Beanstalk) maintains full capacity by launching new instances before taking old ones down.
• Blue/Green vs. Canary: Blue/Green is an "all-or-nothing" environment switch (though traffic can be shifted gradually). Canary is specifically about testing "blast radius" by exposing a tiny fraction of users to the new code.

Comparison Tables