Going faster with continuous delivery

Ideas you will meet

Deployment

Releases, feature flags, rollbacks and continuous delivery.

What we already know about this

Our own lessons on these ideas. Read them here before you start, so it makes sense.

• Core Concepts: How Things Actually Work · 8 minDeployment strategiesRolling, blue-green, canary and feature flags: how to release changes with less risk, including database changes.Read hereClose

  Why strategy matters

  Most outages follow a change. A good deployment strategy limits the blast radius and makes rollback fast.

  The main strategies

  Recreate (big bang)

  Stop the old version, start the new one. Simple, but there is downtime and no easy rollback.

  Rolling update

  Replace instances a few at a time. No downtime and little extra capacity, but for a while both versions serve traffic, so they must be compatible. Rollback means rolling back the same way.

  Blue-green

  Run two identical environments. Blue serves live traffic; deploy to green, test it, then switch the router to green. Rollback is flipping back. Cost: double the capacity during the switch, and shared state (databases) still needs care.

  Canary

  Send a small share (1%, 5%, 25%...) of traffic to the new version, watch the metrics, then widen. If errors rise, roll back automatically. Needs good monitoring and traffic splitting.

  100%

  Figure SDA-CORE-12-1 · Canary · © forcsguy.com

  Feature flags

  Ship code switched off, and enable it for chosen users (or a percentage) at runtime. It separates deploying from releasing, and gives an instant kill switch. Remove old flags to avoid clutter.

  100%

  Figure SDA-CORE-12-2 · Four ways to put a new version live · © forcsguy.com

  Before: release to everyone at once

  100%

  After: canary: a few users first

  100%

  What changed

  • A bad release reaches few users before it is caught
  • Rolling back means shifting traffic back, not redeploying
  • You compare error rates between old and new

  Databases are the hard part

  Code can roll back instantly; data cannot. Use expand and contract:

  1. Expand: add new columns or tables, compatible with the old code.
  2. Deploy code that works with both shapes and writes to both if needed.
  3. Migrate data (backfill in batches).
  4. Contract: remove the old structure in a later release.

  Never combine a destructive schema change with the code that depends on it in one step.

  Checklist for safer releases

  • Automated tests and a staging environment that resembles production.
  • Health checks and automatic rollback on failure.
  • Monitoring on error rate and latency, watched during rollout.
  • Small, frequent changes over large, rare ones.
  • A written, practised rollback plan.

  More on this site

  Related reading

  • Blue Green DeploymentMartin FowlerBlogs
  • Ensuring rollback safety during deploymentsAmazon Builders' Library · Amazon Web ServicesBlogs
  • Feature Toggles (aka Feature Flags)Pete Hodgson · Martin FowlerBlogs
  • Going faster with continuous deliveryAmazon Builders' Library · Amazon Web ServicesBlogs

  Show 6 moreShow fewer

  • Online migrations at scaleJacqueline Xu · StripeCase Studies
  • Continuous Integration and Deployment with Bazel at DropboxDropbox engineers · DropboxCase Studies
  • HashiCorp BlogHashiCorp engineers · HashiCorpBlogs
  • Software Engineering at GoogleTitus Winters, Tom Manshreck and Hyrum Wright · O'Reilly / GoogleBooks
  • Scaling iOS CI with Anka at ShopifyShopify engineers · ShopifyCase Studies
  • Mozilla Release EngineeringMozilla Release Engineering engineers · Mozilla Release EngineeringBlogs

  Open this lesson with its quiz and exercise

• Advanced Distributed Systems · 13 minKubernetes essentialsPods, deployments, services, ingress and operators: the building blocks of the most common container platform and how a request reaches a pod.Read hereClose

  What Kubernetes does

  Kubernetes (K8s) runs containers across a cluster of machines. You describe the desired state (for example "three copies of this image, reachable at this address") and controllers continuously make reality match it: restarting failed containers, replacing lost nodes and rolling out new versions. (Containers themselves are introduced in the cloud models lesson.)

  The cluster

  • Control plane: the API server (everything talks to it), etcd (the consistent store of cluster state, built on Raft; see the consensus lesson), the scheduler (decides which node runs a pod) and controllers (reconcile desired and actual state).
  • Nodes: machines that run pods, each with a node agent (kubelet), a container runtime and a networking component.

  The core objects

  100%

  Figure SDA-ADS-07-1 · From request to pod · © forcsguy.com

  Object	Purpose
  Pod	Smallest unit: one or more containers sharing network and volumes
  ReplicaSet / Deployment	Keep N pods running; roll out updates and roll back
  Service	Stable virtual IP and DNS name that load balances to matching pods
  Ingress	HTTP routing from outside to services (host, path, TLS), handled by an ingress controller
  ConfigMap / Secret	Configuration and sensitive values injected as environment variables or files
  StatefulSet	Pods with stable identity and storage, for databases and brokers
  DaemonSet	One pod per node (log shippers, agents)
  Job / CronJob	Run to completion, once or on a schedule
  Namespace	Logical separation of resources and quotas
  PersistentVolume(Claim)	Durable storage requested by pods

  Networking in one paragraph

  Every pod gets its own IP and can reach every other pod without NAT. Because pods are short-lived, clients use Services (found through cluster DNS such as orders.shop.svc). Network policies restrict which pods may talk to which. An Ingress (or the newer Gateway API) handles external HTTP(S) traffic.

  A deployment and a rolling update

  apiVersion: apps/v1
  kind: Deployment
  metadata: { name: web }
  spec:
    replicas: 3
    selector: { matchLabels: { app: web } }
    strategy: { type: RollingUpdate, rollingUpdate: { maxSurge: 1, maxUnavailable: 0 } }
    template:
      metadata: { labels: { app: web } }
      spec:
        containers:
          - name: web
            image: example/web:1.4.2
            resources: { requests: { cpu: 200m, memory: 256Mi }, limits: { memory: 512Mi } }
            readinessProbe: { httpGet: { path: /healthz, port: 8080 } }
  

  100%

  Figure SDA-ADS-07-2 · Rolling update · © forcsguy.com

  Probes: readiness decides if a pod receives traffic; liveness decides if it should be restarted; startup gives slow starters time. Requests and limits tell the scheduler how much CPU and memory a pod needs and cap what it can use.

  Autoscaling

  A Horizontal Pod Autoscaler adds or removes pods by metrics such as CPU or request rate; a cluster autoscaler adds or removes nodes when pods cannot be placed. Scaling is useless without correct resource requests.

  Extending Kubernetes: operators and CRDs

  A Custom Resource Definition (CRD) adds a new object type (for example PostgresCluster). An operator is a controller that watches those objects and does the operational work (create replicas, take backups, fail over), encoding human runbooks as code. Many databases and brokers ship operators.

  Things that often go wrong

  Missing readiness probes (traffic to pods not ready), no resource requests (noisy neighbours, evictions), latest image tags (unrepeatable deploys), secrets in plain config, a single replica for a critical service, and running stateful systems without understanding storage and failure behaviour.

  Real-world reading

  Related reading

  • TechWorld with Nana: Docker & KubernetesNana Janashia · TechWorld with NanaYouTube
  • AWS Containers BlogAmazon Web Services engineers · Amazon Web ServicesBlogs
  • Awesome KubernetesRamit Surana · ramitsuranaGitHub
  • Kubernetes ConceptsKubernetes Authors · CNCF / KubernetesDocumentation

  Show 6 moreShow fewer

  • Kubernetes: IngressKubernetes · CNCF / KubernetesDocumentation
  • Docker BlogDocker engineers · DockerBlogs
  • DevOps Roadmaproadmap.sh community · roadmap.shCourses
  • Kubernetes BlogKubernetes community · CNCF / KubernetesBlogs
  • From bare-metal to Kubernetes at BetabrandBetabrand engineers · BetabrandCase Studies
  • Large-scale cluster management at Google with Borg (paper)Verma et al. · GooglePapers

  Open this lesson with its quiz and exercise

• Core Concepts: How Things Actually Work · 9 minDevOps in practice, and where to learn moreWhat DevOps really means, the practices behind it, how to measure delivery performance, and a short reading list.Read hereClose

  It is a culture first

  DevOps removes the wall between people who build software and people who run it. The old model threw code "over the wall" to operations, who feared change; developers wanted change. DevOps aligns both on the same goal: deliver value quickly and reliably. Tools help, but the core is shared ownership, automation and fast feedback.

  The pipeline

  100%

  Figure SDA-CORE-23-1 · The pipeline · © forcsguy.com

  Core practices

  1. Version control for everything: code, configuration and infrastructure definitions.
  2. Continuous integration (CI): merge small changes frequently; each triggers an automated build and tests.
  3. Continuous delivery and deployment (CD): automated, repeatable release to staging and production, with safe rollout (see the deployment strategies lesson).
  4. Infrastructure as code (IaC): define servers, networks and permissions in code (Terraform, CloudFormation, Pulumi, Ansible). Review, version and recreate environments on demand.
  5. Containers and orchestration: package software consistently (Docker) and run it on a platform such as Kubernetes.
  6. Observability: metrics, logs and traces, with alerts on user-visible symptoms.
  7. Security in the pipeline ("DevSecOps"): dependency scanning, secret detection, image scanning, least privilege.
  8. Blameless learning: postmortems and improvement of the system, not of blame.
  9. GitOps: Git is the source of truth for desired state; automation reconciles the real environment with it.

  Measuring delivery performance: the DORA metrics

  Research by the DevOps Research and Assessment (DORA) team found four measures that predict both delivery and business performance:

  Metric	Question
  Deployment frequency	How often do we deploy to production?
  Lead time for changes	How long from commit to running in production?
  Change failure rate	What share of deployments cause a failure needing remediation?
  Time to restore service	How quickly do we recover from a failure?

  The finding that surprised many: high performers are both faster and more stable. Speed and stability reinforce each other when you work in small batches with strong automation.

  Common mistakes

  • Renaming the operations team "DevOps" without changing responsibilities.
  • Buying tools without changing habits.
  • Automating a broken process instead of fixing it.
  • Measuring individuals (lines of code, tickets closed) instead of flow and outcomes.
  • Ignoring security and cost until the end.

  Where to learn more

  These books are widely recommended (buy or borrow them; this course summarises ideas in its own words):

  • Accelerate by Nicole Forsgren, Jez Humble and Gene Kim: the research behind the DORA metrics.
  • The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois and John Willis: practices and case studies.
  • The Phoenix Project by Gene Kim, Kevin Behr and George Spafford: a novel that explains the ideas through a story.
  • Site Reliability Engineering by Google's SRE team (free online): reliability, monitoring and incidents.
  • Continuous Delivery by Jez Humble and David Farley: pipelines and release engineering.
  • Release It! by Michael Nygard: designing for production failure.
  • Infrastructure as Code by Kief Morris: managing infrastructure with software practices.

  Real-world reading

  Related reading

  • Going faster with continuous deliveryAmazon Builders' Library · Amazon Web ServicesBlogs
  • DevOps Roadmaproadmap.sh community · roadmap.shCourses
  • Screwdriver: Continuous Delivery Build System for Dynamic Infrastructure at YahooYahoo engineers · YahooCase Studies
  • Blue Green DeploymentMartin FowlerBlogs

  Show 6 moreShow fewer

  • AWS DevOps BlogAmazon Web Services engineers · Amazon Web ServicesBlogs
  • Ensuring rollback safety during deploymentsAmazon Builders' Library · Amazon Web ServicesBlogs
  • Software Engineering at GoogleTitus Winters, Tom Manshreck and Hyrum Wright · O'Reilly / GoogleBooks
  • Continuous Integration and Deployment with Bazel at DropboxDropbox engineers · DropboxCase Studies
  • Mozilla Automation Team Engineering BlogMozilla Automation Team engineers · Mozilla Automation TeamBlogs
  • OpenTelemetry conceptsOpenTelemetry · CNCF / OpenTelemetryDocumentation

  Open this lesson with its quiz and exercise