Upgrading Your Merge Requests

Ken Van Hoeylandt
ING Blog
Published in
4 min readFeb 27, 2020

Let’s automate merge request creation to better guard our process, while keeping friction at a minimum.


Merge requests are a part of our daily lives as developers: We spend a lot of time with them and create many every year. Even though they’re a very useful tool, they can be perceived as a kind of friction. This write-up is about the automatic generation of these merge requests, to improve the quality safe-guards of our project while trying to keep that friction as small as possible.

Checks and balances

Our development cycle has a lot of checks and balances in place: Some of these relate to the development process, while some others relate to the release process.

Considering that many developers contribute to our projects, it’s important that this process is clear and easy to follow.


Beyond technical measures to improve quality (like running automated tests), we also have expectations that are harder to automate in our existing tooling: this includes product owner approvals, security assessments, or even a reminder to follow the boyscout rule.

We used to do this with GitLab’s merge request templates. This would change the merge request description based on a template file written in Markdown and could look like this:

However, this approach wasn’t entirely without its problems:

  • People were able to ignore some of these requirements. Nothing prevented them from merging their changes without even taking a look at these checklists.
  • Adding information to such a checklist (e.g. linking to the scrum/kanban story) was tedious, as it would require the developer to edit the merge request for each checklist entry.
  • Managing all these templates is tedious: due to the many dozens of projects (applications and libraries) that we develop, it was hard to keep all these merge request templates up-to-date.

We can do better

To improve this experience, our team built a tool that generates discussions in GitLab as soon as code is pushed. Based on the branch name (e.g “feature/*”, “release/*”), a profile is…

Ken Van Hoeylandt
ING Blog
Writer for

Software Developer / Byte Welder