Upgrading Your Merge Requests
Let’s automate merge request creation to better guard our process, while keeping friction at a minimum.
Introduction
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.
Quality
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 selected, which leads to automated discussions in a merge request:
These are some of the discussions from our release process:
All discussions are based on a profile that is defined in YAML:
Defining new profiles is easy. Other teams working on different products can easily use the tool to apply their own requirements. Our teams currently use it for Android and iOS development. For Android, we have different profiles for library development, plugin development and application development.
Result
The end result is that development requirements and guidelines are easier to follow: The discussions now block the merge request. It’s not possible to accidentally forget the checklists anymore, as developers need to actively resolve the discussions before they can merge.
Even though they are blocking, they now cause less friction: each discussion can now be completed in-line, as developers don’t need to repeatedly edit the merge request itself anymore.
Lastly, it’s easier to scale up our way of working, as it is now driven by a small configuration. The software and the configuration are deployed in a repository (both Maven and Docker) so it’s easy to roll out updates to all our projects at once.
While working on the mobile banking applications at ING, we strive to continuously improve our way of working, so merge requests and the processes surrounding them are no exception.
The Future
In the future, we might want to not have the merge request created by default, but move to a similar setup where at least the content (discussions) is generated automatically. We might end up creating a build trigger, that
spins up a build that starts these discussions.
That way, we’ll give the developer a bit more freedom to manage his merge request, while still keeping the assurance that certain discussions are started.
