Continuous Integration, Delivery, and Deployment Pipelines

The Problem: Integration Hell

In Waterfall, integration happens once — at the end, after all components are built. This is when you discover that Alice’s module expects dates in DD/MM/YYYY and Bob’s module sends MM-DD-YYYY. The project is now late, over budget, and the fix requires rework across multiple components.

Continuous Integration (CI) is the solution: integrate small pieces frequently so that integration bugs are caught while they are still small and cheap to fix.

The CI/CD/CDP Spectrum

Term	Meaning
Continuous Integration (CI)	Developers merge to the main branch at least once per day. Every merge triggers an automated build and a full test suite. If anything fails, the team is notified within minutes and fixing the broken build becomes the top priority. This eliminates the “Merge Hell” of long-lived branches.
Continuous Delivery (CD)	Every version of the code that passes the pipeline is in a state that could be deployed to production at any moment. Automated tests pass → auto-deploy to a staging environment. A human decides when to actually push to production — this is a business decision (“is the marketing campaign ready? are the release notes written?”).
Continuous Deployment (CDP)	Fully automated path from code commit to live production. No human gate. All tests pass → auto-deployed to real users. Relies on automated monitoring and rollback: if error rates spike after a deployment, the system automatically reverts to the previous version.

The progression is: CI (integrate frequently) → CD (always be ready to ship) → CDP (ship automatically on every passing commit). Most companies practise CI and CD; far fewer practise full CDP — usually those with extremely high deployment maturity (Netflix, Amazon, Google).

Anatomy of a CI/CD Pipeline

1. Commit — a developer pushes code to the shared repository.
2. Build — the pipeline compiles/assembles the code, producing a versioned artifact (e.g. a Docker image tagged with the commit SHA). This artifact is used identically across all subsequent environments — ensuring that what you tested in Staging is exactly what reaches Production.
3. Unit Tests — fast, isolated tests run first. If these fail, there is no point running the slower tests.
4. Lint and Security Scan — static analysis for style violations, known vulnerabilities in dependencies (Dependabot/Snyk check against CVE databases), and common security anti-patterns.
5. Integration Tests — spin up real infrastructure (test database, message queue) and verify that modules work together.
6. Deploy to Staging — the artifact is deployed to a Staging environment, an exact replica of Production (same configuration, same infrastructure, but with test data).
7. Smoke Tests / E2E Tests — a fast subset of E2E tests that prove the critical paths work (login, checkout, search).
8. Deploy to Production — in CD, a human presses the button. In CDP, the pipeline does it automatically.

Failing any step rejects the build. This is a Quality Gate: the artifact may not proceed to subsequent environments until all upstream checks pass.

The Promotion Pipeline (Environments)

Code moves through environments of increasing “production-likeness”:

Environment	Purpose
Development	Local developer machines. The “wild west” — anything goes, rapid iteration, frequent breakage.
CI/Test	Clean, ephemeral environments spun up per pipeline run. Every test starts from a known state. Destroyed after the pipeline finishes.
Staging / UAT (User Acceptance Testing)	Identical to Production in every way except it does not serve real users. The “final dress rehearsal.” Product owners and QA test here.
Production	Real users, real data, real money. Zero tolerance for avoidable breakage.

Google’s “xFood” Progressive Internal Testing

Before any new feature reaches real users at Google, it goes through progressively larger internal audiences:

• Fishfood: 20–30 developers on the immediate team. Unstable, fast iteration. The build may be broken for hours.
• Teamfood: 50–100 people in the wider department. More stable, fewer breakages. Catches “annoyance” bugs the developers are too close to notice.
• Dogfood: all Google employees (thousands of people). The Release Candidate closest to what external users will see. By this stage, UX friction and reliability issues that passed earlier stages are caught by a diverse, non-developer audience.

The insight: expand the blast radius of a bug in controlled, concentric circles, with automatic rollback at any stage, rather than letting the first real user discover it in production.

Expected Learning

• Define CI, CD, and CDP, and explain the relationships and differences between them.
• Trace a commit through a CI/CD pipeline, naming each stage and its purpose.
• Explain the role of Quality Gates and why failing a stage must reject the build.
• Describe the promotion pipeline (Dev → CI → Staging → Prod) and why each environment differs.
• Explain Google’s xFood strategy and what problem it solves.

---

Past Paper Questions

Scenarios involving testing strategies for a rapidly growing service (2025 Tripos Q5a) naturally lead into discussing CI/CD pipelines and how automated testing gates prevent regressions. Example Sheet 2, Question 4 asks about deployment strategies; you must know the CI/CD context those strategies operate within.