Back to Subject

Unit 4: Core concepts of Continuous Delivery (CD), Deployment & Automation

INT331 — Fundamentals Of Devops 7 min read

The unit builds on Continuous Integration and extends the pipeline outward: from validated artifacts, through automated provisioning and configuration, to running workloads in production. Every later section assumes the same pipeline spine — commit, build, test, package, deploy — and the goal of shrinking lead time while keeping releases low-risk and repeatable.

  • Deployment pipeline: the automated path an artifact travels from version control to production; each stage is a gate that must pass before the next runs.
  • Idempotency: applying the same operation many times yields the same end state; the governing property of configuration management and infrastructure tools.
  • Immutability: servers/containers are replaced rather than modified in place, eliminating configuration drift.
  • Declarative vs imperative: describe the desired end state (declarative) versus scripting the steps to reach it (imperative).
  • Artifact: the single, versioned, tested build promoted unchanged through every environment.

II. Continuous Delivery & Continuous Deployment

Two release disciplines that differ only at the production gate.

A. Introduction to Continuous Delivery & Continuous Deployment

Both practices automate everything up to release; they differ in whether a human approves the final push.

  1. Continuous Delivery: every change that passes the pipeline is deployable to production, but the actual release is triggered manually.
    • Trigger: a person clicks "promote"; the build is already staging-verified.
    • Use case: regulated domains needing a sign-off (banking, healthcare).
  2. Continuous Deployment: every change that passes automated tests is released to production automatically, with no human step.
    • Trigger: a green pipeline is the release; no gate.
    • Precondition: high automated test coverage and reliable rollback.
    • Shared foundation: both require Continuous Integration, automated tests, one artifact promoted across environments, and infrastructure defined as code.
    • Metrics: measured by deployment frequency, lead time for change, mean time to recovery (MTTR), and change-failure rate.

III. Jenkins Plugins for CD

Extending Jenkins from a build server into a delivery orchestrator.

A. Jenkins Plugins for CD

Jenkins ships a minimal core; delivery capability comes from plugins layered onto pipelines.

  • Pipeline (Workflow) plugin: defines the build as code in a Jenkinsfile using Groovy stages.
    GROOVY
      pipeline {
    agent any
    stages {
      stage('Build')  { steps { sh 'mvn package' } }
      stage('Test')   { steps { sh 'mvn test' } }
      stage('Deploy') { steps { sh './deploy.sh' } }
    }
  }
  • Blue Ocean: graphical visualization of pipeline stages and their pass/fail state.
  • Credentials Binding: injects secrets (tokens, keys) into builds without hardcoding them.
  • Docker Pipeline: builds, tags, and pushes images and runs steps inside containers.
  • Kubernetes plugin: spins up ephemeral build agents as pods on demand.
  • SSH / Publish Over SSH: copies artifacts and runs remote deploy commands on target hosts.
  • stage-gate plugins (input step): the input directive pauses for manual approval — the mechanism that turns Continuous Deployment into Continuous Delivery.

IV. Deployment Strategies

Techniques for replacing a running version while controlling downtime and blast radius.

A. Rolling

Instances are upgraded in batches so the service never fully stops.

  • Mechanism: replace a subset (e.g. 2 of 6 nodes) with the new version, health-check, then proceed to the next subset.
  • Trade-off: no extra capacity cost, but old and new versions run simultaneously, so both must be backward-compatible.
  • Rollback: slow — the batch process must be reversed instance by instance.

B. Blue-Green

Two identical environments exist; traffic switches between them instantly.

  • Mechanism: "blue" serves live traffic while "green" holds the new version; a load-balancer or DNS switch cuts all traffic to green at once.
  • Rollback: near-instant — flip traffic back to blue.
  • Trade-off: requires double the infrastructure during the switchover; database schema changes need care since both share data.

C. Canary

A small slice of real traffic tests the new version before full rollout.

  • Mechanism: route ~5% of users to the canary; monitor error rate and latency; increase gradually to 100% or abort.
  • Advantage: limits blast radius to a fraction of users and validates against real load.
  • Contrast with Blue-Green: blue-green switches all traffic in one step; canary ramps traffic progressively, trading speed for safety.

V. Configuration Management Basics: Terraform / Puppet / Ansible

Codifying servers and infrastructure so environments are reproducible.

A. Terraform

A declarative tool for provisioning infrastructure (the machines themselves).

  • Scope: creates and destroys cloud resources — VMs, networks, load balancers.
  • State file: terraform.tfstate records what exists so plans compute only the delta.
  • Workflow: terraform init → plan (preview) → apply (execute).
    HCL
      resource "aws_instance" "web" {
    ami           = "ami-0abcd1234"
    instance_type = "t2.micro"
  }

B. Puppet

A declarative, agent-based tool for configuring the software on servers.

  • Model: agents pull the desired state (manifests) from a central Puppet master at intervals.
  • Language: manifests describe resources; Puppet enforces them idempotently.
    PUPPET
      package { 'nginx': ensure => installed }
  service { 'nginx': ensure => running }
  • Contrast with Ansible: Puppet is pull-based and needs an agent installed; Ansible is push-based and agentless.

C. Ansible

An agentless, procedural tool that configures hosts over SSH.

  • Transport: connects via SSH; no software on targets beyond Python.
  • Playbooks: YAML files listing ordered tasks against inventory groups.
  • Idempotency: modules (e.g. apt, service) only change state when needed.

VI. Infrastructure Automation with Ansible and Terraform

Combining a provisioner and a configurer into one automated flow.

A. Infrastructure Automation with Ansible and Terraform

The two tools are complementary rather than competing: Terraform builds the infrastructure, Ansible configures what runs on it.

  1. Terraform's role — provisioning: stands up the raw resources (instances, subnets, security groups) declaratively and tracks them in state.
  2. Ansible's role — configuration: installs packages, writes config files, and starts services on the provisioned hosts.
    • Handoff: Terraform outputs host IPs; Ansible consumes them as inventory, so a single run goes from empty cloud account to a working, configured application.
    • Ansible playbook example:
      YAML
        - hosts: web
    tasks:
      - name: Install nginx
        apt: { name: nginx, state: present }
      - name: Start nginx
        service: { name: nginx, state: started }
    • Benefit: the entire environment is version-controlled, reviewable, and reproducible — supporting immutable, drift-free infrastructure.

VII. Containerization and Docker

Packaging an application with its dependencies into a portable, isolated unit.

A. Containerization Introduction

Containers isolate a process and its dependencies while sharing the host kernel.

  • Definition: OS-level virtualization bundling code, runtime, and libraries into one image.
  • Contrast with virtual machines:
    • VM: ships a full guest OS per instance; heavy, boots in minutes.
    • Container: shares the host kernel; lightweight, starts in seconds.
  • Value: "build once, run anywhere" — eliminates the "works on my machine" gap.

B. Docker Architecture & Workflow

Docker uses a client-server model to build and run containers.

  • Docker client: the CLI (docker) that sends commands.
  • Docker daemon (dockerd): the server that builds images and runs containers.
  • Image: a read-only template built from layers.
  • Container: a running, writable instance of an image.
  • Registry: a store for images (Docker Hub, private registries).
  • Workflow: write a Dockerfile → docker build produces an image → docker push to a registry → docker pull and docker run on any host.

C. Writing Dockerfiles

A Dockerfile is a text recipe of ordered instructions that build an image.

  • FROM: the base image every layer sits on.
  • WORKDIR: sets the working directory inside the image.
  • COPY: copies files from build context into the image.
  • RUN: executes a command at build time, creating a new layer.
  • EXPOSE: documents the port the container listens on.
  • CMD: the default command run when the container starts.
    DOCKERFILE
      FROM node:18-alpine
  WORKDIR /app
  COPY package.json .
  RUN npm install
  COPY . .
  EXPOSE 3000
  CMD ["node", "server.js"]
  • Layer caching: each instruction is a cached layer; copying package.json before source code lets dependency installs be reused when only code changes.

D. Building Images

Building turns the Dockerfile and its context into a tagged, layered image.

  • Command: docker build -t myapp:1.0 . — the . is the build context sent to the daemon.
  • Tagging: name:tag identifies versions; untagged builds default to latest.
  • Inspection: docker images lists built images with size and ID.
  • Optimization: multi-stage builds compile in one stage and copy only the artifact into a slim final image, cutting size.

E. Running Containers

Running instantiates an image as an isolated, live process.

  • Command: docker run -d -p 8080:3000 myapp:1.0.
    • -d: detached (background) mode.
    • -p 8080:3000: maps host port 8080 to container port 3000.
  • Lifecycle: docker ps lists running containers; docker stop/docker start manage state; docker logs reads output.
  • Persistence: container writes are ephemeral; -v host:container mounts a volume to keep data across restarts.
Previous
Unit 3
Next
Unit 5