当 TFVC 为源存储库时，Azure Pipelines 是不是支持使用同一管道构建和发布多个功能分支？

Posted 2023-03-22

【中文标题】当 TFVC 为源存储库时，Azure Pipelines 是不是支持使用同一管道构建和发布多个功能分支？

【英文标题】：Does Azure Pipelines support building and releasing multiple feature branches using same pipeline when TFVC is source repository?当 TFVC 为源存储库时，Azure Pipelines 是否支持使用同一管道构建和发布多个功能分支？

【发布时间】：2021-12-16 10:03:33

【问题描述】：

问题

我们希望能够从我们的不同功能分支构建代码并将代码部署到我们的各种环境中，而不必在每次拥有功能分支时都克隆和修改构建和发布管道。使用 TFVC 源代码控制时，Azure Pipelines 是否支持在管道中构建多个分支并执行基于分支的条件任务？如果是，怎么做？

背景

在本地运行 Azure DevOps Server 2020 Update 1。在我们的代码存储库中有多个应用程序，每个应用程序都有自己的开发、主和功能分支，使用 TFVC 作为源代码控制存储库。 Source Control Repository 结构如下：

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

我们有经典的（不是 YAML）构建管道，可以为我们的每个开发和主要分支构建、执行门控签入和发布工件。 然后，我们有发布管道，从这些构建中获取工件并将它们部署到我们不同的环境（开发、QA、生产）

迄今为止对问题的研究

根据to this documentation：似乎 Azure Pipelines 支持使用 Git 作为源代码控制存储库在一个构建管道中构建多个分支，因为您可以指定执行某些任务，例如使用支持的条件仅在某些分支中构建某些解决方案文件Build.SourceBranch 变量 (as mentioned here)。

但是，当使用 TFVC 作为源并尝试进行构建时，它不会将 Build.SourceBranch 变量设置为分支名称（在我们的例子中，即：dev、dev-feature-1、main 等)，而是将其设置为 Team Project 的根目录（即：在我们的例子中为 $/Team Project），因此我们无法根据正在构建的分支执行条件逻辑来执行某些任务，这使得它所以我们不能使用一个构建定义来构建多个分支，并且可能让我们只能为每个功能分支创建一个新的构建和发布管道（这将是乏味的）。

【问题讨论】：

在我以前的公司中，我们使用 rest api 创建了一个适用于任何功能分支的新版本...

【参考方案1】：

不，Azure Pipelines 不支持构建的高级映射，TFVC 也不支持 YAML 管道。

有一些变通方法，但在我们探索这些方法之前，我必须强烈敦促您和您的团队考虑迁移到 Git。 TFVC 显然已经走到了生命的尽头，Azure DevOps 本身在未来将被 GitHub 取代。 TFVC 是一条死胡同。

至于解决方法：

您可以有一个在添加新分支时触发的管道，然后将管道用于您的默认分支并复制它。这可以使用 REST API 来完成。您必须重写映射和触发器以匹配 etarget 分支，并且如果对文件的所有其他引用使用 $(Build.SourceDirectory) 变量来查找他们需要的文件，那么整个管道可以轻松地从一个分支移植到另一个分支。 您可以使用my

TFVC - Do not sync sources

task 来防止您的构建创建工作区并检出文件。然后依靠自定义脚本在管道的其余部分之前设置正确的映射和获取文件。 您可以将上述任务与the

TFVC Get

task 一起使用来获取源代码，而无需完全依赖工作区配置。

为确保您知道要构建哪个分支，您可以在排队时设置一个变量，或者查看触发构建的变更集以确定它触发的分支。

但是，无论您选择什么解决方法，请开始计划迁移到 Git。