Effective CI/CD for Large Systems
summary
Argues CI must be fast and component-driven: targets 5–15 minute CI for quick feedback and 15–30 minute deployments for safe rollbacks, else developers batch and lose context. Shows combinatorial cost: a 4‑component system with 3–6 interactions needs about 1800 combinatorial tests, and a 1.1% flaky test rate produces ~20% overall failure by ~220 tests and ~50% by ~693 tests. Recommends trunk‑based development, feature flags, canary releases, monorepo tooling and splitting tests as in Ivan’s cloud volume rescue workflow across eight public clouds.
AI-written summary · about
chapters (21)
- 0:00Intro
- 0:39This talk is not
- 3:52Other Industries?
- 6:22CI/CD questions
- 12:37Parallel test running
- 14:00How to escape?
- 15:25Components have contracts
- 16:18Combinatorial Explosion
- 18:37System of Gates
- 24:43Waiting is a Time Sink
- 27:44Case study: add-vm-volume
- 33:55Design goal: Confidence
- 34:34Rapid releasability
- 35:46Feature flags
- 36:32Smaller Pipelines
- 37:18Monorepo Tools
- 38:05Observability
- 38:50Deployment automation
- 39:10Rollback automation
- 39:42Refactoring tools
- 40:50Test-driven development
related talks
32mPractical Tips & Tricks for CI/CD Success
24mCI/CD Best Practices to Deliver Software Faster
48mDemystifying CI/CD
51mBetter software, faster: principles of Continuous Delivery and DevOps
32mClimbing the Mountain of CI/CD: A Tester’s Tale
38mCI is Essential but not Sufficient for an Effective Application Delivery Workflow
17mCI/CD - Build/Deploy Automation
44mSimplifying and Scaling Software Delivery
