In this edition: a new pull request methodology called Ship, Show, Ask. Plus: event sourced aggregates; biometric authentication myths; .NET 6 minimal APIs; is Blazor just a walled garden?; and the Windows 11 launch date.
ARE YOU READY.... TO CODE?!!! *double bass solo* Photo by Vienna Reyes / Unsplash
Ship, Show, Ask
Pull requests are a common way by which software teams merge their changes together, and I know from experience that they work quite well. However, Rouan Wilsenach was wondering: do you miss the urgency we had when everyone merged to the same branch? Pull Requests, since they are a separate entity, can sit around forever before anyone gets to them.
To alleviate some of this concern, Rouan introduces a software branching scheme he calls Ship / Show / Ask.
The idea goes like this: whenever a developer makes a change to a codebase, they choose one of three options:
Ship: Make the change directly to the mainline. This is great for items that might be unremarkable, such as minor bugs, documentation changes, or updates that stem from feedback from other developers.
Show: Make the change on a branch, but open a Pull Request and merge to the mainline without showing anyone. You still get automated checks and tests, but you don't need to wait for a reviewer. This works well for refactoring, showing how to fix an interesting bug, or demonstrating a new pattern.
Ask: Make the change on a branch, and wait for feedback before merging. This is important for major changes, "will this work?" situations, and demonstrations about new approaches.
Rouan also introduces certain rules to make this system work, such as allowing developers to commit their own PRs. There's more information in the article; you should check it out.
In my opinion, this is a very cool process in theory, but it totally depends on the team involved. Committing minor changes without code review sounds reasonable to me, but as a lead (and therefore responsible for entire projects) I'd be hard-pressed to give up reviews in the "Show" scenario. That said, for smaller teams or more agile organizations, I can see this kind of approach working well.
This article is for paying subscribers only
Sign up now and upgrade your account to read the article and get access to the full library of articles for paying subscribers only.
