opdavies/oliverdavies.uk
1
0
Fork 0
Code Issues 1 Pull requests Projects 1 Releases Packages Wiki Activity Actions

Move all files to tome/

Browse source
This commit is contained in:
Oliver Davies 2025-10-01 00:05:52 +01:00
parent 5675bcfc36
commit 674daab35b
2874 changed files with 0 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

113
tome/content/node.e01efd03-7851-41b8-a34d-7b7a56d77d31.yml Normal file
View file

@ -0,0 +1,113 @@
uuid:
- value: e01efd03-7851-41b8-a34d-7b7a56d77d31
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:51+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: |
Ship, Show or Ask
created:
- value: '2022-11-30T00:00:00+00:00'
changed:
- value: '2025-05-11T09:00:51+00:00'
promote:
- value: false
sticky:
- value: false
default_langcode:
- value: true
revision_translation_affected:
- value: true
path:
- alias: /daily/2022/11/30/ship-show-or-ask
langcode: en
body:
- value: |
<p>"Ship / Show / Ask" describes itself as a self-described modern branching strategy that combines the features of pull or merge requests with the ability to keep shipping changes.</p>
<p>Each change is either a "Ship", "Show", or "Ask".</p>
<h2 id="ship">Ship</h2>
<p>"Ship" changes are what I most commonly do with continuous integration and trunk-based development projects. Changes are committed directly to the main branch and shipped - assuming that the CI pipeline and any other automated checks pass. There is no blocking code review or pull request for "Ship" changes.</p>
<h2 id="show">Show</h2>
<p>"Show" changes are made on a temporary branch instead of the mainline. This branch is then used to create a pull request which is closed once the CI checks pass without any code review.</p>
<p>Once the pull request is merged, the change is deployed, but the pull request is still available as somewhere to have feedback and conversation about the change.</p>
<p>This is something that I did today after starting to write a new feature by implementing the Decorator design pattern, and wanted others to be aware of this approach and ask any questions.</p>
<p>Another reason for this approach is if someone wants to ensure that the CI checks will pass before merging to mainline. Some Developers worry about breaking the CI pipeline with a trunk-based approach and blocking others, so want to know that the pipeline will continue to work and they aren't disrupting other team members.</p>
<h2 id="ask">Ask</h2>
<p>This is how I've worked on most projects before, and still with some clients where they want to review changes before merging, or maybe I want to have a discussion and review a change beforehand.</p>
<p>This is also common when new Developers join a project or need to change some code they haven't worked on before.</p>
<h2 id="conclusion">Conclusion</h2>
<p>I like the flexibility and balance of this approach. I prefer to work on "mostly ship" projects, and most of the show and ask conversations happen during pair or mob programming sessions.</p>
<p>Some of my clients where I work with teams are "mostly ask" and work in a more Git Flow-type way and want to review any changes before they're merged and deployed.</p>
<p>But if you're working on a "mostly ask" project and want to move to "mostly ship", then aiming to move to "mostly show" is a good intermediate step and a way to reduce shipping time or develop and build confidence in the CI pipeline before moving to trunk-based development and removing the manual review step.</p>
<p>The full article with more information is at https://martinfowler.com/articles/ship-show-ask.html.</p>
format: full_html
processed: |
<p>"Ship / Show / Ask" describes itself as a self-described modern branching strategy that combines the features of pull or merge requests with the ability to keep shipping changes.</p>
<p>Each change is either a "Ship", "Show", or "Ask".</p>
<h2 id="ship">Ship</h2>
<p>"Ship" changes are what I most commonly do with continuous integration and trunk-based development projects. Changes are committed directly to the main branch and shipped - assuming that the CI pipeline and any other automated checks pass. There is no blocking code review or pull request for "Ship" changes.</p>
<h2 id="show">Show</h2>
<p>"Show" changes are made on a temporary branch instead of the mainline. This branch is then used to create a pull request which is closed once the CI checks pass without any code review.</p>
<p>Once the pull request is merged, the change is deployed, but the pull request is still available as somewhere to have feedback and conversation about the change.</p>
<p>This is something that I did today after starting to write a new feature by implementing the Decorator design pattern, and wanted others to be aware of this approach and ask any questions.</p>
<p>Another reason for this approach is if someone wants to ensure that the CI checks will pass before merging to mainline. Some Developers worry about breaking the CI pipeline with a trunk-based approach and blocking others, so want to know that the pipeline will continue to work and they aren't disrupting other team members.</p>
<h2 id="ask">Ask</h2>
<p>This is how I've worked on most projects before, and still with some clients where they want to review changes before merging, or maybe I want to have a discussion and review a change beforehand.</p>
<p>This is also common when new Developers join a project or need to change some code they haven't worked on before.</p>
<h2 id="conclusion">Conclusion</h2>
<p>I like the flexibility and balance of this approach. I prefer to work on "mostly ship" projects, and most of the show and ask conversations happen during pair or mob programming sessions.</p>
<p>Some of my clients where I work with teams are "mostly ask" and work in a more Git Flow-type way and want to review any changes before they're merged and deployed.</p>
<p>But if you're working on a "mostly ask" project and want to move to "mostly ship", then aiming to move to "mostly show" is a good intermediate step and a way to reduce shipping time or develop and build confidence in the CI pipeline before moving to trunk-based development and removing the manual review step.</p>
<p>The full article with more information is at https://martinfowler.com/articles/ship-show-ask.html.</p>
summary: null
field_daily_email_cta: { }