Merge Conflicts illness? Hire a botctor to diagnose them!
Do you suffer from the occasional illness of "Ouch! The changes I did few days ago were rejected because of merge conflicts?" On a scale of 0 to 10, how annoyed are you when you have to go back to that code and fix these silly conflicts? If your answer is, let's say, 7 or greater, continue reading, and maybe you will discover an interesting proposal to take care of them at the early stages.
A DevOps medication
If you are a DevOps-aware team, you are probably familiar with concepts like Continuous Integration (CI) and Trunk-based-development, and the benefits they provide to your value stream.
You may also know how important it is to keep flow moving fast and to have instant feedback for your rejected code changes in the pipeline for any reason, so the cause of the problem is addressed sooner, before it becomes a tedious task.
But implementing processes to fit these needs could be a major step. I'd like to show you how Plastic SCM leverages its DevOps feature to easily create an actual ecosystem of automation bots to achieve all of these goals.
The CI & Trunk Based Development part of the equation
Recently we added embedded DevOps capabilities to Plastic SCM, so you can easily automate your code integration process using a so-called "mergebot".
So far, Plastic SCM comes with a built-in mergebot that follows trunk-based-development principles to drive the merges from your (short-lived) task branches into your trunk branch (/main branch in Plastic jargon).
But, to manage which branches are ready to be integrated, and to ensure your trunk branch is always kept in a releasable status, mergebots are supported by a collection of "plugs" or connectors to external systems, such as Issue Trackers (Jira), or CI systems (Bamboo, TeamCity, Jenkins).
With IssueTracker plugs, mergebots bind Plastic branches to actual issue tracker tasks, and therefore, they can query the status of your task branch to decide whether a task branch is ready to be merged or not.
With CI plugs, mergebots are able to build and test the merged (but not committed yet) code of your task branch with the trunk branch. Basically, you set which steps define your build and test process in your CI system, and the mergebot will deliver the merged code to be built.
If the build and test plan execution is successful, the merged code is checked-in into the trunk branch, because it was proven the merged code didn't break the releasable condition of your trunk branch. Then, the next task branch is processed the same way.
The Instant feedback part of the equation
So far, everything looks good. But, what happens if the mergebot cannot automatically merge the task branch code with the trunk branch?
Since Plastic SCM server is now empowered with semantic merge capabilities, the chances of requiring manual user-intervention on merge operations are drastically reduced. But, sometimes it happens; a merge operation cannot be automatically completed because manual conflicts appear, and the task branch is rejected.
The question you may have is: Do I have to wait until the mergebot starts processing my task branch before I receive a notification telling me that my branch cannot be merged? The answer is NO.
Give trunk-bot a partner bot to detect conflicts earlier!
Depending on how long the workflow is in your issue tracker, it is likely to take several hours (or even days) since you set your task status as implemented until it reaches the ready to merge status (e.g. the code of your task branch has to be previously set as code-reviewed-OK, and then, it should be set as "tested by QA" before setting the task to ready to merge).
But, once your task reaches the ready to merge status, it could take some extra time until the mergebot finishes with previously queued task branches and starts processing your task branch. This time depends on how long your build and test process is in your CI system.
In the end, it could take a while since you set the task status as implemented until you notice if your code has conflicts with trunk branch. And how annoying/frustrating/awful is to have to jump back to a previously implemented task to resolve these conflicts requiring your manual intervention? You name it.
But hey, you can tell me: "Why don't you run a dry-merge operation of your task branch with the trunk branch when you mark the task as implemented to check whether there are manual conflicts or not?"
OK, I can do that. But, the conflicts check result will be valid just for a given repository snapshot. What I mean is: what happens when the mergebot integrates and checks-in other task branches into trunk branch? I would have to run a dry-merge of my task branch with trunk branch again every time a new changeset is checked-in into trunk branch to ensure my task branch has no manual conflicts!
The proposed solution? Automate all these dry-merge operations described above in a new mergebot: "ConflictsBot".
You can find this new mergebot source code at github. You can compile it and set it up as a custom mergebot to track a given repo's branches.
ConflictsBot: How it works
This ConflictsBot works as follows:
- It tracks every branch in a given repository matching a certain branch prefix.
- If a previously defined "branch status" attribute is set to an implemented value, and the associated task in the issue tracker's (if any) status field is also set to a given implemented value, then the ConflictsBot will run a dry-merge of the task branch with the configured trunk branch.
- If the merge has manual conflicts that require user-intervention, the branch status is set to a failed value. The status field in the configured issue tracker (if any) is also set to a failed value.
- Otherwise, the task branch is promoted to a no conflicts so far queue.
- When new changesets are created in configured trunk branch, the branches in the no conflicts so far are re-processed again to check if they have manual conflicts at this new repository snapshot.
- A task branch leaves the no conflicts so far queue when the branch status attribute is set to a previously configured merged value. Note that this branch status transition is usually triggered by another mergebot, such as the described built-in trunk-bot.
- A notifier plug (Slack, email,...) can be configured to notify you whether a task branch processed by ConflictsBot has manual conflicts or not.
Show me the ropes!
A full configuration example combining TrunkBot and ConflictsBot is described here.
Next steps
The roadmap for ConflictsBot has just begun, and there are several improvements we have in mind:
- Integrate ConflictsBot functionality in TrunkBot, so you can benefit from the best of two bots out-of-the-box in a single, built-in mergebot.
- Provide a more detailed report about detected conflicts: Not only those that require manual user intervention, but, also those awesomely resolved by server-side semanticmerge.
- Ideas and requests are welcomed!
0 comentarios: