uuid:
  - value: 0316dfcf-b709-47e1-9622-9355b5ece6d9
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:00+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: 'You can deploy on Fridays'
created:
  - value: '2025-03-11T00:00:00+00:00'
changed:
  - value: '2025-05-11T09:00:00+00:00'
promote:
  - value: false
sticky:
  - value: false
default_langcode:
  - value: true
revision_translation_affected:
  - value: true
path:
  - alias: /daily/2025/03/11/friday
    langcode: en
body:
  - value: |
      <p>Does your team have a "No deploy Friday" policy?</p>

      <p>What about not deploying after a certain time in the afternoon?</p>

      <p>These approaches are attempts to minimise risk when deploying.</p>

      <p>If there is an issue, will someone be available during the evening or weekend to resolve it?</p>

      <p>To me, this indicates the deployment process is too complicated, possibly due to a lack of automation, or deployments aren't happening frequently enough.</p>

      <p>Having a <a href="/daily/2025/01/30/gatekeeper">robust and passing CI pipeline</a> that runs automated checks and tests is crucial to know the code is deployable.</p>

      <p><a href="/daily/2023/09/28/feature-flags-enable-continuous-integration">Feature flags are a great way</a> to separate deploying code from releasing changes to users, which means you don't need to avoid pushing some code until the change is complete. It can be done incrementally and released over several deployments.</p>

      <p>Too much time between deployments is a smell.</p>

      <p>The more time there is between a deployment and the larger the changeset, the riskier the deployment will be.</p>

      <p>There is more to go wrong and it'll be harder to diagnose and resolve any issues.</p>

      <p>I always advocate for many smaller releases than larger less frequent ones.</p>

      <p>Ideally, a production release every day - even if the changes are small or everything is hidden behind feature flags.</p>

      <p>Deploying on Friday is easy if you last deployed on Thursday.</p>

              
    format: full_html
    processed: |
      <p>Does your team have a "No deploy Friday" policy?</p>

      <p>What about not deploying after a certain time in the afternoon?</p>

      <p>These approaches are attempts to minimise risk when deploying.</p>

      <p>If there is an issue, will someone be available during the evening or weekend to resolve it?</p>

      <p>To me, this indicates the deployment process is too complicated, possibly due to a lack of automation, or deployments aren't happening frequently enough.</p>

      <p>Having a <a href="http://default/daily/2025/01/30/gatekeeper">robust and passing CI pipeline</a> that runs automated checks and tests is crucial to know the code is deployable.</p>

      <p><a href="http://default/daily/2023/09/28/feature-flags-enable-continuous-integration">Feature flags are a great way</a> to separate deploying code from releasing changes to users, which means you don't need to avoid pushing some code until the change is complete. It can be done incrementally and released over several deployments.</p>

      <p>Too much time between deployments is a smell.</p>

      <p>The more time there is between a deployment and the larger the changeset, the riskier the deployment will be.</p>

      <p>There is more to go wrong and it'll be harder to diagnose and resolve any issues.</p>

      <p>I always advocate for many smaller releases than larger less frequent ones.</p>

      <p>Ideally, a production release every day - even if the changes are small or everything is hidden behind feature flags.</p>

      <p>Deploying on Friday is easy if you last deployed on Thursday.</p>

              
    summary: null
field_daily_email_cta: {  }