<p>It depends on your specific requirements and constraints, but having a single pipeline that handles multiple environments can simplify the overall CI/CD process and make it easier to track changes and deployments across different environments.</p>
<p>If you want to use a single pipeline, you can add a stage for UAT that is triggered only when a pull request is made to the UAT branch, and requires manual approval before proceeding to the next stage. To set this up, you can use the following steps:</p>
<ol>
<li><p>Create a separate stage for UAT in your pipeline and configure it to run only when a pull request is made to the UAT branch.</p>
</li>
<li><p>Add a manual approval step in the UAT stage, so that someone must approve the deployment to UAT before it proceeds.</p>
</li>
<li><p>Use a feature such as approval rules in your version control system, such as GitHub, to ensure that only approved changes can be merged into the UAT branch.</p>
</li>
<li><p>Add a stage to your pipeline that handles the production deployment, and ensure that it only runs after the UAT stage has been approved and completed.</p>
</li>
</ol>
<p>This approach can provide a more controlled and auditable deployment process, as well as give you the ability to test changes in the UAT environment before deploying to production. However, if your requirements are different, you may need to use a different approach that better suits your needs.</p>

CC BY-SA 4.0
2023-02-12T11:44:05.777Z
2023-02-12T11:44:05.777Z
Ozzy
<p>maybe you can go in to a bit more details on the branching strategy you follow for example git flow as that will impact how you setup your CI/CD Pipelines.</p>
<p>For us we have one Pipeline for CD that will build the Development Branch (Git Flow) to deploy to our UAT Environment but automatically skip the Prod environment stage if the branch is called Develop* or Feature*</p>
<p>If the Branch starts with Release/* it will go throe the build stage, the UAT Deployment stage, The Automated Testing stage (Against UAT) and then the Production Stage, see below graphic to illustrate.</p>
<p>What I like on this approach is that you use the exact same code package (artifacts) on UAT and Prod, in your case that would be Dev, UAT and Prod.</p>
<p><a href="https://i.sstatic.net/frEwn.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/frEwn.png" alt="enter image description here" /></a></p>
<p>In our case the CI Pipeline is a separate Pipeline and uses the same yaml templates for the build but only deploys to the Automated Test environment and is triggered by a Pull Request Policy</p>

CC BY-SA 4.0
2022-09-13T10:57:14.723Z
2022-09-13T10:57:14.723Z
qBasicBoy
<p>I have a dev, uat, and prod environment for my ado project, and I just completed a pipeline deploy to dev.</p>
<p>Is it better practice to have a second pipeline that triggers on the uat branch, or is another stage in the same pipeline a better approach?</p>
<p>I'm leaning towards having a single pipeline, but am unsure how to set up a PR with a manual approval for uat.</p>
<p>Is this even an approach I should be investigating?</p>

<azure-pipelines><yaml>
Trigger different environments in one pipeline
ChrisW
# Trigger different environments in one pipeline

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

I have a dev, uat, and prod environment for my ado project, and I just completed a pipeline deploy to dev.

Is it better practice to have a second pipeline that triggers on the uat branch, or is another stage in the same pipeline a better approach?

I'm leaning towards having a single pipeline, but am unsure how to set up a PR with a manual approval for uat.

Is this even an approach I should be investigating?

**Tags:** azure-pipelines, yaml


---

## 2 answers

### Answer by username_1 on 2023-02-12. Score: 0

It depends on your specific requirements and constraints, but having a single pipeline that handles multiple environments can simplify the overall CI/CD process and make it easier to track changes and deployments across different environments.

If you want to use a single pipeline, you can add a stage for UAT that is triggered only when a pull request is made to the UAT branch, and requires manual approval before proceeding to the next stage. To set this up, you can use the following steps:

1. Create a separate stage for UAT in your pipeline and configure it to run only when a pull request is made to the UAT branch.
2. Add a manual approval step in the UAT stage, so that someone must approve the deployment to UAT before it proceeds.
3. Use a feature such as approval rules in your version control system, such as GitHub, to ensure that only approved changes can be merged into the UAT branch.
4. Add a stage to your pipeline that handles the production deployment, and ensure that it only runs after the UAT stage has been approved and completed.

This approach can provide a more controlled and auditable deployment process, as well as give you the ability to test changes in the UAT environment before deploying to production. However, if your requirements are different, you may need to use a different approach that better suits your needs.


---

### Answer by username_2 on 2022-09-13. Score: 0

maybe you can go in to a bit more details on the branching strategy you follow for example git flow as that will impact how you setup your CI/CD Pipelines.

For us we have one Pipeline for CD that will build the Development Branch (Git Flow) to deploy to our UAT Environment but automatically skip the Prod environment stage if the branch is called Develop\* or Feature\*

If the Branch starts with Release/\* it will go throe the build stage, the UAT Deployment stage, The Automated Testing stage (Against UAT) and then the Production Stage, see below graphic to illustrate.

What I like on this approach is that you use the exact same code package (artifacts) on UAT and Prod, in your case that would be Dev, UAT and Prod.

[![enter image description here](https://i.sstatic.net/frEwn.png)](https://i.sstatic.net/frEwn.png)

In our case the CI Pipeline is a separate Pipeline and uses the same yaml templates for the build but only deploys to the Automated Test environment and is triggered by a Pull Request Policy


---

