CODEWITHSUNDEEP
gitcontinuous-integrationazure-devops
GaTechThomas
GaTechThomas

Reputation: 6076

VSTS/TFS Git Branching Strategy and Continuous Integration

Our company had been using a git branching strategy that kept a long-running sprint work branch around that looked something like this:

master
  \
   Sprint
     \
      Feature1
      Feature2

With the current sprint, we switched to having a new branch with a new name for each sprint:

master
  \
   Sprint123
     \
      Feature1
      Feature2

With this change some pain points arise:

  1. Policy has to be set up each time a new Sprint### branch is created (which includes continuous integration and pull request settings).
  2. Build definitions have triggers which still work fine via wildcard ("Sprint*"), but the repository source setting for the build doesn't support wildcards.

I've been through the VSTS documentation, but I feel like I've missed something on how to set this up to have a new branch per sprint (which is in line with VSTS branching strategy documentation).

So, the questions are:

Our expectation was that the branch that triggers the build is the one that is built. Is this possible?

What is the recommendation for setting branch policy each time a new branch is created off of master? Should we just expect that we will have to configure all of the settings manually every time?

Upvotes: 0

Views: 2233

Answers (2)

Matt Cooper
Matt Cooper

Reputation: 937

We've published guidance on Git branch strategy. The sibling answer which points at TFVC is incorrect.

We don't recommend long-running development branches for most teams. Instead, keep a clean master and use short-lived topic branches. Then, you won't need to keep creating and deleting policies, build definitions, etc.

If you must keep using long-lived branches for some reason, consider using slashes in the names of branches, e.g. sprints/s100. We have a REST API already (and soon, admin UI) to set policies on a prefix-matching basis, stopping at /s. So, you could set up branch policy on sprints/ and it would get automatically applied to sprints/s100, sprints/s101, etc.

Upvotes: 3

Marina Liu
Marina Liu

Reputation: 38106

The recommended branching strategy is always use the same branch even for new sprints. As this article, you can always use development branch for different sprints.

Of cause, you can use your branching strategy if the codes are quite different between two sprints. But the disadvantages as:

  1. Set branch policy each time when you create new branch.
  2. As time goes on, there will has amount of branches sprint*, it’s not good to trace the whole project versions easily.

Finally, for your questions (if you still need your current strategy):

  1. Yes, you can still use the format Sprint* in build definition Triggers Tab, then your new created branches Sprint### will also suitable for CI build. And get sources step for build definition won’t affect your CI build, the repo and branch select only for manually queue build.
  2. You need to set branch policy manually for the new created branches every time.

Upvotes: 1

Related Questions