From e0f6a44823143d28d3db0712ae1a3b3f41051945 Mon Sep 17 00:00:00 2001 From: Oliver Davies Date: Mon, 5 Jun 2023 23:22:42 +0100 Subject: [PATCH] daily-email: add 2023-06-05 --- src/content/daily-email/2023-06-05.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 src/content/daily-email/2023-06-05.md diff --git a/src/content/daily-email/2023-06-05.md b/src/content/daily-email/2023-06-05.md new file mode 100644 index 000000000..bd289c1ad --- /dev/null +++ b/src/content/daily-email/2023-06-05.md @@ -0,0 +1,19 @@ +--- +title: > + How long should a feature flag live? +pubDate: 2023-06-05 +permalink: > + archive/2023/06/05/how-long-should-a-feature-flag-live +tags: + - software-development + - software-engineering + - feature-flags +--- + +Instead of creating a branch that lives for as long as the code takes to write, if it's behind a feature flag, the code can be merged into the mainline branch without affecting the rest of the codebase. + +Being able to release changes incrementally lowers the risk compared to releasing a large change all at once. + +But the same issue can occur with feature flags, and the longer that code is behind a feature flag, the more risk there will be when enabling the feature. + +So, like feature branches, feature flags should be short-lived and only used for as long as is needed to create the first releasable version of the feature. The feature flag can be removed once the feature is live, and the feature can continue to be iterated on and improved.