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

docs(daily-email): add 2022-11-30

Browse source
This commit is contained in:
Oliver Davies 2022-12-01 01:09:26 +00:00
parent b3c9b6a0b8
commit d13416e78a
1 changed files with 43 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

43
website/src/daily-emails/2022-11-30.md Normal file
View file

@ -0,0 +1,43 @@
---
title: >
Ship, Show or Ask
pubDate: 2022-11-30
permalink: >
archive/2022/11/30/ship-show-or-ask
tags:
- git
---
"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.
Each change is either a "Ship", "Show", or "Ask".
## Ship
"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.
## Show
"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.
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.
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.
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.
## Ask
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.
This is also common when new Developers join a project or need to change some code they haven't worked on before.
## Conclusion
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.
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.
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.
The full article with more information is at https://martinfowler.com/articles/ship-show-ask.html.