A CI/CD pipeline is the automated assembly line that takes code from a developer's commit to a running application in production. It is the central artefact of a DevOps practice — replacing slow, error-prone manual deployments with a fast, reliable, repeatable process.
Continuous Integration (CI)
Continuous Integration means that every developer integrates (merges) their code into the shared repository frequently — ideally multiple times per day. Each integration triggers an automated pipeline that:
- Compiles the code to catch syntax and type errors
- Runs unit and integration tests to verify correctness
- Runs static analysis / linting to enforce code quality
- Produces a build artefact (a binary, Docker image, or deployment package)
The key principle: fix a failing build before anything else. If the main branch is broken, the entire team is blocked. CI discipline means the main branch is always in a known-good state.
Continuous Delivery vs Continuous Deployment
These two terms are often confused:
| Continuous Delivery | Continuous Deployment | |
|---|---|---|
| Definition | Code is always in a releasable state. Deployment to production requires a manual approval. | Every build that passes all automated checks is deployed to production automatically. |
| Human trigger | Yes — a person presses "Deploy to production" | No — fully automated end to end |
| Common in | Regulated industries, enterprise software | SaaS, web products with mature test coverage |
Most organisations start with Continuous Delivery and evolve toward Continuous Deployment as their test coverage and confidence increase.
Anatomy of a Pipeline
A modern CI/CD pipeline typically has these stages:
- Source: A commit or pull request to a Git branch triggers the pipeline.
- Build: Compile source code, install dependencies, produce a versioned artefact.
- Unit Test: Fast isolated tests — run in seconds, fail fast.
- Integration / E2E Test: Slower tests against real dependencies or a test environment.
- Security Scan: SAST (static), dependency vulnerability scan (OWASP, Snyk), container image scan.
- Staging Deploy: Deploy to a pre-production environment that mirrors production.
- Smoke / Acceptance Test: Verify core journeys work in the staging environment.
- Production Deploy: Blue/green or canary deployment to production. May require manual approval gate.
Deployment Strategies
| Strategy | How It Works | Rollback Speed |
|---|---|---|
| Recreate | Stop old version, start new version. Brief downtime. | Slow (redeploy) |
| Rolling | Replace instances one at a time. Zero downtime if health checks pass. | Medium |
| Blue/Green | Run two identical environments. Switch traffic at load balancer. | Instant (flip back) |
| Canary | Route a small % of traffic to new version. Expand gradually. | Fast (remove canary) |
| Feature Flags | Deploy code dark, toggle features on/off in production without redeploy. | Instant (toggle off) |
Common CI/CD Tools
| Tool | Type | Notes |
|---|---|---|
| GitHub Actions | SaaS / hosted | Native to GitHub; YAML-based workflows |
| GitLab CI/CD | SaaS / self-hosted | Tight integration with GitLab repos; excellent pipelines |
| Jenkins | Self-hosted | Highly extensible; large plugin ecosystem; steeper ops burden |
| CircleCI | SaaS | Fast parallel execution; good Docker support |
| AWS CodePipeline | AWS managed | Native integration with CodeBuild, CodeDeploy, S3, ECR |
| Tekton | Kubernetes-native | Cloud-native pipelines on K8s; used by many GitOps platforms |
| ArgoCD | Kubernetes GitOps CD | Pulls from Git and reconciles K8s cluster state |
Pipeline as Code
Treat your pipeline configuration the same as application code: version it in Git, review it in pull requests, test changes in a branch. A GitHub Actions workflow looks like this:
name: CI
on: [push, pull_request]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- run: npm test
- run: npm run buildStoring the pipeline definition alongside the code means every branch can have its own pipeline behaviour, and changes to CI configuration go through the same review process as feature code.