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

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. 👎

0 reposts1 like

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.