Migrate content to YAML
This commit is contained in:
parent
3d76aa0c3b
commit
9d5a930eab
4550 changed files with 93849 additions and 129734 deletions
76
content/node.235bcd7b-1bdb-4616-99bb-ecd321f449a0.yml
Normal file
76
content/node.235bcd7b-1bdb-4616-99bb-ecd321f449a0.yml
Normal file
|
@ -0,0 +1,76 @@
|
|||
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: { }
|
Loading…
Add table
Add a link
Reference in a new issue