Post

Cory House
@housecor.com

Controversial opinion: 🌶️ I prefer for all quality checks to occur *before* merge. Here's why. Merging code that hasn't been fully quality checked leads to batching work. It means we need to maintain a long-lived environment (like QA, UAT, or Staging) to integration test all our changes... 1/3

2 reposts18 likes

Cory House
@housecor.com

It means need more release overhead - we need to agree on a release cadence, release cutoff dates, etc. This encourages devs to rush to hit release cutoff dates too. And it leads to devs getting pulled back into work days later if their code doesn't pass inspection in some other environment. 👎

Cory House
@housecor.com

In contrast, if all quality checks occur *before* merge, we can automatically deploy the code when it's merged. So all the release overhead above melts away. No more batching, coordination overhead, release planning, etc. Code deploys to prod when we merge, because we know it's good enough. 🔥

Jaap Weijland
@weijland.it

A rule of thumb i maintain is that master should always be deployable. If you’re only testing after merging to master, it means the code is potentially breaking something and thus that master might get in a broken state - even if you would revert it afterwards.

metru
@metru.dev

100%. Don't even have to read. All quality checks should happen before merge. All code should have a consistent format, code-style, patterns, acceptable test coverage. Reading code where every file follows slightly different opinions is not great.

Mads
@madsva.bsky.social

Depends on what you mean with "merge". If merging to the dev/release branch from a feature branch: Absolutely, no questions about it. The only people I know that finds this annoying/controversial is people that are not used to it.