Add a mergebot to your repo!
Recently I described how mergebots help implement DevOps from a conceptual point of view. Today, I'm going to explain what mergebots actually look like.
A mergebot automatically merges branches once they are correctly reviewed, validated and all tests pass. You can think of it as robotic automation for the integration process. It saves on costly context switches for developers (who no longer have to go and merge your branch, the bot does this with you) and automates most of the repetitive work of integrators and build-masters.
What is the added value?
Traditionally teams do one of these options to merge task branches:
-
Option 1) Have a dedicated build-master/integrator.
Someone in the team is responsible for merging branches and creating releases.
Once a branch is ready (code-reviewed, validated, all tests pass), the integrator takes the branch and merges.
This option has some advantages. If there is a manual conflict, the integrator, as a highly responsible team member they are, will ask the developers involved to help. The integrator is a "final validation gate" for branches in case of conflict.
The contrary situation might be a junior developer solving conflicts themselves on a Friday afternoon before leaving for the weekend… see the value? (Of course, your team could be a highly committed, highly homogenously experienced team, and then such things might never happen :P).
An extra layer of responsibility is good, but the process doesn't scale as I have explained many times.
-
Option 2) Every developer merges their own code.
Pull-request model anyone? Ok, someone goes and hits the "merge button" when the "pull request" is ready (a glorified branch, after all).
You can do this in Plastic if every developer merges to main (or whatever your integration branch is) once the branch has been code reviewed.
Even if there are no conflicts someone has to take the time to press the "merge" button.
mergebot: look ma, no hands!
A mergebot goes one step beyond this manual task. There is nobody actually pressing the merge button. A bot does it for you. It is like hiring a robotic integrator that is monitoring branches in the background and triggering builds on your Jenkins/TeamCity/Bamboo/your-own and confirming the merge only if the tests pass.
And all this combined with our (unique, yep, not bluffing, it is unique :P) merge technology that basically runs cycles around the Gits and P4s of the world. (If you doubt me about its uniqueness, read this www.plasticscm.com/mergemachine, and this about semantic capabilities).
The added value of the mergebot is reducing manual merge conflicts up to 30% thanks to our better merge, plus ensuring you never break the build, because mergebots only confirm the merge if tests pass, and not before. (For more details, see mergebot: the story of our DevOps initiative).
But, I already have Jenkins. What's the plus?
Ok, you may already have Plastic + Jenkins or Bamboo or TeamCity or any other CI system. And that's a good option. In fact, I wrote about it this year (DevOps with Bamboo and Plastic).
So, what is the plus then? What problems does the mergebot solve?
Well, how do you tell your CI system that branches have to be merged only when the associated Jira task is set as "reviewed"? And, what about passing tests of branch task + main (merged) but only confirm the merge if tests pass so you never break a build again?
Or, what about notifying by email or Slack (interruptions permitted) when the task-branch starts testing, or when it is finally successfully integrated once tests pass?
You can obviously do that yourself. But, mergebots make it easier because they give you all the glue code out of the box. That's the plus.
And, mergebots *code* your workflow. It can be "trunk-based-devel + task branches", it can be release branches, it can be many products on the same branch… our goal is to develop a collection of mergebots so teams can choose the one that best fits their needs or even extend and create their own.
mergebots and plugs
This is our Plastic SCM webadmin where you can see a new "DevOps" section.
This is actually our internal main server, where we have our own bot to do integrations, and then 4 "plugs" or connectors: one for email to notify branch merge and build status, same for Slack notifications, then our internal CI system (call hal), and our internal issue tracker system (tts).
In your case, it could be Jenkins + Jira + Slack.
What does a mergebot config looks like?
Here, I'm going to share some of the settings in our own internal (custom) mergebot. If you click on "configure" in the "halbot" line above in our server, you'll see something as follows:
You specify the repository to monitor. In our case, we just specify one, but other mergebots can specifically act on a set of repos, or all the repos in the server.
Our bot has a setting to "upgrade server on successful merge" which is currently disabled. We eat our own dog food, so every new internal release is normally immediately installed so the entire team starts testing it (besides the automated test suite the new version already passed).
Then, comes the "issue tracker integration". In our case, we use "tts" which is our own issue tracker. Jira could be a more popular choice, by the way. Then, the mergebot asks you to tell it where the "description of the task can be found", and it is "title" in our case. Then, what is the name of the "status" field, and then, what is the value of the status when a task is still "in progress" (open in our case).
The configuration continues with additional fields to setup the issue tracker integration: things such as how to know if a task is reviewed, validated, or what value to set when a branch is merged, and many more.
It is important to highlight that all these settings are particular to this mergebot. Different bots need different parameters to work.
Then, see how the CI integration looks like for our mergebot:
This is very particular to our case, and you can see how our own mergebot works. We are using monorepo for our 3 main products. This means that the three are in a single repo, which might sound counterintuitive at first. Our reality is that since they share lots of code, it is very useful to place them in a single repo.
Well, going back to the config: for Plastic itself the mergebot creates a new "public version" only when at least 4 tasks have been merged. This means that releases with just a single task are quite rare. But, you can see how for gmaster and semantic that the bot creates a new version as soon as a single branch is merged. (Later, we decide if every new potentially public version is finally released or not, but many are created so we can go ahead and publish anytime).
The Slack integration shows how everything is reported to "jesusmg", who is our build-master (although he outsourced part of his work to mergebot so now he watches Netflix most of the day :P... let's see if he reads this :-D), and the #releases channel where we all can see what is being cooked.
After that, we also have settings for emails, specific settings on how to label releases and more...
That's all folks... but more coming!
I hope this gives you a good overview of what a mergebot is and how it looks and feels and what it can do to help your team be more effective.
Of course, this is just the beginning. I still didn't describe the mergebot that actually comes included with the Plastic server but instead described our own custom one (although it will be published in case you want to mimic the way we work), and there are many other interesting settings and workflows to consider.
Stay tuned!
0 comentarios: