81 lines
3.7 KiB
YAML
81 lines
3.7 KiB
YAML
uuid:
|
|
- value: dda819a3-30c3-45e3-9cb0-30c1f1ffa48e
|
|
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:30+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: |
|
|
Should you use a staging environment?
|
|
created:
|
|
- value: '2023-09-25T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:30+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2023/09/25/should-you-use-a-staging-environment
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>The purpose of any pre-production version of your website or application (any version that isn't the public live one) is to mimic the production version and as a test run for deployments.</p>
|
|
|
|
<p><strong>If I deploy this feature, will it break the website?</strong></p>
|
|
|
|
<p>The issue with most staging and other pre-production environments is that they differ from what's on production. It may have been some time since the latest data was added, and its value is only as good as how close to production it is and how likely it is to find potential issues in production.</p>
|
|
|
|
<p>If they differ greatly, the staging environment offers no value.</p>
|
|
|
|
<p>It's not a true comparison, and instead of being a test run for a deployment to production, you're only reviewing the deployment to the staging environment itself.</p>
|
|
|
|
<h2 id="here%27s-the-thing">Here's the thing</h2>
|
|
|
|
<p>The best situation I've experienced is where a sanitised snapshot was synced to all pre-production environments every night.</p>
|
|
|
|
<p>I knew that my environment was, at most, a single day out of date, and I was confident that my changes would work in production if they did there.</p>
|
|
|
|
<p>In that situation, the staging site works and testing it has value, but if it's weeks or months out of date, it doesn't, as there are too many differences for it to be an accurate representation.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>The purpose of any pre-production version of your website or application (any version that isn't the public live one) is to mimic the production version and as a test run for deployments.</p>
|
|
|
|
<p><strong>If I deploy this feature, will it break the website?</strong></p>
|
|
|
|
<p>The issue with most staging and other pre-production environments is that they differ from what's on production. It may have been some time since the latest data was added, and its value is only as good as how close to production it is and how likely it is to find potential issues in production.</p>
|
|
|
|
<p>If they differ greatly, the staging environment offers no value.</p>
|
|
|
|
<p>It's not a true comparison, and instead of being a test run for a deployment to production, you're only reviewing the deployment to the staging environment itself.</p>
|
|
|
|
<h2 id="here%27s-the-thing">Here's the thing</h2>
|
|
|
|
<p>The best situation I've experienced is where a sanitised snapshot was synced to all pre-production environments every night.</p>
|
|
|
|
<p>I knew that my environment was, at most, a single day out of date, and I was confident that my changes would work in production if they did there.</p>
|
|
|
|
<p>In that situation, the staging site works and testing it has value, but if it's weeks or months out of date, it doesn't, as there are too many differences for it to be an accurate representation.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|