Deploy before Merge

When designing the pipeline that delivers your changes through sandbox environments up to production, it's good practice to expect that people using it will sometimes fail.

Failure is normal - we're all human - we just need a process that's prepared for it. That's why we often use what's called "Deploy before Merge."

It's a CI/CD technique when working with Pull/Merge Requests: before you click the "Merge" button, you run a pipeline that deploys the code (and maybe runs unit tests) and only if that deployment succeeds will it automatically merge the code.

Why it is worth it

When deploying before merging the code, you keep your branch in good shape - maybe even deployable all the time.

If something goes wrong and even peer code review didn't catch it, validation passed, but deployment fails - you don't have to panic, do git reverts, or make fast changes just to unblock everyone else.

This may not be so harmful in small projects, but when working with several teams of dozens of developers and you just merged something that's blocking everyone else, the goosebumps and heat feeling just maybe isn't worth it. Adrenaline is fine, but maybe look for some other source than playing with git.

"But why should I care when validation will catch everything?"

Well, not really. Validation catches most stuff, but there are changes validation can't predict - for example: background jobs that appeared; manual changes in the background when the package was on quick deploy; Apex tests using real org data; post-destructive changes; and Master-Detail to/from Lookup field type changes.

And so on - every day we discover new "just Salesforce things."

So prepare your processes for failure and keep up the good work!