0

Currently we use a dev-Branch in TFVC where every developer checks in. We have a Gated Checkin which ensures that our project builds.

Now we would like to switch to git, but TFS 2017 and Azure DevOps 2019 don´t have something similar to a Gated Checkin for git repositories. We could change our workflow to use feature branches and pull requests. But pull requests only test the code when merging to master (or another branch).

This would be okay if every feature is developed by a single developer. But in most of our features there work more than one developer on a feature. How could we prevent a developer from pushing code to a branch that breaks the build and blocks the other developers on the same branch?

Martin
  • 1,283
  • 2
  • 14
  • 28
  • I´m looking for a solution where not every developer needs his own branch. Maybe something like a pre-receive-hook, but build-in in TFS / Azure DevOps. I will wait a week or two if someone has any solution for this. If not, I will accept your answer. I think this is the way to work within git and we have to rethink our workflow. – Martin Jun 08 '20 at 07:29
  • How about the issue? Have you got any better solution this issue? After you reply, I have also tried more, but it seems that I have not found a better answer. I look forward to your reply. – Leo Liu Jun 16 '20 at 09:41
  • No, I couldn´t find any better solution. – Martin Jun 17 '20 at 13:24

2 Answers2

2

How could we prevent a developer from pushing code to a branch that breaks the build and blocks the other developers on the same branch?

We could use the Branch policies to protect the protect the feature branch.

enter image description here

To prevent a developer from pushing code to a branch that breaks the build and blocks the other developers on the same branch, like Feature branch.

We could add the Build validation on the Feature branch to set a policy requiring changes in a pull request to build successfully with the protected branch before the pull request can be completed.

In this case, this Build validation will prevent a developer from pushing code to the feature branch that breaks the build and blocks the other developers on the feature branch.

When we have one more developers on this Feature branch, each developer should create their own branch based on the Feature branch, like Feature_DevelopA, whenever a developer merges to Feature branch, they need to pass the Build validation to complete the merge.

Besides, we could also add other Branch policies, like code reviewers.

Hope this helps.

Leo Liu
  • 71,098
  • 10
  • 114
  • 135
  • 1
    Hi Leo, Build validation is fine but consider this scenario PullRequest1 is created and a build is triggered as part of Build validation. This build is green (Compile + test cases etc.). PullRequest2 is also in progress, which has some changes which may fail the first pull request changes. PullRequest2 build validation build is green and it is Approved and Completed and merged into master. Now, pull request 1 is Approved (as it got a green build earlier) and completed and merged into master. Once pull request1 changes are merged to master, master is now a broken branch. How to avoid this? – ViBi Dec 14 '20 at 05:01
0

You can apply branch policies to your feature branches, just like you do with master.

enter image description here

https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops

Calidus
  • 1,374
  • 2
  • 14
  • 31
  • Thank you, but with branch policies on a feature branch also every developer has to work in his own branch :-( – Martin Jun 09 '20 at 06:04
  • Any reason why you can't make your developer branches short lived? Creating a new branch for each PBI or Task and then submitting a PR back to the feature branch is a standard workflow. Branching is much easier in Git than TFVC. You may want to look at some common git workflows. https://learn.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/use-git-microsoft – Calidus Jun 09 '20 at 13:29