Pushing to master - adopting trunk based development
summary
State of DevOps data-backed claim: adopting trunk-based development drives higher deployment frequency and quality, but it requires concrete practices not slogans. Implemented roots include RFC design docs, strict TDD, a CI/CD pipeline (Jenkins or GitHub Actions), and feature flags via LaunchDarkly to test in prod. Teams see 10–15 commits per day, test suites up to ~20 minutes, a reported 50–90% defect drop, and at one company 69 engineers and 88 active feature flags enable shipping tiny changes that otherwise took two months to approve.
AI-written summary · about
chapters (21)
- 0:00Introduction
- 1:27Zappy engineering challenges
- 2:32DORA metrics
- 4:01Trunk-based development
- 5:49Long-lived branches problems
- 7:56Implementing TBD effectively
- 9:21TBD key benefits
- 11:28Excuses for not adopting TBD
- 12:32TBD for junior devs
- 14:15Four roots for TBD
- 14:36Design and RFCs
- 17:04Design versus deployments
- 18:08Test-driven development
- 20:36Continuous integration
- 21:37Continuous deployment
- 22:18Feature flags
- 23:00Feature flags in practice
- 25:26Adopting best practices
- 26:29Driving adoption
- 27:32Why TBD is hard
- 28:13Q&A
related talks
35mIncrease Agility and Quality Using Trunk-Based Development in Continuou...
39mOur journey from Gitflow to Trunk Based Development
18mTrunk Based Development and Feature Toggles
01h 01mA team's transition to Continuous Delivery
48mDevOps Culture & Practices to Create Flow
45mContinuous Integration: That’s Not What They Meant
34mYou only have to change one thing to do the DevOps
25mFrom Git Push to Exit