3 ms·
The OP doesn't state not to review code anymore. I think the most common process is something like: feature branch -> review -> merge intro trunk -> release to
by Lutger 3y ago
The OP doesn't state not to review code anymore. I think the most common process is something like:
feature branch -> review -> merge intro trunk -> release to prod
This is simplified, somewhere in between those stages is often automated test, release to staging server, feature toggles, etc. But lets omit those from consideration. Now the proposed way of working would be:
feature branch -> merge intro trunk -> review -> release to prod
You still have the same checks, you just change the order. Trunk could be broken more often, bringing velocity down. You'd have to organize review in a different way, which might be complicated. But the same checks would be there.
- alkonaut 3y ago> The OP doesn't state not to review code anymore. Nor am I suggesting he does. I'm saying that merging incorrect code to master might increase velocity if two conditions are fulfilled 1) that people are helped by building on top of the code merged to master and 2) that an incorrect master does NOT create issues that slows down the velocity more than 1) helps. And that second bit is the case, for example, if the master branch is used to create data (document files, for example) that would be useless or require manual salvaging, if the master branch is broken.