How it works
Continuous integration means every push or pull request starts a pipeline on a fresh machine: install dependencies, lint, type-check, run the tests and build. A failing run blocks the merge, so broken code is caught in minutes rather than in production. Continuous delivery keeps the main branch ready to release at the press of a button; continuous deployment goes one step further and releases every change that passes.
Pipelines are described in files that live in the repository, such as a GitHub Actions workflow or a .gitlab-ci.yml. Common services include GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines and the long-established, self-hosted Jenkins. Hosting platforms such as Vercel, Netlify and Cloudflare Pages build a simple CD pipeline in: connect a repository, and every push deploys.
CI/CD pros and cons
Pros
- Bugs are caught minutes after they are written
- Releases become routine and repeatable instead of risky events
- Every change is built the same way on a clean machine
- Frees developers from manual testing and deploy chores
Cons
- Only as good as the tests it runs
- Slow or flaky pipelines frustrate teams and get ignored
- Build minutes and runners cost money at scale
When to use CI/CD
Pick it when
- More than one person works on the code
- You deploy often and want each release to be uneventful
- A broken release would cost real money or trust
Skip it when
- A throwaway prototype, where a host's automatic deploys are enough
Related terms
More in Dev workflow and DevOps
Shipping