61 lines
2.5 KiB
YAML
61 lines
2.5 KiB
YAML
uuid:
|
|
- value: 5ec8d076-631f-428e-aaf3-44fef2b83bac
|
|
langcode:
|
|
- value: en
|
|
type:
|
|
- target_id: daily_email
|
|
target_type: node_type
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
|
revision_timestamp:
|
|
- value: '2025-05-11T09:00:40+00:00'
|
|
revision_uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
revision_log: { }
|
|
status:
|
|
- value: true
|
|
uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
title:
|
|
- value: |
|
|
How long should a feature flag live?
|
|
created:
|
|
- value: '2023-06-05T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:40+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2023/06/05/how-long-should-a-feature-flag-live
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>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.</p>
|
|
|
|
<p>Being able to release changes incrementally lowers the risk compared to releasing a large change all at once.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>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.</p>
|
|
|
|
<p>Being able to release changes incrementally lowers the risk compared to releasing a large change all at once.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|