如何使用 TeamCity 和 Octopus 完成这种分支和部署策略

Question

我一直在研究并试图找出满足以下要求的最佳分支和部署策略。也许我错过了一些东西，但它比看起来更复杂。理想情况下，我们只有一个永久分支“master”，它可以标记特定的提交以将发布标记为生产。

我们当前的策略基于 Git Flow，并拥有永久分支“master”（只有发布到生产环境）和“develop”。使用多个永久分支模型复杂化的主要问题是，将同一构建从暂存环境“提升”到生产环境的概念。目前，这需要在单独的源代码分支中完成（部署到 staging 来自“develop”，部署到 prod 来自“master”）。

工具： Git (VSTS)、TeamCity、Octopus Deploy

要求（功能和修补程序生命周期）：

• 所有代码均通过拉取请求审核（通过分支策略强制执行）
• 所有代码都部署到暂存环境中进行测试
• 我们可以快速返回到之前部署的任何代码快照
• 如果测试成功，则可以将相同的构建从我们的暂存环境“提升”到生产环境（无需再次构建）

在作为单个版本推出生产之前，功能会随着时间的推移而积累。修补程序必须能够通过，而不会陷入“全有或全无”的下一个常规版本。

我喜欢拥有一个带有标签的永久分支的想法（回复：主/开发拆分是多余的，http://endoflineblog.com/gitflow-considered-harmful），但是拥有额外的永久分支可能更好地促进部署到不同的生命周期/版本（功能和修补程序）以章鱼。

我一直在努力解决如何最好地解决这个问题，我可能过于复杂了。感谢您提供任何反馈。

Answer 1

看来您有很多问题，而且范围很广...我将在您的每个要求中添加一些 cmets 作为对话启动器，但是整个线程可能会被版主阻止，因为它绝对不是SO的问题风格。

---

所有代码都通过拉取请求审查（通过分支策略强制执行）

我已经很久没有研究过 VSTS，但我希望它们已经支持分支策略和拉取请求，所以除了在存储库中配置设置之外，不确定这里是否还有其他需要。

如果 VSTS 不支持该功能，您可能会考虑迁移到一个可以支持的工具，例如BitBucket、GitHub 等。这两个都有本地版本，以防您不能（或不想）使用云托管版本。

所有代码都部署到暂存环境进行测试

您可以通过设置 lifecycles in Octopus Deploy 来实现这一点，以确保部署/促销遵循您想要的顺序。

我们可以快速返回之前部署的任何代码快照

您已经拥有源代码控制，因此您现在需要的只是从环境中部署的代码到 Octopus Deploy 中的部署版本、TeamCity 中的构建作业、源代码控制中的分支和准确提交的可追溯性。

您可以做一些事情来实现这一目标：

1. 定义适合您的版本控制方案。我喜欢使用语义版本控制。 “主要”和“次要”版本由开发人员定义，“补丁”是来自 TeamCity 的自动递增数字 (%build.number%)。每个git push 构建代码并生成唯一的构建版本（%major%.%minor%.%build.number%）

2. 作为 TeamCity 中构建步骤的一部分，在编译代码之前，请确保使用每个构建分配的版本号修补源文件，提交哈希 来自您的源代码管理，和分支名称。例如如果您使用的是 .NET，请确保使用该版本更新所有 AssemblyInfo.cs 文件，以便该版本嵌入到二进制文件中。这允许任何人查看二进制文件的属性来查询版本，还允许您在应用本身上显示应用版本（例如状态栏、页脚、标题、关于框等）

   李>

3. 让 TeamCity 使用每个构建的版本号标记您的源代码管理，以便您可以快速查看源代码管理历史记录。您可能只想对 master 分支执行此操作，尽管这是您关心的。

4. 让 Octopus 使用部署版本号和环境名称标记您的源代码控制，以便您可以快速查看（从您的源代码控制）哪些内容被部署在哪里。

第 1 步和第 2 步是最重要的，真的。 3 和 4 只是很好有。大多数情况下，您只需在环境中打开应用程序，检查“关于”中的提交哈希，然后对该提交哈希执行 git checkout...

如果测试成功，那么相同的构建可以从我们的暂存环境“提升”到生产环境（无需再次构建）

同样，Octopus Deploy lifecycles，并确保在应用程序的配置文件中定义了每个环境中的任何不同之处，该文件在 Octopus 部署期间使用environment-specific variables 进行更新。

就分支工作流程而言，最后一项要求强制在部署生命周期开始之前将更改合并到 master（或任何您的“生产”分支）。