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: {  }