Continuous integration - that's not what they meant
summary
Claim: true continuous integration means everyone commits to mainline daily, each commit triggers automated build and tests, and failures return to green within 10 minutes, not just CI-labeled products or long-lived branches. The talk shows practices to get there: automated incremental tests, fast local builds, TDD, refactoring to minimize dependencies, and collaboration patterns like pair/mob programming and many more much smaller steps. Warnings: feature flags must be limited; auditors accept CI if traceability is demonstrated.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 1:05What is CI
- 3:37Continuous integration vs continuous delivery
- 7:11Problem with feature branches
- 11:21Why PRs fail
- 15:59Compliance and continuous integration
- 19:44Dangers of big bang trunk dev
- 21:52Role of tech coaching
- 23:56CI needs good code
- 27:26Keeping build green
- 29:32Smaller steps
- 33:09Unfinished features in trunk dev
- 35:59Key benefits of continuous integration
- 39:09Q&A
related talks
56mContinuous Integration: That’s Not What They Meant
45mContinuous Integration: That’s Not What They Meant
01h 15mThe Practices That Make Continuous Integration
34mContinuous Integration: A Bittersweet Love Story
31mContinuous Integration 101 for Devs
11mCreate unfair competitive advantage w/CI/CD Pipelines
32mBuilding Confidence Together: Continuous Integration & Testing
38mContinuous Integration May Have Negative Effects
