管道触发器和发布分支

Question

我正在将 TFS 存储库迁移到 git 并查看不同的分支策略。我喜欢微软在这里https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops 建议的那个，但在发布分支上有点挣扎。

存储库是一个包含几个不同应用程序的单一存储库。当我创建一个新的发布分支时，我希望它触发管道来构建自上次发布以来已更改的应用程序，而不是所有应用程序的管道。

我想要完成的工作流程：

• 通过功能分支和拉取请求在主分支上开发
• 提交到主分支将触发构建到我们的 QA 环境 带有路径触发器。例如，对 /ApplicationA 的提交将触发 ApplicationA 的管道构建
• 准备发布时，创建一个新的发布分支，该分支将触发构建并将候选发布版部署到我们的 UAT 环境中

当我创建一个新的发布分支时，我希望它触发所有应用程序的管道，这些应用程序自上次提交到上一个发布分支后发生了变化。

这是否可以使用管道触发器进行设置，或者我最好使用长时间运行的发布分支，而不是为每个新版本单独设置一个？

Answer 1

当我创建一个新的发布分支时，我希望它触发所有应用程序的管道，这些应用程序自上次提交到上一个发布分支后发生了变化。

目前不支持您想要的行为，因为该功能已部分删除了很长时间。通常 Azure Devops Service 不会回滚到旧行为，除非新行为出现大问题。

您可以查看有关该行为的部分历史记录：

2018：一些成员（Issue1不是唯一一个）在我们的用户语音论坛中发布了功能请求以删除旧行为（新分支将触发 CI 构建）=> 2019 年 7 月：我们进行了更改以修改旧行为 => 2019 年 8 月：Some members 发现行为已更改。

这是否可以通过管道触发器进行设置，还是我会更好 有一个长期运行的发布分支，而不是每个单独的发布分支 新版本？

如果你新创建的分支只用于发布而不是开发，那么新创建的分支和mian分支没有区别。

这样，无需为每个新版本创建单独的版本。发布管道记录将清楚地显示发布版本来自哪个提交。我们只需要查看提交记录就可以知道所有的变化。

此外，为每个新版本单独创建一个会使我们的存储库变得臃肿且管理不便。所以我个人的建议是使用长期运行的发布分支