0

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

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

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

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

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

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

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

我一直在努力解决如何最好地解决这个问题，我可能会把事情复杂化。任何反馈表示赞赏。

4

1 回答 1

1

看来您有很多问题，而且范围很广...作为对话的发起者，我将为您的每个要求添加一些评论，但是整个线程可能会被版主阻止，因为这绝对不是问题的风格SO是为此而生的。

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

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

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

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

您可以通过在 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 部署生命周期，并确保在应用程序的配置文件中定义每个环境中的任何不同，该配置文件在 Octopus 部署期间使用特定于环境的变量进行更新。

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

于 2016-05-19T23:38:10.877 回答