【发布时间】：2020-08-13 12:59:04
【问题描述】：
我一直在为我们的团队进行一些研究，以迁移到新的分支策略。目前我们正在使用只有 master 和 feature 分支的 github 流。但是由于我们在修补程序方面遇到了一些问题，我认为我们应该使用发布分支迁移到 gitflow，所以我们有一个稳定的分支，我们可以在需要时进行修补程序。我们使用 Azure Devops 作为我们的平台。
到目前为止，我遇到的问题是，当我们创建一个新的发布分支时，我们应该如何触发我们的持续部署管道？
通常在合并 PR 并运行 CI 构建时会触发管道。但是，当您创建一个新的发布分支并希望将其部署到例如验收环境时，我们应该如何触发这些管道？另一个问题是我们的存储库中有多个可发布组件。因此，当我们创建发布分支时，我们最终不得不查找我们更改了哪些组件，为它们运行手动构建，以便触发我们的管道。
在我看来这应该是一个常见问题，但我找不到太多关于此的信息，这表明我在这里遗漏了一些东西。我错过了什么？
问候
【问题讨论】：
-
我看到一个非常接近的投票结果，这是一个基于意见的问题。这简直是愚蠢的。这就是我们正在谈论的 Azure DevOps。你可以，或者不能。我也不确定为什么这得到了两次反对票。作为 Git 中的发布分支并不少见，我相信其他人也有同样的问题。
-
您似乎在询问如何构建 gitflow 触发器......但是您可以围绕其时间和结构进行任何数量的流程。树枝会长生不老吗？你会从标签上剪下一个新的吗？我已经在几家公司设置了 gitflow 以在不同的 Azure DevOps 中发布不同的版本。所以是的，如前所述，我认为这可能会导致一些自以为是的答案。我们不了解您的流程，因此很难给您一个好的答案。
-
如果您只是专门询问如何触发发布，您可以分支到 Release\ 文件夹并在 Release\ * 上设置构建触发器。或者，您可以在发布分支上设置与您的 master 匹配的策略，并针对该策略执行 PR。那么它与您当前的流程不会有太大不同？
-
嗨@Demoric。这张票有更新吗？如果答案能给你一些帮助，请随时告诉我。
-
是的，原来缺少的一些部分是创建分支也可以触发管道。最后一个缺失的部分是，为了仅精细地发布某些组件，我们将为每个要发布的组件创建一个发布分支。所以 release/componentA/release1.1 等。这可以防止我们触发所有我们不想要的组件。感谢您的帮助！
标签： git azure-devops continuous-integration continuous-deployment git-flow