Continuous Integration and Continuous Delivery
What this domain tests
Continuous Integration and Continuous Delivery tests pipeline design: build once and deploy many, artifact promotion, test stages, quality gates, ephemeral runners, and separating deployment from release.
Core rules and concepts
- CI means integrating to trunk frequently and proving each change with an automated build and fast tests. CD means every validated change is releasable; continuous deployment goes further and releases automatically.
- Build the artifact once, version it immutably, store it in an artifact repository, and promote that same digest through environments. Rebuilding per environment breaks provenance.
- Use a test pyramid: many fast unit tests, fewer integration and service tests, and a small number of end-to-end tests. Slow, flaky end-to-end suites become the bottleneck.
- Pipelines must be deterministic and idempotent. Pin tool and dependency versions, and use ephemeral containerized runners to avoid "works on the build agent."
- Decouple deploy from release using feature flags so code can ship dark and be enabled independently.
Worked example
A pipeline takes 70 minutes; 40 minutes are end-to-end UI tests that fail intermittently. Reasoning: quarantining the flaky tests hides coverage rather than fixing it. First make failures reproducible with retained artifacts, logs, and traces; split the suite into a fast PR gate and a post-merge full run; parallelize shards; and replace redundant UI paths with API-level tests. The goal is a fast, trustworthy signal, not simply a shorter clock.
Traps that cost marks
- Rebuilding the same commit separately for staging and production.
- Adding manual approval to every environment, turning CD into slow release management.
- Treating a green pipeline as proof of production health.
- Caching secrets or credentials in build logs and artifacts.
- Running the entire end-to-end suite on every commit instead of tiering tests.