Skip to content

Identify improvements to Merge Trains

What’s this issue all about?

Today, We are still at an MVC for the Merge Trains functionality. We built one-at-a-time execution https://gitlab.com/gitlab-org/gitlab-ee/issues/9186, and now we are working on parallel execution of merge trains https://gitlab.com/gitlab-org/gitlab-ee/issues/11222. We need to understand if this experience is meeting our users' needs and what can be improved upon.

What questions are you trying to answer?

  • How might we approach the design of the Merge Trains with the users' goals in mind?
  • Who are the users? (Developers, or administrators who manage stream of release orchestration and CI-cost balances) Need validation
  • What are their goals with regard to merge trains? Unknown
  • How do they use this feature today? Unknown
  • How can we improve the experience today? Receive from this study

What assumptions do you have?

  1. The experience of interacting with the merge trains is unclear and leads to a poor overall experience.
  2. The current information structure, with merge trains pipelines not being differentiated on the merge request widget is not the best way to organize information.
  3. The messaging on the merge request widget makes consuming the information difficult.
  4. There isn't a clear workflow for how users should set-up and manage their merge trains.
  5. We don't provide users with enough information in the documentation to fully understand this feature.

Other assumptions

  • Users don't care to know that the Pipeline for merge train will not be created immediately
    • We are unsure which persona cares the pipeline capacity at the merge request level.
    • This could be useful information for administrators who manages stream of release orchestration and CI-cost balances. Even though developers/maintainers saw it, it doesn't affect their decision on the merges as they know their MRs will be merged sooner or later.
  • The information about the pipeline limitation is less valuable than other type of information in the UI
  • What is important to users is that their merge request will be merged eventually
  • Users don't revisit the merge request again once they set Merge Train
  • If users revisit the merge request revisit, that would be when something went wrong e.g. a merge request was supposed to have been merged but not yet.
  • https://gitlab.com/gitlab-org/gitlab-ee/issues/11222#note_187018901: The most important information (IMHO must-have) and missing today is which pipeline is the pipeline for merge train and which pipeline is the other types. While users are developing on the branch, they push commits and the other pipelines are created (These pipelines are most likely Pipelines for merged results or detached merge request pipeline). But technically, Pipelines for merge train has to be clearly distinguished from them, but current it's shown as Pipelines for merged results.
  • If we remove the merge train option from the settings page, how do users know that the merge trains strategy is the default?
  • Added to the merge train at position 6. Improve the message to indicate that there's a limit of 4, there's 2 waiting until the pipeline start.

What decisions will you make based on the research findings?

Take the findings to a product discovery issue and map out an improved experience with a new MVC to be implemented once discovery is complete.

What's the latest milestone that the research will still be useful to you?

Resources/links

Edited by James Heimbuck