CI/CD Pipelines
Status: Stub Category: Delivery Default enforcement: Soft Author: PushBackLog team
Tags
- Topic: delivery, automation, devops
- Skillset: devops, backend
- Technology: generic
- Stage: deployment, execution
Summary
Continuous Integration (CI) is the practice of automatically building and testing every code change as it is merged. Continuous Delivery (CD) extends this by ensuring the software is always in a deployable state; Continuous Deployment takes it further by automatically deploying every passing build to production. Together, CI/CD pipelines are the infrastructure of reliable, frequent software delivery.
Rationale
Manual deployment processes are slow, error-prone, and impossible to run consistently. Teams that deploy manually deploy rarely, and teams that deploy rarely accumulate large changes between releases. Large changes between releases are harder to test, harder to debug when they fail, and harder to roll back.
CI/CD pipelines invert this. By making the path from committed code to deployed software automated and fast, they make frequent small deployments the natural mode of operation. Frequency reduces batch size. Small batch sizes reduce risk. Automated validation gates on every change prevent regressions from reaching production undetected.
Guidance
Continuous Integration
Every commit to a shared branch should trigger:
- Build — compile, transpile, or bundle the application
- Lint — enforce code style and static analysis rules
- Unit tests — fast feedback on logic correctness
- Integration tests — validate inter-component or inter-service behaviour
CI gates must be fast (under 10 minutes is a useful target for developer feedback loops) and must block merges on failure. A CI gate that can be bypassed or ignored is not a gate — it is a suggestion.
Trunk-based development (merging to a single main branch frequently) works best with CI. Long-lived feature branches accumulate drift and produce integration events rather than continuous integration.
Continuous Delivery
CD extends CI with automated deployment to one or more pre-production environments. The pipeline continues: 5. Build artefact — produce the deployable (container image, package, archive) 6. Deploy to staging — deploy the artefact to an environment that mirrors production 7. E2E / smoke tests — validate the deployed application behaves correctly end-to-end 8. Manual approval gate (optional) — human sign-off before production
At any point in this pipeline, the software should be in a releasable state. CD does not mean deploying continuously — it means maintaining the capability to deploy on demand, at any time, without ceremony.
Continuous Deployment
Continuous Deployment removes the manual approval gate. Every build that passes all automated checks is deployed to production automatically. This requires:
- High confidence in test coverage
- Feature flags to separate deployment from release
- Robust rollback or forward-fix capabilities
- Strong observability to detect regressions in production quickly
Pipeline design principles
| Principle | Description |
|---|---|
| Fail fast | Put the fastest, most discriminating checks first |
| Idempotent | Running the pipeline twice produces the same result |
| Reproducible | Same inputs always produce the same outputs |
| Auditable | Every deployment is traceable to a specific commit and build run |
| Secure | Secrets are injected at runtime, never committed; pipeline permissions follow least privilege |
Branch strategy and pipelines
| Branch | Pipeline trigger | Deploys to |
|---|---|---|
| Feature branch (PR) | On push | Nothing (tests only) |
| Main / trunk | On merge | Staging |
| Tag / release | On tag push | Production |
Secrets management in pipelines
Pipeline secrets (API keys, registry credentials, deployment tokens) must:
- Never appear in source code or pipeline configuration files
- Be stored in a secrets manager (Vault, AWS Secrets Manager, GitHub Actions secrets)
- Be scoped to the minimum permissions required
- Be rotated on schedule
Common failure modes
| Failure | Description |
|---|---|
| Flaky tests | Tests that fail intermittently cause pipeline noise and erode trust in the gate |
| Slow pipelines | Long feedback loops cause developers to batch work or bypass CI |
| Manual deployments alongside pipelines | Drift between automated and manual deployments; pipeline becomes untrustworthy |
| Secrets in config | Credentials committed to repositories or hardcoded in pipeline YAML |
| No rollback strategy | Deployments succeed but cannot be reversed when a problem is discovered post-deploy |