Migrate content to YAML
This commit is contained in:
parent
3d76aa0c3b
commit
9d5a930eab
4550 changed files with 93849 additions and 129734 deletions
96
content/node.9533c89f-d5dd-4959-ba2c-66be5df70f60.yml
Normal file
96
content/node.9533c89f-d5dd-4959-ba2c-66be5df70f60.yml
Normal file
|
@ -0,0 +1,96 @@
|
|||
uuid:
|
||||
- value: 9533c89f-d5dd-4959-ba2c-66be5df70f60
|
||||
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:22+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: 'Daily or quarterly?'
|
||||
created:
|
||||
- value: '2024-01-16T00:00:00+00:00'
|
||||
changed:
|
||||
- value: '2025-05-11T09:00:22+00:00'
|
||||
promote:
|
||||
- value: false
|
||||
sticky:
|
||||
- value: false
|
||||
default_langcode:
|
||||
- value: true
|
||||
revision_translation_affected:
|
||||
- value: true
|
||||
path:
|
||||
- alias: /daily/2024/01/16/daily-or-quarterly
|
||||
langcode: en
|
||||
body:
|
||||
- value: |
|
||||
<p>Imagine this scenario.</p>
|
||||
|
||||
<p>You have two options on how frequently you can deploy code changes to your application.</p>
|
||||
|
||||
<p>Option 1: Every day.</p>
|
||||
|
||||
<p>Option 2: Once a quarter.</p>
|
||||
|
||||
<p>No more, no less.</p>
|
||||
|
||||
<p>I'd choose daily.</p>
|
||||
|
||||
<p>I much prefer to deploy changes as often as possible rather than waiting.</p>
|
||||
|
||||
<p>I'm much more confident when releasing small changes - even if it's a small refactor, such as changing a variable name or extracting a small helper method.</p>
|
||||
|
||||
<p>It might even seem too small to release.</p>
|
||||
|
||||
<p>But the smaller the release is, the easier it is to find and fix any issues, and knowing that the next release would only be the following day makes it easier to fix forward instead of rolling back a large release with months of changes.</p>
|
||||
|
||||
<h2 id="here%27s-the-thing">Here's the thing</h2>
|
||||
|
||||
<p>Whilst it may seem counterintuitive initially, it's much less risky to release small changes often compared to large changes infrequently.</p>
|
||||
|
||||
<p>Which option would you choose?</p>
|
||||
|
||||
|
||||
format: full_html
|
||||
processed: |
|
||||
<p>Imagine this scenario.</p>
|
||||
|
||||
<p>You have two options on how frequently you can deploy code changes to your application.</p>
|
||||
|
||||
<p>Option 1: Every day.</p>
|
||||
|
||||
<p>Option 2: Once a quarter.</p>
|
||||
|
||||
<p>No more, no less.</p>
|
||||
|
||||
<p>I'd choose daily.</p>
|
||||
|
||||
<p>I much prefer to deploy changes as often as possible rather than waiting.</p>
|
||||
|
||||
<p>I'm much more confident when releasing small changes - even if it's a small refactor, such as changing a variable name or extracting a small helper method.</p>
|
||||
|
||||
<p>It might even seem too small to release.</p>
|
||||
|
||||
<p>But the smaller the release is, the easier it is to find and fix any issues, and knowing that the next release would only be the following day makes it easier to fix forward instead of rolling back a large release with months of changes.</p>
|
||||
|
||||
<h2 id="here%27s-the-thing">Here's the thing</h2>
|
||||
|
||||
<p>Whilst it may seem counterintuitive initially, it's much less risky to release small changes often compared to large changes infrequently.</p>
|
||||
|
||||
<p>Which option would you choose?</p>
|
||||
|
||||
|
||||
summary: null
|
||||
field_daily_email_cta: { }
|
Loading…
Add table
Add a link
Reference in a new issue