What CI/CD Actually Is¶

Estimated time: 18 min read · Part: CI/CD Foundations

The Three Practices¶

Continuous Integration (CI) is the practice of merging code into a shared main branch frequently — many times per day — with an automated build and test suite verifying each change. The goal is to catch integration problems within minutes. Before CI, teams worked on long-lived feature branches and suffered "merge week" — painful days of resolving conflicts between code that diverged over weeks, with failures that were nearly impossible to attribute to any single change.

Continuous Delivery (CD) extends CI so that every change that passes the pipeline is automatically prepared for release and could be deployed to production at the push of a button. The key word is "could": a human still decides when to release. This requires that the pipeline include not just unit tests, but everything needed to validate a production deployment — integration tests, performance tests, security scans, staging deployment and smoke tests.

Continuous Deployment removes the human gate entirely: every change that passes the full pipeline is automatically deployed to production. This is the most mature practice and requires very high confidence in the automated test suite, feature flags to decouple deployment from feature launch, and robust rollback mechanisms. Many high-performing engineering organizations — Etsy, Netflix, Amazon — deploy to production hundreds of times per day this way.

Why Small, Frequent Changes Are Safer¶

The counterintuitive truth of CI/CD is that deploying more often — even to production — reduces risk rather than increasing it. The reasoning is statistical and practical: when a deployment fails, the blast radius is limited to a small, well-understood changeset. Attribution is trivial: "this diff broke it." Rollback is fast: one git revert or one previous image tag. Small changes also hit fewer code paths simultaneously, meaning tests are better targeted. Big, infrequent releases accumulate risk: a six-week deployment contains hundreds of changes, any of which could be the cause of a failure, and rollback might require reverting features customers have started using.

flowchart LR
    A[Developer<br/>Commits Code] --> B[CI Pipeline<br/>Build + Test]
    B -->|passes| C[Artifact<br/>Ready to Deploy]
    B -->|fails| D[Notify Developer<br/>Fix in Minutes]
    C -->|Continuous Delivery| E[Human Approves<br/>Deploy]
    C -->|Continuous Deployment| F[Auto Deploy<br/>to Production]
    E --> G[Production]
    F --> G

Cultural Prerequisites¶

CI/CD is as much a cultural practice as a technical one. The technical pipeline is relatively easy to build; the organizational habits that make it effective are harder. Three are non-negotiable: trunk-based development — everyone integrates to the main branch at least daily, with feature flags to hide incomplete features rather than long-lived branches; small PRs — a pull request that takes more than a day for one reviewer to understand is too large; fast tests — a CI run that takes 30 minutes gets skipped or disabled; the sweet spot is under 10 minutes for the full pre-deploy validation suite.

WHY the core insight Integration pain is proportional to the time since the last integration. Frequent small merges make each one trivial; rare large merges make each one a crisis. The CI/CD pipeline automates the verification that makes frequent integration safe.

HOW the three practices CI: merge to main daily with automated tests. Continuous Delivery: every passing build is release-ready; a human clicks deploy. Continuous Deployment: every passing build deploys automatically.

WHERE enterprise transformation DORA metrics apply to any software organization. In consulting, use them to benchmark a client's current state, set improvement targets, and measure the impact of tooling and process changes over time.

1. Classification: LOW performer
   - Elite: multiple deploys/day, <1h lead time, <15% failure rate, <1h MTTR
   - This team is in the lowest DORA tier on all four metrics.

2. Highest-impact metric to improve first: LEAD TIME (3 weeks → target: hours)
   - Long lead time means slow feedback, slow customer value delivery,
     and usually correlates with large batch sizes (which drive the high CFR).
   - Improving lead time forces smaller PRs and faster pipelines, which
     compound to improve deployment frequency and failure rate.

3. Two concrete practices:
   a) Trunk-based development: merge to main daily; use feature flags
      to hide incomplete features. Eliminates weeks of branch divergence
      and integration conflict.
   b) Fast CI pipeline: target <10 minutes for the pre-deploy validation
      suite. Audit and parallelize slow tests; mock external dependencies;
      move slow E2E tests to a separate post-deploy stage.