Getting software from a commit to production, repeatably.
CI/CD is the practice of turning every commit into a tested, deployable artifact and moving it to production through an automated, repeatable pipeline. This section explains the stages and links to the detailed software delivery notes.
Continuous integration (CI) means developers merge small changes into the main branch frequently, and each merge triggers an automated build and test run. The goal is to detect integration problems within minutes instead of at the end of a release cycle. Continuous delivery extends this so that every passing build produces an artifact (a container image, a wheel, a JAR) that could be released at any time, usually after a manual approval. Continuous deployment removes that approval: every change that passes the pipeline goes to production automatically.
Common tools are GitHub Actions, GitLab CI, Jenkins, CircleCI and Azure DevOps for pipelines, and Argo CD or Flux for GitOps-style deployment to Kubernetes, where the cluster continuously reconciles itself to manifests stored in Git.
| Strategy | How it works | Use when |
|---|---|---|
| Rolling | Replace instances a few at a time | Default for stateless services |
| Blue/green | Run two environments, switch traffic at once | You need instant rollback |
| Canary | Send a small share of traffic to the new version first | High-traffic services with good metrics |
| Feature flags | Deploy code dark, enable per user or cohort | Decoupling release from deploy |
The detailed page, Software Delivery, walks through the full lifecycle from development through testing to release. Containers are the usual unit of delivery; see Containers for Docker and Kubernetes.