Continuous Integration and Delivery Explained

Few phrases appear in software job ads, tool marketing and team retrospectives as often as "CI/CD." It is usually said as one word, as if it were a single product you could install. In reality it bundles together three related ideas: continuous integration, continuous delivery and continuous deployment. Each one describes a habit a team follows, not a tool it buys.

Understanding the difference matters for everyone around a software team, not only programmers. A product owner who knows what continuous delivery means can ask better questions about release plans. A Scrum Master who understands integration can spot why a sprint keeps ending with a painful "merge week." And a manager who grasps why small batches matter is less likely to push for the large, risky releases that cause outages.

This guide explains the three terms, the pipeline that connects them, trunk-based development, and the reasoning behind working in small pieces.

Three Terms That Are Often Confused

Continuous integration (CI) is the starting point. Martin Fowler, whose article on the subject was first published in 2000 and substantially revised in 2024, defines it as a practice where each member of a team merges their changes into a shared codebase together with their colleagues' changes at least daily. Fowler traces the practice to Kent Beck and the Extreme Programming community in the 1990s. The key word is integration: combining everyone's work often, so that conflicts surface while they are still small.

Continuous delivery goes further. Fowler describes it as building software in such a way that it can be released to production at any time. The idea was popularized by the 2010 book Continuous Delivery by Jez Humble and Dave Farley. Crucially, continuous delivery does not mean you release every change. It means you could, and the decision to release becomes a business choice rather than a technical gamble.

Continuous deployment is the most automated version. Every change that passes the automated checks goes to production without a person pressing a button. Fowler notes that continuous deployment requires continuous delivery to be in place first, but not every team that practices continuous delivery chooses to deploy continuously.

What a Pipeline Does

The machinery that links these ideas is usually called a deployment pipeline. Think of it as an assembly line for changes: each time someone adds work to the shared codebase, the pipeline picks it up and runs it through a series of increasingly realistic checks.

A typical pipeline might include these stages:

1. Build the software from the latest shared code.
2. Run fast automated tests that check small pieces of logic.
3. Run slower tests that check how parts work together.
4. Deploy the build to a test environment that resembles production.
5. Make the verified build available to release, either automatically or on request.

If any stage fails, the pipeline stops and the team is told. The value is not the automation itself but the fast, reliable feedback. DORA, the long-running research program on software delivery, says each change should trigger automated tests that give feedback within a few minutes, and suggests an upper limit of about 10 minutes for that feedback.

Trunk-Based Development

In version control, the main shared line of code is often called the trunk or mainline. Developers can also create branches, which are separate copies where work happens in isolation. Branches are useful, but long-lived ones delay integration, which is exactly what CI tries to avoid.

Trunk-based development is the habit of keeping branches short and merging into the trunk frequently. DORA's guidance describes teams with three or fewer active branches, branches merged to trunk at least once a day, and no code freezes or separate integration phases. DORA reports that its research found teams following these practices achieved higher software delivery and operational performance.

Fowler makes a related point: running a CI server against many separate feature branches is not the same as continuous integration. If code is not merged into the shared mainline, it has not really been integrated, no matter how often it is built.

Why Small Batches Matter

Behind all of this sits a simple idea. Small changes are easier to understand, test, review and undo. DORA lists the benefits of working in small batches as faster feedback that makes problems easier to triage, greater efficiency and motivation, and protection from the sunk-cost fallacy, the tendency to keep investing in something because you have already invested so much.

Consider a hypothetical team that merges a month of work at once. If something breaks, the cause could be anywhere in hundreds of changes. A team that merges a few small changes each day knows the problem almost certainly sits in the last one or two. The second team spends minutes diagnosing what the first team spends days untangling.

Small batches also change how teams plan. Instead of finishing a whole feature before integrating, developers break work into slices that can be merged safely, sometimes hidden behind a feature flag, which is a switch that keeps unfinished functionality turned off for users.

Habits That Make It Work

Tools make CI and continuous delivery possible, but habits make them succeed. Drawing on Fowler's list of practices and DORA's guidance, the most important include:

• Keep everything needed to build the software in version control.
• Make the build and tests run automatically on every change.
• Treat a broken build as the team's top priority; Fowler puts it as "nobody has a higher priority task than fixing the build."
• Keep the build fast so people actually wait for its results.
• Hide work in progress with techniques such as feature flags instead of long-lived branches.
• Make the state of the pipeline visible to everyone.
• Automate deployment so releasing is routine, not an event.

Common Misunderstandings

One misunderstanding is that buying a CI service means you are doing CI. The tool only runs builds; the practice depends on people integrating often. Another is that continuous delivery forces you to ship constantly. It does not. Many organizations release on a schedule while keeping their software always releasable.

A third is that these practices are only for large technology companies. The underlying principles, integrate often, test automatically, keep changes small, apply to a small team building an internal tool as much as to a large platform. The investment simply scales with the system.

Key takeaways

• Continuous integration means merging everyone's work into a shared mainline at least daily, with automated builds and tests.
• Continuous delivery means software is always in a releasable state; continuous deployment means every passing change goes live automatically.
• A deployment pipeline gives fast, staged feedback on each change.
• Trunk-based development keeps branches short-lived so integration really happens.
• Small batches make problems easier to find, fix and roll back.

Sources

• Martin Fowler, Continuous Integration
• Martin Fowler, Continuous Delivery
• DORA, Continuous integration
• DORA, Trunk-based development
• DORA, Working in small batches