104 lines
4.9 KiB
YAML
104 lines
4.9 KiB
YAML
uuid:
|
|
- value: 0a4f05ae-4240-476b-bb57-bcf3d3a598a3
|
|
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:01+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: "Don't branch, use feature toggles"
|
|
created:
|
|
- value: '2025-02-20T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:01+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2025/02/20/toggles
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>If <a href="/daily/2025/02/18/conflicts">feature branches cause conflicts</a>, what is the alternative?</p>
|
|
|
|
<p>Don't branch.</p>
|
|
|
|
<p>Keep all changes on a single branch and avoid merge conflicts between branches by not having branches.</p>
|
|
|
|
<p>But how can you avoid releasing changes before they are ready?</p>
|
|
|
|
<p>You can have a local branch with your changes that you don't push and rebase locally, but then <a href="/daily/2025/02/17/ci-cd">you're not doing continuous integration</a> and you're just as likely to get conflicts and have incompatible code.</p>
|
|
|
|
<p>One of the main benefits of trunk-based development, where everything is on a single branch, is that everyone's work always works together.</p>
|
|
|
|
<p>The better option is to use feature toggles (aka feature flags).</p>
|
|
|
|
<p>Wrapping code in feature toggles separates deploying the code from releasing the feature.</p>
|
|
|
|
<p>The code can be released, but the feature isn't active until the toggle is enabled.</p>
|
|
|
|
<p>This means everyone can work on the same branch and continuously deploy changes whilst being selective about the features that are visible to the end users.</p>
|
|
|
|
<p>If you have multiple environments, the same code can be used with different toggles enabled to allow for testing different features.</p>
|
|
|
|
<p>Then, once the feature is ready to be enabled, there is no deployment needed.</p>
|
|
|
|
<p>The code is already there - it just needs to be enabled.</p>
|
|
|
|
<p>For Drupal, there is a <a href="https://www.drupal.org/project/feature_toggle">Feature Toggle module</a> and <a href="https://www.drupal.org/project/feature_toggle_twig">an extension that I wrote</a> that make it easy to use and manage feature toggles by just logging into the admin UI and selecting the active toggles you want.</p>
|
|
|
|
<p>And, if an issue is discovered, it can also be easily disabled <a href="/daily/2025/02/19/back-or-forward">without needing to roll back to the previous version</a>.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>If <a href="http://default/daily/2025/02/18/conflicts">feature branches cause conflicts</a>, what is the alternative?</p>
|
|
|
|
<p>Don't branch.</p>
|
|
|
|
<p>Keep all changes on a single branch and avoid merge conflicts between branches by not having branches.</p>
|
|
|
|
<p>But how can you avoid releasing changes before they are ready?</p>
|
|
|
|
<p>You can have a local branch with your changes that you don't push and rebase locally, but then <a href="http://default/daily/2025/02/17/ci-cd">you're not doing continuous integration</a> and you're just as likely to get conflicts and have incompatible code.</p>
|
|
|
|
<p>One of the main benefits of trunk-based development, where everything is on a single branch, is that everyone's work always works together.</p>
|
|
|
|
<p>The better option is to use feature toggles (aka feature flags).</p>
|
|
|
|
<p>Wrapping code in feature toggles separates deploying the code from releasing the feature.</p>
|
|
|
|
<p>The code can be released, but the feature isn't active until the toggle is enabled.</p>
|
|
|
|
<p>This means everyone can work on the same branch and continuously deploy changes whilst being selective about the features that are visible to the end users.</p>
|
|
|
|
<p>If you have multiple environments, the same code can be used with different toggles enabled to allow for testing different features.</p>
|
|
|
|
<p>Then, once the feature is ready to be enabled, there is no deployment needed.</p>
|
|
|
|
<p>The code is already there - it just needs to be enabled.</p>
|
|
|
|
<p>For Drupal, there is a <a href="https://www.drupal.org/project/feature_toggle">Feature Toggle module</a> and <a href="https://www.drupal.org/project/feature_toggle_twig">an extension that I wrote</a> that make it easy to use and manage feature toggles by just logging into the admin UI and selecting the active toggles you want.</p>
|
|
|
|
<p>And, if an issue is discovered, it can also be easily disabled <a href="http://default/daily/2025/02/19/back-or-forward">without needing to roll back to the previous version</a>.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|