我们如何更好地管理 azure git 并构建管道？

Question

我们使用 azure pipeline 和 Azure Git 已经有一段时间了，这是我们的流程。

• 每个 sprint 我们都会基于 Master 分支创建一个 sprint 分支
• 对于每个故事，我们都会根据 sprint 分支创建一个故事分支
• PR 后，story 分支将基于 sprint 分支重新构建
• sprint 完成后，sprint 分支将重新基于 Master 分支

事实证明，在 sprint 完成后，很难记住要重新定位到 Master 分支。 此外，我们需要更改构建管道以在每个 sprint 中使用新的 sprint 分支。

这确实成为我们的负担，在某些情况下我们只是忘记将东西合并回 Master。我们有几个存储库，这确实使过程变得更糟。

你们是怎么处理的？

sprint 完成后是否可以自动变基到 master 分支（所以总是忽略冲突）？

对于 azure 构建管道，是否可以应用一些规则，这样我们就不必为每个 sprint 不断更改构建源？

Answer 1

你们是怎么处理的？

我们做同样的事情，但没有任何 sprint 分支。

在一个项目中，一旦故事完成，我们将故事分支合并到主分支。

在另一个项目中，除了 master 之外，我们还有一个“dev”分支。 因此，一旦故事完成，故事就会重新定位到 dev 中，然后在我们准备好发布时将 dev 合并到 master，这会触发 UAT 和生产管道。

sprint 完成后是否可以自动变基到 master 分支（所以总是忽略冲突）？

您也许可以通过scheduled trigger 做到这一点

但我认为更简单的解决方案是拥有一个长期存在的 dev 分支，而不是短期的 sprint 分支。 IE。故事完成后将故事重新设置为 dev，然后在 sprint 结束时将 dev 合并为 master。 它不能解决忘记合并到 master 的问题，但可以确保工作不会丢失在被遗忘的分支中。

对于 azure 构建管道，是否可以应用一些规则，这样我们就不必为每个 sprint 不断更改构建源？

如果所有 sprint 分支的名称都相同， 您可以使用与所有这些匹配的触发器。

即azure-pipelines.yml 中的类似内容：

trigger: sprint/*

更多 info here 包括如何在经典 UI 中执行相同操作（如果您不使用 YAML）。