<p>No, Azure DevOps does not support merge trains. I think in your case, you can create a new branch (like a release branch) from the target one. Then merge your PRs one by one into it. If all goes well then create one PR from the release branch to the target branch.</p>

CC BY-SA 4.0
2022-03-07T13:00:31.703Z
It'll be hard to automate this, it should not just be done once, but continuously when there are new PRs coming in.
spydon
CC BY-SA 4.0
2022-04-26T08:25:42.617Z
@spydon maybe not *easy* but not super hard either
Prof. Falken
CC BY-SA 4.0
2022-04-26T11:25:28.057Z
@Prof.Falken how would you automate this?
spydon
CC BY-SA 4.0
2022-04-26T12:04:28.187Z
Create a new branch X1. Merge request *A* against it X1. Create branch X2. Merge requests *A* and *B* against X2. Create a new branch X3. Merge requests *A*, *B* and *C* against X3. Kick off pipe-line builds for branches X1, X2 and X3. Monitor their build status. Note if any build failed. If pipeline build for X3 failed but build for  X2 passed, you can safely merge X2 into main. @spydon
Prof. Falken
CC BY-SA 4.0
2022-04-26T12:45:12.147Z
And where would this code live for such an automation, in the normal build pipeline? Seems quite hacky
spydon
CC BY-SA 4.0
2022-04-26T12:50:57.810Z
The user shouldn't have to care which branch that their PR is targeting, just like with the merge trains. So I would also have to build something that changes the target in the first step of the pipeline.
spydon
CC BY-SA 4.0
2022-03-07T02:49:23.533Z
2022-03-07T02:49:23.533Z
Shamrai Aleksander
<p>Is it possible to somehow implement a merge trains in Azure DevOps, similar to what <a href="https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html" rel="nofollow noreferrer">GitLab does</a>?</p>
<blockquote>
<p>Merge train example</p>
<p>Three merge requests (A, B and C) are added to a merge train in order,
which creates three merged results pipelines that run in parallel:</p>
<pre><code>The first pipeline runs on the changes from A combined with the target branch.
The second pipeline runs on the changes from A and B combined with the target branch.
The third pipeline runs on the changes from A, B, and C combined with the target branch.
</code></pre>
</blockquote>

<azure-devops><azure><azure-pipelines>
Merge trains in Azure DevOps
spydon
# Merge trains in Azure DevOps

(Asked by: username_0 on 2022-03-01)

Is it possible to somehow implement a merge trains in Azure DevOps, similar to what GitLab does?

Merge train example
Three merge requests (A, B and C) are added to a merge train in order,
which creates three merged results pipelines that run in parallel:
The first pipeline runs on the changes from A combined with the target branch.
The second pipeline runs on the changes from A and B combined with the target branch.
The third pipeline runs on the changes from A, B, and C combined with the target branch.

**Tags:** azure-devops, azure, azure-pipelines


---

## 1 answers

### Answer by username_1 on 2022-03-07. Score: 2

No, Azure DevOps does not support merge trains. I think in your case, you can create a new branch (like a release branch) from the target one. Then merge your PRs one by one into it. If all goes well then create one PR from the release branch to the target branch.

> **Comments:**
> **username_0**: It'll be hard to automate this, it should not just be done once, but continuously when there are new PRs coming in.  
> **username_2**: @username_0 maybe not *easy* but not super hard either  
> **username_0**: @Prof.Falken how would you automate this?  
> **username_2**: Create a new branch X1. Merge request *A* against it X1. Create branch X2. Merge requests *A* and *B* against X2. Create a new branch X3. Merge requests *A*, *B* and *C* against X3. Kick off pipe-line builds for branches X1, X2 and X3. Monitor their build status. Note if any build failed. If pipeline build for X3 failed but build for  X2 passed, you can safely merge X2 into main. @username_0  
> **username_0**: And where would this code live for such an automation, in the normal build pipeline? Seems quite hacky  
> **username_0**: The user shouldn't have to care which branch that their PR is targeting, just like with the merge trains. So I would also have to build something that changes the target in the first step of the pipeline.  

---

