Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Direction - Merge Trains

Merge Trains

A core tenet of our Ops section direction, is about balancing speed with reliability, keeping your pipelines green. This ultimately supports the stability of collaboration across branches and GitLab has introduced Merge Trains as the mechanism to accomplish this. When merge trains are used, each merge request joins as the last item in that train. Each merge request is processed in order and is added to the merge result of the last successful merge request. The merge request adds its changes, and starts the pipeline immediately under the assumption that everything is going to pass. If the merge request fails, it is kicked out of the train and the next merge request continues the pipeline of the last successful merge result.

What's Next & Why

For an overview of our plans for Merge Trains, see epic Merge Trains Vision.

In the first two quarters of FY22, we are focused on reducing the bug backlog of the Merge Train feature. Our goal is to improve usability by resolving issues such as conditions that prevent a user from re-adding a merge request to Merge Train when "pipeline must succeed" is enabled gitlab#35135.

In the latter half of FY22, we plan to proceed with other Merge Trains vision items such as visualization of a merge train in a merge request and fast-forward merge support for merge trains.

Overview

Who we are focusing on?

Check out our Ops Section Direction "Who's is it for?" for an in depth look at the our target personas across Ops. For Merge Trains, our "What's Next & Why" are targeting the following personas, as ranked by priority for support:

  1. Sasha - Software Developer
  2. Devon - DevOps Engineer

Maturity Plan

This category is currently at the "Viable" maturity level, and our next maturity target is Complete (see our definitions of maturity levels). We currently have basic capabilities and want to continue and extend these in the upcoming releases.

Key deliverables to achieve this are:

Competitive Landscape

It looks like GitLab is the first to provide this functionality, although GitHub has a partial solution and we are aware that other competitors will be able to catch up. This is an important space for us to maintain a lead.

Top Customer Issue(s) and Top Customer Success/Sales Issue(s)

The most popular issue is gitlab#35628. When selecting to work with Fast Forward Merge without using merge trains, a user is offered to rebase master manually, in case master has advanced. Merge Train supporting fast forward merge would reconstruct train and re-run pipelines automatically.

Top Internal Customer Issue(s)

One very useful functionality that has been requested by our own team while dogfooding the feature, is the ability to use merge quick action to add an MR to a merge train gitlab#32336.

Delivery Team

In an effort to dogfood our own features, we are actively working on using merge trains internally on gitlab-org gitlab#195.

Top Vision Item(s)

Our top vision item is Merge Trains should support fast forward merge as this will eliminate the frequent need for manually rebasing. We have heard from many developers that a large portion of their day is dedicated to this activity, and with this functionality, Merge trains will take care of this for them.

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license