Continuous Integration: I Invite You to Break My Build
summary
Argues that breaking the build is acceptable when the team fixes it quickly and uses CI to surface environment mismatches; recommends okay to break the build but don't leave it broken, run builds on every commit and run at least one integration job CI every 15 minutes to catch third‑party regressions. Use multiple CI environments (OS, DB, library versions) with staggered notifications, keep the repo releasable at all times, avoid punitive shaming, and expect outcomes like catching a provider rollback and finishing a client project weeks early with no post‑release bug fixes.
AI-written summary · about
chapters (9)
- 0:00Introduction and title explanation
- 1:25Philosophy of breaking builds
- 8:53Agile development as feedback-driven
- 17:23Keeping software releasable at all times
- 27:52Broken window theory in code
- 36:49Continuous integration fundamentals
- 44:43Benefits of continuous integration
- 52:56Handling environment differences
- 1:00:08Q&A and summary
related talks
38mContinuous Integration May Have Negative Effects
34mContinuous Integration: A Bittersweet Love Story
46mContinuous integration - that's not what they meant
32mBuilding Confidence Together: Continuous Integration & Testing
45mContinuous Integration: That’s Not What They Meant
56mContinuous Integration: That’s Not What They Meant
01h 15mThe Practices That Make Continuous Integration
32mContinuous Integration and Deployment: Five Lessons Learned