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

Posted 2023-03-06

【中文标题】如何使用 TeamCity 和 Octopus 完成这种分支和部署策略

【英文标题】：How to Accomplish This Branching and Deployment Strategy Using TeamCity and Octopus

【发布时间】：2016-05-16 20:26:06

【问题描述】：

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

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

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

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

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

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

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

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

【问题讨论】：

您的问题是什么？您已经描述了基础设施和一些一般性的想法，但您的文本中没有问题，也无法给出答案（讨论和自以为是的 cmets 确实不是答案）。

很抱歉。我已经更新了标题。我试图弄清楚如何使用列出的工具来完成列出的要求。

这个问题太宽泛了。这是 2 个自动化工具和一个 SCM，它们几乎可以完成任何事情。你能提供一个设计/实践，我们看看我们是否可以提供改进它的想法？这可能更容易。

【参考方案1】：

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

---

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

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

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

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

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

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

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

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

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

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

李>

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

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

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

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

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

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