Home / Insights / Architecture and Modernization
Architecture and Modernization
Designing a CI/CD Pipeline: Stages, Quality Gates and Safe Deployment
A good CI/CD pipeline lets teams release small changes often with confidence. This guide explains the difference between continuous integration, delivery and deployment, the stages and gates of a practical pipeline, safe deployment strategies and how to measure and improve it.
TopicsArchitecture and ModernizationQA and Software TestingWeb and SaaS Development
Key takeaways
- Continuous integration merges small changes frequently and verifies each automatically; continuous delivery keeps every change releasable; continuous deployment releases every passing change automatically.
- A practical pipeline has build, test, security, packaging, deployment and verification stages, with gates that block bad changes early.
- Keep the fast feedback loop under about ten minutes for most changes; run slower suites in parallel or on a schedule.
- Deploy with strategies that limit blast radius — rolling, blue-green, canary and feature flags — and automate rollback.
- Measure lead time, deployment frequency, change failure rate and time to restore, and improve the pipeline like a product.
On this page
Many teams still release software in large, infrequent batches: weeks of changes merged at once, a manual test cycle, a late-night deployment and a tense morning after. CI/CD replaces that with a steady flow of small, automatically verified changes. The result is faster delivery and, counter-intuitively, fewer failures, because each change is small and easy to diagnose.
Three related practices
| Practice | What it means | Prerequisite |
|---|---|---|
| — | — | — |
| Continuous integration (CI) | Developers merge small changes into the main branch frequently; each merge is built and tested automatically | Fast automated tests; trunk-based or short-lived branches |
| Continuous delivery | Every change that passes the pipeline is releasable; release is a business decision | Reliable deployment automation and environments |
| Continuous deployment | Every passing change is deployed to production automatically | High test confidence, monitoring and automated rollback |
Most teams aim for continuous delivery first; continuous deployment suits mature products and teams.
Pipeline stages
| Stage | Activities | Gate |
|---|---|---|
| — | — | — |
| Commit | Lint, format, type checks, unit tests | Fails fast on basic errors |
| Build | Compile, bundle, build container images | Reproducible, versioned artefacts |
| Test | Integration, API and contract tests; component tests | Required suites pass |
| Security | Dependency scanning, secret scanning, static analysis, image scanning | No critical issues unaddressed |
| Package | Store signed artefacts in a registry | Artefact integrity |
| Deploy to staging | Infrastructure as code, database migrations, configuration | Successful deployment and smoke tests |
| Verify | End-to-end tests, performance checks, accessibility checks | Critical journeys pass |
| Release to production | Progressive deployment strategy | Health checks and metrics within thresholds |
| Observe | Monitoring, alerts, error tracking | Automated rollback triggers |
Build once and promote the same artefact through every environment.
Keep feedback fast
- Run the fastest checks first and fail early.
- Parallelise tests and cache dependencies.
- Use test impact analysis to run tests related to the change, with the full suite on merge or nightly.
- Fix or quarantine flaky tests immediately; they erode trust in the pipeline.
- Keep environments reproducible with infrastructure as code.
Deployment strategies
| Strategy | How it works | Best for |
|---|---|---|
| — | — | — |
| Rolling | Replace instances gradually | Stateless services with good health checks |
| Blue-green | Switch traffic from the old environment to a fully prepared new one | Fast rollback; larger infrastructure cost |
| Canary | Send a small share of traffic to the new version, increase if healthy | High-traffic services where metrics detect problems |
| Feature flags | Deploy code dark; enable features for selected users | Separating deployment from release; experiments |
Combine strategies: canary deployment plus feature flags is common.
Database changes need special care: use backward-compatible migrations — expand, migrate, then contract — so old and new versions can run together. Our guide to zero-downtime migration covers this pattern.
Rollback and recovery
- Automate rollback on failed health checks or metric thresholds.
- Keep previous artefacts ready for redeployment.
- Make data changes reversible or forward-fixable.
- Practise recovery so it is routine, not an emergency improvisation.
Security in the pipeline
- Store secrets in a secret manager, never in pipeline configuration.
- Restrict who can change pipelines and deploy to production.
- Sign artefacts and verify signatures before deployment.
- Scan dependencies and images, and keep base images current.
- Log pipeline actions for audit.
Metrics
Track the four delivery measures popularised by DORA research — lead time for changes, deployment frequency, change failure rate and time to restore service — alongside pipeline duration, flaky test rate and the share of deployments needing manual steps.
Maturity path
- Automate builds and unit tests on every pull request.
- Automate deployment to staging with infrastructure as code.
- Add integration, security and end-to-end gates.
- Automate production deployment with a manual approval.
- Introduce progressive delivery — canary and feature flags — with automated rollback.
- Move to continuous deployment for services where confidence is high.
Frequently asked questions
Which CI/CD tool should we use?
Use the one that fits your repository host and cloud, such as the built-in CI of your code platform. Pipeline design matters more than the tool.
How often should we deploy?
As often as small, verified changes are ready. Many teams deploy daily or several times a day once the pipeline is reliable.
Do we need continuous deployment?
Not necessarily. Continuous delivery — always releasable, with a deliberate release decision — suits many businesses, especially with regulated or scheduled releases.
How do we start with a legacy application?
Automate the build and a small set of smoke tests first, then add tests around the areas you change most.
Sources and methodology
Facts in this article were checked against the sources below on 6 November 2026. Directory data (ratings, review counts, rate bands and team sizes) changes over time and is shown as published on the date accessed. Illustrative examples are labelled as such and are not quotes.
- Danilo Sato (martinfowler.com): Parallel Change — accessed 6 November 2026. Expand, migrate and contract for backward-compatible changes
Related reading
Continue your research
Releases slow, risky or manual?
Share your current process and stack. We will help you design a pipeline with the right tests, gates and deployment strategy for your product.