Three terms, two acronyms, one enormous amount of industry confusion. "CI/CD" is used as a single phrase so often that many engineers treat it as one thing. It isn't. Continuous Integration, Continuous Delivery, and Continuous Deployment are distinct practices with different prerequisites, different QA implications, and different levels of maturity. This lesson draws the lines clearly so you can talk about them precisely and understand what each one demands from testing.
Continuous Integration
Continuous Integration (CI) is the practice of developers merging their code into a shared main branch frequently — ideally multiple times per day — with automated tests running on every merge.
The problem CI solves is "integration hell": two developers work on separate branches for a week, then try to merge. Their changes conflict in unexpected ways. Business logic that worked in isolation breaks when combined. The later you integrate, the more painful it is.
CI forces integration early and often. Every commit triggers: build the code, run the test suite, report pass or fail. If integration breaks something, the developer finds out within minutes — while the context is fresh.
What CI requires from QA:
- A fast, reliable automated test suite that runs on every commit
- Tests that cover the integration points between components (not just unit tests)
- A commitment to fixing broken tests immediately — a failing CI build that's ignored defeats the entire purpose
CI tools: GitHub Actions, Jenkins, GitLab CI, CircleCI, TeamCity, AWS CodeBuild.
Continuous Delivery
Continuous Delivery takes CI further: every commit that passes the CI pipeline is packaged and deployed to a staging environment automatically. At any point, a human can push a button to release that build to production.
The key word is "can" — not "does automatically." Continuous Delivery keeps the release pipeline ready and the staging environment always up to date, but the final step to production is a deliberate human decision. This is the right model for teams that need a manual approval gate before production — a sign-off from a product manager, a business stakeholder, or a regulatory requirement.
What Continuous Delivery requires from QA:
- Automated deployment to staging, including any database migrations and configuration changes
- Automated smoke tests that run against staging after every deployment
- Confidence that the automated test suite is comprehensive enough that manual QA before production is minimal — not a week-long cycle
- Clear "definition of done" for what makes a build production-ready
Continuous Delivery shifts QA from gatekeeper (manual sign-off before release) to enabler (build the automated safety net that makes sign-off routine).
Continuous Deployment
Continuous Deployment removes the human from the final step. Every commit that passes the full pipeline — CI tests, staging deployment, staging smoke tests — is automatically promoted to production. No button. No approval. Every green build ships.
This is the most mature and demanding practice. It requires:
- An automated test suite comprehensive enough to trust for production releases
- Feature flags to release code that isn't ready for users without deploying it separately
- Canary deployments or blue-green deployments to limit the blast radius of a bad release
- Production monitoring and alerting so a bad release is caught and rolled back within minutes
- A culture where "revert and fix forward" is preferred over long pre-release gates
Most teams are not doing Continuous Deployment. Most are doing CI (tests run automatically) or are partway toward Continuous Delivery (staging is always deployable). Continuous Deployment is the goal for the highest-velocity, highest-trust teams — and it requires years of investment in testing and infrastructure to reach safely.
QA's role at each stage of maturity
| Practice | QA involvement | Key QA deliverable |
|---|---|---|
| CI | Tests run automatically, team fixes failures | Fast, reliable automated suite; zero ignored failures |
| Continuous Delivery | Staging always tested; human approves production | Comprehensive automation + staging smoke gate |
| Continuous Deployment | Tests ARE the release gate | Exhaustive automation + feature flags + monitoring |
The progression is a maturity ramp. Each step demands more from the automated test suite and shifts more responsibility from manual QA to engineering discipline.
The "shift left" connection
All three practices share a common thread: quality moves earlier in the development lifecycle. In a waterfall model, QA sits at the end and tests a complete build. In a CI/CD model, quality is built in at every stage — requirements review, code review, automated testing, pipeline gates. By the time code reaches production in a mature Continuous Deployment shop, it has passed dozens of automated checks that together provide more coverage than a traditional two-week manual test cycle.
"Shift left" is the name for this trend. The further left (earlier) a bug is caught, the cheaper it is to fix. A requirement ambiguity caught in planning costs an hour. The same misunderstanding caught in a production incident costs days.
⚠️ Common mistakes
- Calling everything "CI/CD" regardless of what's actually in place. If tests run automatically but every deployment requires a three-day manual QA cycle, that's CI with a manual gate — not Continuous Delivery. The distinction matters when you're planning test coverage strategy.
- Jumping to Continuous Deployment without the test foundation. Teams that auto-deploy to production with a weak test suite ship bugs automatically. The speed gain from removing the manual gate disappears in the time spent on production incidents.
- Treating Continuous Deployment as the goal for every team. Some domains — medical software, financial systems, government infrastructure — have regulatory requirements that mandate manual approval gates. Continuous Delivery is the right ceiling for those contexts.
🎯 Practice task
Map your team's current practice — 10 minutes.
- Answer honestly: when a developer merges to main, what happens automatically? If the answer is "nothing," that's the baseline.
- Is there a staging environment? Does it get updated automatically after every merge, or manually when someone remembers?
- How does code get to production? Is there a manual approval step? Who approves it?
- Based on your answers, classify your team: pre-CI, CI only, approaching Continuous Delivery, or Continuous Deployment.
- Write one sentence about what would need to change to move one step up the maturity ramp. (For most teams: the first step is getting a fast automated test suite running on every pull request — which is exactly what the next chapter covers with GitHub Actions.)
The next lesson covers the QA engineer's specific role in a CI/CD team — what skills are new, what skills carry over, and what "owning the pipeline" actually means day to day.