A CI/CD pipeline is an automated workflow that turns a code change into a tested, deployable release. It exists to reduce risk and increase delivery speed: every change follows the same checks, the same build rules, and the same deployment steps.
In mature teams, pipelines are not “just scripts”. They are the delivery system for quality, security, compliance, and repeatability.
Simple mental model
A good pipeline answers three questions automatically: Does it work? (tests), Is it safe? (security + policy), Can we release it reliably? (deploy + rollback).
1. What a CI/CD Pipeline Is (In Plain English)
Think of a pipeline as a conveyor belt: every commit triggers a repeatable set of steps—build, test, scan, and deploy—so releases do not depend on manual, error-prone runbooks.
- CI (Continuous Integration): merge changes often and validate them automatically.
- CD (Continuous Delivery/Deployment): automate releases so you can ship changes safely and frequently.
2. CI vs CD: Continuous Delivery vs Continuous Deployment
“CD” is commonly used for two related practices:
- Continuous delivery: every change is deployable; you may require a manual approval to push to production.
- Continuous deployment: production deploy happens automatically when the pipeline passes.
Practical choice
Many teams start with continuous delivery (manual prod approval) and evolve toward continuous deployment for low-risk services once they trust tests, monitoring, and rollback.
3. Pipeline Anatomy: Typical Stages from Commit to Production
A common high-signal pipeline layout:
- Pre-checks: lint, format, static analysis.
- Tests: unit → integration → (optional) E2E.
- Build: artifact or container image.
- Security: SAST, dependency scanning, container scan.
- Deploy non-prod: dev/staging with smoke tests.
- Promote: same artifact to prod.
- Post-deploy: health checks, SLO monitoring, rollback triggers.
Commit -> CI checks -> Tests -> Build artifact -> Scan -> Deploy staging -> Approve -> Deploy prod -> Verify4. Triggers, Branching, and How Changes Flow
Keep triggers predictable:
- Pull request pipeline: fast feedback (lint + unit tests).
- Main branch pipeline: build, scan, deploy to staging.
- Release tag pipeline: promote the exact artifact to prod.
Avoid “works on main only”
Run the same core checks on pull requests. Catching issues after merge is slower and more expensive.
5. Testing Strategy in Pipelines (Unit, Integration, E2E)
Balance confidence and speed:
- Unit tests: fast, high coverage of business logic.
- Integration tests: DBs, queues, third-party APIs (often mocked).
- E2E tests: critical user journeys; keep the set small.
Flaky tests are a delivery tax
If tests are flaky, teams stop trusting CI. Track flaky test rate and fix them as a first-class reliability issue.
6. Artifacts, Versioning, and Build Once / Deploy Many
A core best practice: build once and deploy that exact artifact through environments. This improves traceability and reduces “it changed between staging and prod” failures.
- Version artifacts: semantic version or commit SHA.
- Store artifacts: registry or artifact repository.
- Promote: tag/approve the same build for production.
7. DevSecOps: Security Scans (SAST, SCA, Containers, IaC)
Add security early and automate it:
- SAST: scan code for risky patterns.
- SCA: scan dependencies for known vulnerabilities.
- Container scanning: base image and OS packages.
- IaC scanning: Terraform/Kubernetes misconfigurations.
Policy rule of thumb
Fail the pipeline on critical issues, warn on lower severity, and require explicit exceptions for risk acceptance.
8. Environments and Promotion: dev → staging → prod
Environment separation is about reducing blast radius:
- dev: fast feedback, frequent deployments.
- staging: production-like validation and smoke tests.
- prod: controlled releases with monitoring and rollback.
Promotion pattern
Use environment-specific config (not environment-specific builds). The artifact stays constant; configuration changes per environment.
9. Secrets Management and Least Privilege in CI/CD
Secrets are where pipelines most often leak risk. Minimum standards:
- Use a secret store: CI secrets or a dedicated vault.
- Scope by environment: staging secrets cannot deploy prod.
- Least privilege: pipeline roles can do only what they must.
- Rotate: keys and tokens regularly; prefer short-lived creds.
Never
Do not commit secrets, do not echo secrets in logs, and do not reuse production credentials in non-production pipelines.
10. Deployment Strategies: Rolling, Blue/Green, Canary
Choose strategy based on risk and rollback needs:
- Rolling: replace instances gradually; simple, common.
- Blue/green: two environments; switch traffic; fast rollback.
- Canary: shift a small % of traffic first; monitor; expand.
Rollback trigger
Automate rollback based on SLO-style signals: error rate, latency, or saturation above thresholds for N minutes.
11. Approvals, Change Control, and Auditability
Even with automation, many orgs require approvals for production:
- Manual gates: release manager or on-call engineer approves.
- Change record: link the deployment to a ticket/issue.
- Audit logs: who approved what, and when.
12. Post-Deploy Checks: Monitoring, Rollback, and SLOs
Deployment is not done when it finishes; it is done when it is stable. Add post-deploy checks:
- Smoke tests: top user journeys.
- Health checks: readiness/liveness and dependency checks.
- Dashboards: golden signals (latency, traffic, errors, saturation).
- Rollback plan: rehearsed, not theoretical.
Example go/no-go signals
- Error rate > 1% for 5 minutes
- p95 latency +30% vs baseline
- Critical dependency failing health checks13. Metrics That Matter (DORA + Pipeline Health)
Use metrics to improve delivery instead of debating opinions:
- DORA: deployment frequency, lead time, change failure rate, time to restore.
- Pipeline duration: fastest path from commit to deploy.
- Flaky test rate: % of failed runs that pass on retry.
- Rollback frequency: how often releases need reversal.
Where to start
If your pipeline is slow, split tests (fast vs slow), run jobs in parallel, and cache dependencies. Speed matters because it directly affects lead time.
14. Common CI/CD Mistakes (And How to Avoid Them)
- Building different artifacts per environment: “works in staging, fails in prod”. Fix: build once, promote.
- Secrets sprawl: creds everywhere. Fix: vault + least privilege + rotation.
- Over-reliance on E2E: slow and flaky. Fix: more unit/integration coverage, smaller E2E suite.
- No rollback practice: rollback fails under pressure. Fix: rehearse rollback and automate triggers.
- Ignoring metrics: no continuous improvement. Fix: track DORA + pipeline health.
15. CI/CD Pipeline Checklist
Use this as a practical quality bar:
- CI: lint + unit tests on every PR.
- Build: versioned artifact stored in a registry.
- Security: automated scans with clear fail rules.
- Promotion: same artifact moves through environments.
- Config: environment-specific config, not builds.
- Secrets: injected at runtime; least privilege enforced.
- Deploy: safe strategy (rolling/blue-green/canary).
- Verify: smoke tests + dashboards after deploy.
- Rollback: tested runbook + automated triggers.
- Metrics: DORA + pipeline duration tracked.
Fast win
Add “validate merge keys” and “fail on critical vulns” equivalents to your pipeline: small controls with outsized impact on quality and risk.
16. FAQ: CI/CD
Do I need Kubernetes to have CI/CD?
No. CI/CD is tool-agnostic. You can deploy to VMs, serverless, PaaS, or containers. The core idea is automated build, test, and release steps.
Should pipelines deploy on every commit?
For non-production environments, often yes. For production, many teams deploy based on release tags or approvals to balance speed and control.
How do I make pipelines faster?
Run jobs in parallel, cache dependencies, split fast vs slow test suites, avoid rebuilding unchanged artifacts, and fix flaky tests.
Where should I start with security in CI/CD?
Start with dependency scanning (SCA) and secrets scanning, then add SAST and container/IaC scanning. Define clear “fail” rules for critical issues.
What is the minimum rollback plan?
A scripted rollback step, a clear “go/no-go” owner, and monitored signals that trigger rollback. If rollback is manual, practice it regularly.
Key DevOps terms (quick glossary)
- CI
- Continuous integration: automatically building and testing changes to detect issues early.
- Continuous Delivery
- Keeping software deployable at all times, often with a manual approval to release to production.
- Continuous Deployment
- Automatically releasing to production when the pipeline passes all checks.
- Artifact
- The built output of a pipeline (package, binary, or container image) that is deployed to environments.
- DevSecOps
- Integrating security scanning and policy checks into the delivery pipeline as automated steps.
- Blue/Green
- A deployment strategy with two environments where traffic switches to the new version, enabling fast rollback.
- Canary
- A strategy that gradually routes a small percentage of traffic to a new version while monitoring stability signals.
- DORA Metrics
- Delivery performance metrics: deployment frequency, lead time, change failure rate, and time to restore service.
Worth reading
Recommended guides from the category.
