CODEWITHSUNDEEP
azure-devopsazure-pipelinesazure-pipelines-release-pipelinetfvc
reverence12389
reverence12389

Reputation: 467

Does Azure Pipelines support building and releasing multiple feature branches using same pipeline when TFVC is source repository?

Question

We'd like to be able to build and deploy code from our different feature branches to our various environments without having to clone and modify a build and release pipeline every time we have a feature branch. Does Azure Pipelines support building multiple branches and doing branch based conditional tasks in pipelines when TFVC source control is being used? If yes, how?

Background

Running Azure DevOps Server 2020 Update 1 on premise. Have multiple applications in our code repository, each with their own dev, main, and feature branches using TFVC as source control repository. Source Control Repository structure is as follows:

Team Project
  /Apps
    /App 1
      /dev branch
      /dev-feature-1 branch
      /dev-feature-2 branch
      / main branch
    /App 2
      /dev branch
      /dev-feature-1 branch
      /dev-feature-2 branch
      / main branch
  /Utilities
  /SomeCommonStuff

We have classic (not YAML) build pipelines that build, do gated checkins, and publish artifacts for each of our dev and main branches. We then have release pipelines that take the artifacts from those builds and deploy them to our different environments (dev, QA, production)

Research done so far on question

According to this documentation: it seems like Azure Pipelines supports building multiple branches in one build pipeline using Git as the source control repository because you can specify doing certain tasks such as only building certain solution files in certain branches using a condition that supports the Build.SourceBranch variable (as mentioned here).

However, when using TFVC as the source and trying to do a build, it doesn't set the Build.SourceBranch variable to the branch name (ie: dev, dev-feature-1, main, etc. in our case), but instead just sets it to the root of the Team Project (ie: $/Team Project in our case), so we aren't able to do conditional logic to perform certain tasks depending on the branch being built, which makes it so we can't have multiple branches built using one build definition, and may leave us with only being able to create a new build and release pipeline for each feature branch (which will be tedious).

Upvotes: 3

Views: 873

Answers (1)

jessehouwing
jessehouwing

Reputation: 114641

No, Azure Pipelines doesn't support advanced mapping for builds, nor does TFVC support YAML pipelines.

There are workarounds, but before we explore those, I must strongly urge you and your team to consider moving to Git. TFVC is clearly at the end of its lifetime. TFVC is a dead end. Git is the future.

From the official docs:

Git is the default version control provider for new projects. You should use Git for version control in your projects and begin to move your existing TFVC projects to Git. TFVC is considered feature complete. Azure DevOps will maintain compatibility with TFVC, but Git will receive all future investment.

As for the workarounds:

  • You could have a pipeline that triggers when a new branch is added and then takes the pipeline for your default branch and duplicates that. This can be accomplished using the REST API. You'd have to rewrite the mapping and triggers to match th etarget branch and if all other references to files use the $(Build.SourceDirectory) variable to find the files they need, then the whole pipeline can easily be ported from one branch to another.
  • You can use my TFVC - Do not sync sources task to prevent your build from creating a workspace and checking out the files. Then rely on a custom script to setup the correct mapping and fetching files prior to the rest of the pipeline.
  • You can use the above task with the TFVC Get task to fetch the sources without having to rely on workspace configuration at all.

To ensure you know which branch to build, you could set a variable at queue time or look at the changeset that triggered the build to fiwure out what branch it triggered on.

But whatever workaround you choose, start planning your migration to Git.

Upvotes: 2

Related Questions