<p>You can set up <a href="https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#build-validation" rel="nofollow noreferrer">Branch Policies</a> on your develop branch which requires a build to pass successfully before the Pull Request can be completed.</p>

<p>I have set this up for my team with great success; we very rarely will have a broken master branch. The PR does not run the main build, but instead runs a separate, slimmed down build that checks that the code compiles and the unit tests pass. The "Gated" build runs on Pull Request creation, the "Full" build is triggered on change in master branch (PR completion).</p>

CC BY-SA 4.0
2019-05-23T14:37:11.290Z
How do you merge into master? I am looking at branching techniques for example, create a release branch from develop and cherry pick the commits into the release branch that are ready to be completed. I found [this](https://stackoverflow.com/questions/1670970/how-to-cherry-pick-multiple-commits) post on cherry picking.
Richard Hughes
CC BY-SA 4.0
2019-05-23T18:41:59.180Z
We never commit directly into master. Every change has to go through a pull request (which is what the branch policies enforce; even if someone wanted to push changes directly to master, they would not be able to). We are trying to do more trunk based development than gitflow, so we do not do any cherrypicking.
AHaleIII
CC BY-SA 4.0
2019-05-22T12:33:56.617Z
2019-05-22T12:33:56.617Z
AHaleIII
<p>My team is currently using gitflow workflow into develop branch.</p>

<p>Here is an overview for what we are doing. We are a sql server data warehouse team  using Azure repos and Azure devops to build and deploy our code to SSIS, SSAS, and 30+ databases in our environment. I typically deploy to a integration server and then to a prod server. I have an auto build for our SQL server solution that triggers on checkin to the develop branch. I run manually a build that generate the deployment scripts. All the SSAS and SSIS builds and deployments are triggered on the checkin to the branch. </p>

<p>I am looking at trying to migrate to a workflow that would be a pull request so I don't have a broken build that holds everyone eases deployments.  If someone breaks the build in the develop branch then I cannot deploy by the current method. </p>

<p>Prior to moving to the azure devops I was using a release workflow to create the deployment artifacts manually and I would deploy everything manually. This was a completely manual process and time consuming process that was very tedious. </p>

<p>I would like to figure out a path to get to using pull request. Does this mean I would do away with gitflow process? My team is currently using VSCode for creating features and this part works well. I am looking for advice for moving forward with pull request. </p>

CC BY-SA 4.0
2019-05-18T17:53:51.470Z
`so I don't have a broken build that holds everyone eases deployments` That is the idea of DevOps. If the CI/CD is broken then everybody has to help to fix it. No silos.
030
CC BY-SA 4.0
2019-05-20T14:21:02.820Z
I understand this concept however, I want to a build just prior to the merge.
Richard Hughes
<git><azure-devops><azure-pipelines>
Gitflow with pull request or pull request
Richard Hughes
# Gitflow with pull request or pull request

(Asked by: username_0 on 2019-05-09)

My team is currently using gitflow workflow into develop branch.

Here is an overview for what we are doing. We are a sql server data warehouse team using Azure repos and Azure devops to build and deploy our code to SSIS, SSAS, and 30+ databases in our environment. I typically deploy to a integration server and then to a prod server. I have an auto build for our SQL server solution that triggers on checkin to the develop branch. I run manually a build that generate the deployment scripts. All the SSAS and SSIS builds and deployments are triggered on the checkin to the branch.

I am looking at trying to migrate to a workflow that would be a pull request so I don't have a broken build that holds everyone eases deployments. If someone breaks the build in the develop branch then I cannot deploy by the current method.

Prior to moving to the azure devops I was using a release workflow to create the deployment artifacts manually and I would deploy everything manually. This was a completely manual process and time consuming process that was very tedious.

I would like to figure out a path to get to using pull request. Does this mean I would do away with gitflow process? My team is currently using VSCode for creating features and this part works well. I am looking for advice for moving forward with pull request.

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

> **Comments:**
> **username_1**: `so I don't have a broken build that holds everyone eases deployments` That is the idea of DevOps. If the CI/CD is broken then everybody has to help to fix it. No silos.  
> **username_0**: I understand this concept however, I want to a build just prior to the merge.  

---

## 1 answers

### Answer by username_2 on 2019-05-22. Score: 1

You can set up [Branch Policies](https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#build-validation) on your develop branch which requires a build to pass successfully before the Pull Request can be completed.

I have set this up for my team with great success; we very rarely will have a broken master branch. The PR does not run the main build, but instead runs a separate, slimmed down build that checks that the code compiles and the unit tests pass. The "Gated" build runs on Pull Request creation, the "Full" build is triggered on change in master branch (PR completion).

> **Comments:**
> **username_0**: How do you merge into master? I am looking at branching techniques for example, create a release branch from develop and cherry pick the commits into the release branch that are ready to be completed. I found [this](https://stackoverflow.com/questions/1670970/how-to-cherry-pick-multiple-commits) post on cherry picking.  
> **username_2**: We never commit directly into master. Every change has to go through a pull request (which is what the branch policies enforce; even if someone wanted to push changes directly to master, they would not be able to). We are trying to do more trunk based development than gitflow, so we do not do any cherrypicking.  

---

