Feature Flags: Separate Deployment from Feature Release
summary
Feature flags let teams separate deployment from release by shipping both old and new code paths behind an if check and toggling them from a config file, a DB, or a hosted service. Live demos use a simple JSON/env config, SQLite with user overrides (John/Jane/Heather), and services like LaunchDarkly and Azure App Configuration; LaunchDarkly’s SDK pushes updates immediately while Azure shows caching/restart tradeoffs. Best practices: keep flags temporary (a handful, dozen max), add an expiry date test in CI, and remove old code once stable.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 1:42What are feature flags
- 2:23Anti-patterns and benefits
- 5:35Storing feature flags
- 11:19Config file demo
- 15:58Client-side feature flags
- 17:03Database storage demo
- 22:27User context overrides
- 26:05External service options
- 29:17Launch Darkly demo
- 33:18Azure App Config demo
- 37:57Best practices summary
- 39:46When not to use feature flags
related talks
44mFlagging features — a DevOps approach to continuous release
54mFeature Flags Separate Deployment from Feature Release
01h 09mFeature flags: the toggle, the A/B test and the canary
59mFaster & less risky releases with feature flags
35mA Deployment Is Not a Release, Controlled Launches with Feature Flags
27mJust Enough Feature Flagging
30mChoose Your Own Deployment: Interactive Feature Flag Adventure
08mThe Art of Feature Flagging