Trunk Based Development and Feature Toggles
summary
Claim: shipping requires trunk-based development plus feature toggles so code integrates daily and deploys continuously instead of sitting six months (one cited team wrote 100k LOC without releasing). Implements toggles as feature flags in config/env/db, uses merge to main daily with branch-by-abstraction and expand/contract for schema changes, and supports A/B/percentage rollouts (e.g. 20%) and operational kill-switches for failing services. Practices include short-lived flags with an expiry (days to a week), automated tests, and production telemetry to safely remove flags and reduce long-lived complexity.
AI-written summary · about
chapters (5)
- 0:00Introduction
- 4:13Branch by Abstraction
- 7:33Feature Toggles
- 8:58Types of Feature Toggles
- 14:30How to fix Feature Toggles
related talks
35mIncrease Agility and Quality Using Trunk-Based Development in Continuou...
30mPushing to master - adopting trunk based development
39mOur journey from Gitflow to Trunk Based Development
58mFeature Branches And Toggles In A Post-GitHub World
35mFeature Toggles: The Good, The Bad, and The Ugly
06mDeploying rapidly for continuous integration
20mFeature Flag-Driven Development… in Reverse
41mFeature Flags: Separate Deployment from Feature Release