92 lines
3.2 KiB
YAML
92 lines
3.2 KiB
YAML
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: { }
|