2

让我先描述一个简单的 CI 工作流程（我们使用 git、Jenkins、maven、nexus）：对于一个项目，有人从 master 分支创建一个分支，进行更改、验证和代码审查。现在有人提出改变要求。

以下都是自动化的。更改被合并到 master 并排队等待发布。要部署，对于队列中的每个项目，二进制文件是从 master 分支构建的（使用标签或提交 id），运行测试套件，并以 1% 的流量进行部署。在 12 小时内，我们自动分析性能数字和业务数字，此时我们提供 100% 的流量。然后拿起队列中的下一个项目。

每个 100% 版本的一个更改的分离是很重要的，因为如果多个更改在一个版本中，则很难调试错误。

这一切都很好，直到出现问题。

  • 假设我们将 Feature1 推到 1% 的流量，发现数字不好，在 12 小时内发现，Feature2 已合并到 master。在这种情况下，如果我们想要 Feature2 去恢复有缺陷的 Feature1 直到我们修复它的错误，就需要在 Feature1 上执行 git revert。
  • 在上面的案例中，Feature1 非常重要，我们也发现了问题并知道了修复方法。然后我们需要从 master 恢复 Feature2，将 Feature1 fix 合并到 master 并重置队列。
  • 如果在功能之外有一些紧急修复，此时生产处于 Feature0，Feature1 处于试验阶段。我们希望 Feature0 的紧急修复达到 100%。这一次我们需要从 master 恢复 Feature1。

是否有一个工作流程，使用多个分支而不是只使用 master 或添加更多自动化，从而避免 git reverts - 特别是在完成他/她的功能的开发人员没有做错任何事情的情况 2 和 3 中。

4

2 回答 2

1

假设您已阅读上面 Naomi 的回复。这就是我们最终要合作的：

按照 Naomi 的描述，有一个发布分支和开发分支。这里唯一的区别是我们允许合并在发布 HEAD（在开发之后）和开发 HEAD 之间的任何时间点发布。这使我们能够限制发布的功能数量，并让开发人员在完成后立即将他们的新功能从功能分支合并到开发分支。

除此之外，我们还添加了一个单独的“修补程序”分支。这通常会远远落后于发布分支，并且仅在需要时使用。假设某个功能 X 推出了 1%，我们需要推出一个独立于功能 X 的 100% 紧急修复。然后我们将修补程序分支更新到我们处于 100% 的点（在功能 X 之后），进行更改在那里，并从修补程序分支本身构建/测试/发布。在此之后，我们需要合并此修复以掌握和开发未来版本。

这为我们减少了还原案例。

于 2013-08-29T08:19:16.327 回答
1

看来你对主人做的太多了。使用开发和发布分支的 git-flow-ish 模型，以及每个功能和每个错误修复的单独分支如何？

它如何与您提到的那种场景一起工作的示例：

上午 9 点生产 (100%) 在发布标签 1 上。功能 A 已完成，因此分支功能 A合并到开发中

每天上午 10 点发布时间...合并开发到发布，削减（标签 2）并将发布标签 2 发布到 1%

11am 有人完成了 Feature B 的编码并将featureB合并到开发中

中午12点紧急！功能 A 有一个错误。将生产 (1%) 回滚到标签 1。从发布标签 2 中获取一个分支（记住发布分支不包含功能 B），称为bugfixA，然后开始修复错误。

下午 4 点 Bug 修复被签署 - 将bugfixA合并到release中，削减（标签 3）并滚动。还将 bugfixA合并到develop中，并针对develop运行所有测试，以确保 Bugfix A 不会与功能 B 冲突。

第二天上午 10 点 - 推出时间！合并开发到发布，取标签 4 并推送到 1% - 推送功能 B 即

与此同时，某处标签 3（包含功能 A 及其补丁）通过了 12 小时的测试并进入 100% ...

于 2013-07-31T13:24:09.323 回答