uuid:
  - value: fcd0906c-5337-4f6e-8938-c71c2fe672d8
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:32+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: |
      Non-blocking code reviews
created:
  - value: '2023-09-01T00:00:00+00:00'
changed:
  - value: '2025-05-11T09:00:32+00:00'
promote:
  - value: false
sticky:
  - value: false
default_langcode:
  - value: true
revision_translation_affected:
  - value: true
path:
  - alias: /daily/2023/09/01/non-blocking-code-reviews
    langcode: en
body:
  - value: |
      <p>If your team wants or needs to do code reviews, but you don't want it to slow down development, you could implement non-blocking code reviews.</p>

      <p>Instead of creating a topic branch for a feature or fix, creating a pull or merge request and waiting for it to be reviewed before merging, the commit is merged, and the code is reviewed afterwards.</p>

      <p>The ticket workflow could look like this:</p>

      <p>To Do -> Doing -> Merged -> Reviewed -> Tested -> Deployed</p>

      <p>Or:</p>

      <p>To Do -> Doing -> Merged -> Deployed -> Tested -> Reviewed</p>

      <p>The focus is getting the update to production, and the review is deferred.</p>

      <p>The same CI pipeline rules apply - it must be passing before the code can be deployed, so the same quality checks are run.</p>

      <p>With this approach, the code is still reviewed, either in the pull or merge request or by the commits on the mainline branch if doing trunk-based development. It's just done later.</p>

              
    format: full_html
    processed: |
      <p>If your team wants or needs to do code reviews, but you don't want it to slow down development, you could implement non-blocking code reviews.</p>

      <p>Instead of creating a topic branch for a feature or fix, creating a pull or merge request and waiting for it to be reviewed before merging, the commit is merged, and the code is reviewed afterwards.</p>

      <p>The ticket workflow could look like this:</p>

      <p>To Do -&gt; Doing -&gt; Merged -&gt; Reviewed -&gt; Tested -&gt; Deployed</p>

      <p>Or:</p>

      <p>To Do -&gt; Doing -&gt; Merged -&gt; Deployed -&gt; Tested -&gt; Reviewed</p>

      <p>The focus is getting the update to production, and the review is deferred.</p>

      <p>The same CI pipeline rules apply - it must be passing before the code can be deployed, so the same quality checks are run.</p>

      <p>With this approach, the code is still reviewed, either in the pull or merge request or by the commits on the mainline branch if doing trunk-based development. It's just done later.</p>

              
    summary: null
field_daily_email_cta: {  }