VSTS 发布定义与 GitFlow答案

【问题标题】：VSTS Release definition with GitFlowVSTS 发布定义与 GitFlow
【发布时间】：2018-09-19 20:08:50
【问题描述】：

CI/CD 人员的问题。我正在使用 VSTS 来自动化我们的 CI/CD 故事。在我们的代码仓库中，我们使用 git flow，这意味着代码从功能分支移动到我们的开发分支。在准备发布时，会创建一个特定的发布分支，并最终将代码合并到当前版本的 master 中。

现在我想知道的是如何在 VSTS 的发布管道中促进这一点。特别是开发和主分支与发布相结合的差异。我发现一个版本从特定的工件开始，因此也与这些工件源自的构建/分支相关联。在我看来，这意味着如果我们想从开发分支进行日常部署，但从主分支到验收和生产环境进行更手动的定时部署，我们需要两个发布定义？

我真的在寻找关于这个主题的一些最佳实践以及其他人已经发现如何最好地构建这个管道的东西。我已经找到了这个主题，但这并没有给我我想要的东西：Setup GitFlow in VSTS - Best practices?

【问题讨论】：

你不需要两个分支。您可以手动在主分支上对构建进行排队，然后使用该构建来创建发布。默认情况下，您的构建定义将配置为开发分支以每天进行计划构建。
@Harshil 我不关注。我知道我可以如何排队手动构建，但您还希望能够跟踪发布，不仅是现在，而且在几个月后该特定版本出现问题时也是如此。所以在我看来，仅仅发布一个构建确实满足了这个要求。同样在您评论的第二部分中，您提到了开发分支，这意味着实际上有两个分支？我很困惑:)

【解决方案1】：

有多种方法可以通过 VSTS CI/CD 促进 git flow。

下面是VSTS中的一种实现方式（两个CI构建定义和两个CD发布定义）。

develop 分支的 CI 构建和 CD 部署：在将新更改推送到 develop 分支后，将触发构建。然后您可以通过 develop 分支的更改部署到您的测试环境。
master 分支的 CI 构建和 CD 部署：新的更改合并到 master 后，将触发构建。构建后，将创建新版本以将新更改部署到环境中。另外，如果你通过 Pull Request 将 release 分支合并到master 分支，你还可以在合并前添加 PR 构建验证。

【讨论】：

您好玛丽娜，感谢您的回答。这几乎反映了我们现在所拥有的。唯一的区别是我们还希望每天从不稳定的开发分支部署到我们的测试环境。所以我想为此我需要一个单独的发布定义，至少这是我的结论？
是的，如果你需要通过develop分支部署到测试环境，它需要一个额外的发布定义。我更新了我的答案。
谢谢，这是有道理的，并且与我们自己已经想出的一致。但时不时地进行一点验证是很好的。
当然，使用单独的发布定义分别部署develop和master分支也可以省去需要区分工件是来自develop分支还是master分支的步骤。
@Jasper 可以让您的 develop 定义通过在提交时触发来执行 CI，但也可以在同一定义中设置创建构建的时间表（如夜间构建）