CI/CD

CI/CD automates building, testing, and delivering software on every change, replacing manual release steps with a repeatable pipeline that keeps the main branch releasable.

delivery

Definition

CI/CD combines continuous integration, where every change is merged and verified automatically, with continuous delivery or deployment, where verified artifacts move to production through an automated, observable pipeline.

Context and scope

It applies to teams of any size that want faster feedback, fewer integration surprises, and releases that do not depend on a manual checklist.

Common misconceptions

CI/CD means deploying to production on every commit — continuous delivery stops at a deployable artifact; deployment can stay manual.
A pipeline is CI/CD even if it only builds — without tests and a delivery path, it is just automation.
CI/CD removes the need for release approvals — high-risk changes still need gates, but the pipeline makes them explicit and fast.

Anti-patterns

A pipeline that takes an hour, so developers batch changes and avoid running it
Tests that fail intermittently and are retried until green
Deploying from a developer laptop when the pipeline is red

Related concepts

Authoritative source

https://martinfowler.com/articles/continuousIntegration.html

From commit to deployable artifact

Continuous integration means every change lands on a shared branch and triggers an automated build and test run. Continuous delivery extends that run to produce a deployable artifact and push it through staging environments; continuous deployment goes one step further and releases automatically. The pipeline is the contract: if it is green, the artifact is releasable.

push -> install (cached) -> lint -> unit tests -> build -> integration tests
     -> publish image -> deploy staging -> smoke tests -> [gate] -> production

When to use it

Use CI/CD as soon as more than one person commits to the same codebase, and treat it as mandatory when releases happen more than once a month. It fits web services, libraries, and mobile apps alike. If a project has one developer and ships quarterly, a lighter pipeline may be enough, but the feedback loop still pays for itself.

Trade-offs

Pipelines cost engineering time and infrastructure. Slow suites erode trust, and flaky tests are worse than no tests because they teach people to ignore red builds. Security scanning and approvals add gates that must be fast enough not to block. The payoff is smaller batches, faster diagnosis, and releases that are routine rather than heroic.

Example and misconceptions

A team splits its pipeline into a fast stage (lint and unit tests under five minutes) and a slow stage (integration and end-to-end). Developers get feedback before they switch tasks. The myth that CI/CD always means auto-deploy to production confuses continuous delivery with continuous deployment. Related concepts: build cache, GitOps, and rolling deployment.