77 lines
2.8 KiB
YAML
77 lines
2.8 KiB
YAML
|
uuid:
|
||
|
|
- value: 235bcd7b-1bdb-4616-99bb-ecd321f449a0
|
||
|
|
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:14+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: 'Testing topic branches in isolation'
|
||
|
|
created:
|
||
|
|
- value: '2024-04-24T00:00:00+00:00'
|
||
|
|
changed:
|
||
|
|
- value: '2025-05-11T09:00:14+00:00'
|
||
|
|
promote:
|
||
|
|
- value: false
|
||
|
|
sticky:
|
||
|
|
- value: false
|
||
|
|
default_langcode:
|
||
|
|
- value: true
|
||
|
|
revision_translation_affected:
|
||
|
|
- value: true
|
||
|
|
path:
|
||
|
|
- alias: /daily/2024/04/26/testing-topic-branches-in-isolation
|
||
|
|
langcode: en
|
||
|
|
body:
|
||
|
|
- value: |
|
||
|
|
<p>I was recently asked about setting up different testing environments based on topic (a.k.a. feature) branches.</p>
|
||
|
|
|
||
|
|
<p>When a feature or bug fix was finished, it would create a new environment for it to be tested.</p>
|
||
|
|
|
||
|
|
<p>If it passed testing, the topic branch was merged and it would be included in the next release.</p>
|
||
|
|
|
||
|
|
<p>But, there's no guarantee it still works once it's been merged.</p>
|
||
|
|
|
||
|
|
<p>It could conflict with changes from a different topic branch and no longer work - even if it worked when it was tested in isolation on its own branch.</p>
|
||
|
|
|
||
|
|
<p>To ensure it still works, it will need to be tested again.</p>
|
||
|
|
|
||
|
|
<p>So, what is the benefit of testing it in isolation if it needs to be tested again once it's merged?</p>
|
||
|
|
|
||
|
|
<p>This is why I prefer continuous integration and delivery (CI/CD), as I always know all changes work together and not just in isolation.</p>
|
||
|
|
|
||
|
|
|
||
|
|
format: full_html
|
||
|
|
processed: |
|
||
|
|
<p>I was recently asked about setting up different testing environments based on topic (a.k.a. feature) branches.</p>
|
||
|
|
|
||
|
|
<p>When a feature or bug fix was finished, it would create a new environment for it to be tested.</p>
|
||
|
|
|
||
|
|
<p>If it passed testing, the topic branch was merged and it would be included in the next release.</p>
|
||
|
|
|
||
|
|
<p>But, there's no guarantee it still works once it's been merged.</p>
|
||
|
|
|
||
|
|
<p>It could conflict with changes from a different topic branch and no longer work - even if it worked when it was tested in isolation on its own branch.</p>
|
||
|
|
|
||
|
|
<p>To ensure it still works, it will need to be tested again.</p>
|
||
|
|
|
||
|
|
<p>So, what is the benefit of testing it in isolation if it needs to be tested again once it's merged?</p>
|
||
|
|
|
||
|
|
<p>This is why I prefer continuous integration and delivery (CI/CD), as I always know all changes work together and not just in isolation.</p>
|
||
|
|
|
||
|
|
|
||
|
|
summary: null
|
||
|
|
field_daily_email_cta: { }
|