It's More Than Feature Toggles: ...
summary
Argues that feature toggles are technical debt and must be codified as enums/classes, tied into CI so every check‑in builds, packages, and deploys a sealed artifact; shows a Parts Unlimited demo where a toggle causes a performance spike but New Relic monitoring and automated integration tests catch it. Recommends specflow/specb bindings, using deployment variables to flip toggles, limiting to 4–5 toggles max, and running frequent releases—one team starts releasing every check‑in to production daily.
AI-written summary · about
chapters (19)
- 0:00Intro
- 0:23ABOUT ME
- 2:37WHAT MAKES THIS WORK?
- 3:21THE SHARED SANDBOX
- 5:13ACHIEVING TRUNK DEVELOPMENT
- 6:39A TALE OF ONE (REAL) TEAM
- 9:37MAKING TOGGLES EXPLICIT
- 11:23TOGGLES ARE TECH DEBT
- 12:13TOGGLES AND DEPLOYMENT
- 13:10DEPLOYMENT KATA
- 14:46INVERSION OF CONTROL
- 15:23EXTENDING TO FEATURE TOGGLES
- 20:51COMMAND & QUERY RESPONSIBILITY SEGREGATION
- 21:57EXAMPLE STORE PURCHASE
- 23:31ENTER: SPECBIND
- 25:32LINKING TO TOGGLES
- 27:41RUNTIME FEEDBACK
- 28:19DIG DEEPER FOR DATA
- 29:40TAKE AWAY CONCEPTS
related talks
35mFeature Toggles: The Good, The Bad, and The Ugly
30mFeature toggles: ask us anything
20mFeature Flag-Driven Development… in Reverse
43mFeature Toggles: The Good, The Bad and The Ugly
18mTrunk Based Development and Feature Toggles
51mFeature Toggles, or How to Deploy Features Without a Release
01h 09mFeature flags: the toggle, the A/B test and the canary
50mFeature Toggle Promotion via CI/CD Pipeline