Also known as: continuous integration "CI", CD, CI/CD
CI/CD is the practice of automatically building and testing code on every change (continuous integration) and then automating its path to release (continuous delivery/deployment) through a versioned pipeline.1
Continuous Integration
Continuous Integration (CI) automatically builds and runs the test suite on every push (and every pull request). A CI server watches the repository in version control; when a change lands it checks out the code, installs the pinned dependencies via the build system, compiles it, and runs the tests. If anything fails, the team learns within minutes — while the change is fresh and small. The name comes from integrating everyone’s work frequently into the shared main line instead of letting branches drift and merging in one painful “big bang.” CI is the automated enforcement of “don’t break the build.”1
Continuous Delivery and Deployment
CI gets you a tested build; CD carries it toward release.
- Continuous Delivery keeps the build always in a releasable state — packaged and staged — with a human choosing when to ship.
- Continuous Deployment removes even that gate: every change that passes the full pipeline ships to production automatically.
The distinction is just where the human stands. Which you want depends on risk tolerance and how good your tests are.
Pipelines and artifacts
The whole automated sequence is a pipeline — staged steps like lint → build → test → package → deploy, each gating the next, and typically defined in a YAML file committed to the repo so the process itself is versioned. A successful run produces an artifact (a binary, container image, or installer) that is stored, versioned with semantic versioning, and promoted unchanged through environments. On GitHub the common tool is GitHub Actions, which can run the pipeline, fan out across a build matrix, run end-to-end tests, and publish release binaries through a package manager or release page — only when everything is green.