Fellow Daily Commit reader Axel recently wrote to me (shared with permission, and edited slightly for context):

In your Lean CD course, you talk about doing manual QA before merging. But wouldn’t moving QA before the merge expose you to integration risks? Let’s say there are two conflicting changes on separate branches. We would discover the problem only after the merge to master, right? Am I missing something here?

Here’s my full response:

Hi Axel,

Thank you for your question! It’s a good one.

At a high level, the goal should be to find a way to validate that the merge is safe, and there are no conflicts, before merging to master. There are different ways to accomplish this, and the best approach depends on your particulars.

Probably the simplest way to prevent conflicting merges is simply to require that all merges are fast-forwardable. Both GitHub and GitLab offer this option in the repo/merge request options. This disables the ‘Merge’ button when the feature branch is not up to date, forcing a rebase or merge (and thus a re-run of the automated CI tests) before merging. In my experience, this approach works very well on a small repo, with less than maybe 10 developers active.

For larger repos, GitLab offers Merge Trains, which can help order your merges, without forcing a rebase yourself, to prevent conflicts. I imagine GitHub, or some CI add-on tools, can do the same, but I haven’t investigated.

Another option could be to have some staging branch that is merged into, then automatically promoted to master after CI runs. This allows any conflicting merges to be caught in this stage, before merging to master. It would require manual intervention in such a case (probably reverting some PR). This would be sort of a manual implementation of GitLab’s Merge Trains feature. The key here is that it ought to be 100% automated, so that when there is no conflict there’s no further human interaction between hitting “merge” and the code being deployed into production.

Does this help?

Jonathan