3 ms·

> merge first, for the sake of high velocity I think what constitutes high velocity or best practice is going to be highly dependent on the context. What's th

> merge first, for the sake of high velocity I think what constitutes high velocity or best practice is going to be highly dependent on the context. What's the risk and consequences of a mistake, for example? If you are making some Crud SaaS and you are in an early/startup setting then obviously you can probably correct a mistake pretty quickly. Perhaps you haven't even shipped the product publicly. Worst case a service is unavailable or some data is deleted that can be recovered from backup. Bad day at work but you'll recover. But what if you are in a security critical business? What if your code is deployed to customers and it writes files using a file format that must be possible to read forever, and this code contains a bug making those files incorrect? So: your review process, source control workflow, testing method, CI method, etc. will depend on the context, just like the best architecture. (insert Simpson meme with "-Say the line senior developer -it depends"). Anyone who tries to offer "best practices" without caveats is either misinformed or selling snake oil (LinkedIn is the place to go if you want both of those).

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.

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.