首页 文章

VSTS / TFS Git分支策略和持续集成

提问于
浏览 次
0

我们公司一直在使用git分支策略来保持长期运行的sprint工作分支，看起来像这样：

master
  \
   Sprint
     \
      Feature1
      Feature2

在当前的sprint中，我们切换到为每个sprint创建一个新名称的新分支：

master
  \
   Sprint123
     \
      Feature1
      Feature2

随着这种变化，出现了一些痛点：

  • 每次创建新的Sprint ###分支时都必须设置策略（包括持续集成和拉取请求设置） .

  • 构建定义具有通过通配符（"Sprint*"）仍然可以正常工作的触发器，但构建的存储库源设置不支持通配符 .

我已经阅读了VSTS文档，但我觉得我已经错过了如何设置每个sprint的新分支（这与VSTS分支策略文档一致） .

所以，问题是：

Our expectation was that the branch that triggers the build is the one that is built. Is this possible?

What is the recommendation for setting branch policy each time a new branch is created off of master? Should we just expect that we will have to configure all of the settings manually every time?

git continuous-integration azure-devops

2 回答

  • 3

    我们已经发表了guidance on Git branch strategy . 指向TFVC的兄弟答案是不正确的 .

    对于大多数团队，我们不建议长期运行的开发分支 . 相反，保持一个干净的主人并使用短期主题分支 . 然后，您将不需要继续创建和删除策略，构建定义等 .

    如果由于某种原因必须继续使用长期分支，请考虑在分支的名称中使用斜杠，例如 sprints/s100 . 我们已经有一个REST API（很快就是管理员用户界面）来设置prefix-matching basis的策略，在 / 停止 . 因此，您可以在 sprints/ 上设置分支策略，它将自动应用于 sprints/s100 ， sprints/s101 等 .

    回复于
  • 1

    推荐的分支策略始终是 use the same branch even for new sprints . 作为this article，您可以始终使用 development branch进行不同的sprint .

    当然，如果两个冲刺之间的代码完全不同，您可以使用分支策略 . 但缺点是：

    • 每次创建新分支时设置分支策略 .

    • 随着时间的推移，将有大量的分支 sprint* ，很难轻松追踪整个项目版本 .

    最后，针对您的问题（如果您仍需要当前的策略）：

    • 是的，您仍然可以在构建定义触发器选项卡中使用格式 Sprint* ，然后您新创建的分支Sprint ###也将适用于CI构建 . 获取构建定义的源步骤不会影响您的CI构建，repo和branch仅选择手动构建队列 .

    • 您需要每次为新创建的分支手动设置分支策略 .

    回复于

相关问题