Move all files to tome/

tome/content/node.ea81e659-48e0-4eaf-ae3b-a30012102d0e.yml

@@ -0,0 +1,92 @@
+uuid:
+  - value: ea81e659-48e0-4eaf-ae3b-a30012102d0e
+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: 'Roll back or fix forward?'
+created:
+  - value: '2025-02-19T00: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/19/back-or-forward
+    langcode: en
+body:
+  - value: |
+      <p>You deploy a code change but it creates an issue.</p>
+
+      <p>Maybe it breaks a feature, adds a bug or takes down an environment completely.</p>
+
+      <p>How do you resolve it?</p>
+
+      <p>Larger releases will sometimes have a roll back plan that details how to revert to the previous release.</p>
+
+      <p>This can be difficult, especially for large releases and ones that change the database schema or values.</p>
+
+      <p>Because of the amount of change, diagnosing an issue in a large release can take time.</p>
+
+      <p>If it's been a while since the prior release, it can be some time since the code that introduced the issue was worked on - making it harder to fix.</p>
+
+      <p>I prefer to do small releases and do them often.</p>
+
+      <p>Some releases contain a single commit which was made only minutes since the previous release.</p>
+
+      <p>This makes it easier to identify the issue, fix it and deploy a new version.</p>
+
+      <p>No rolling back database changes or reverting to previous releases.</p>
+
+      <p>Small, iterative deployments are less risky than large infrequent ones, easier to fix and make changes available to end users sooner.</p>
+
+              
+    format: full_html
+    processed: |
+      <p>You deploy a code change but it creates an issue.</p>
+
+      <p>Maybe it breaks a feature, adds a bug or takes down an environment completely.</p>
+
+      <p>How do you resolve it?</p>
+
+      <p>Larger releases will sometimes have a roll back plan that details how to revert to the previous release.</p>
+
+      <p>This can be difficult, especially for large releases and ones that change the database schema or values.</p>
+
+      <p>Because of the amount of change, diagnosing an issue in a large release can take time.</p>
+
+      <p>If it's been a while since the prior release, it can be some time since the code that introduced the issue was worked on - making it harder to fix.</p>
+
+      <p>I prefer to do small releases and do them often.</p>
+
+      <p>Some releases contain a single commit which was made only minutes since the previous release.</p>
+
+      <p>This makes it easier to identify the issue, fix it and deploy a new version.</p>
+
+      <p>No rolling back database changes or reverting to previous releases.</p>
+
+      <p>Small, iterative deployments are less risky than large infrequent ones, easier to fix and make changes available to end users sooner.</p>
+
+              
+    summary: null
+field_daily_email_cta: {  }