持续集成工作流程 - 紧急用例

Question

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

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

每100％版本中一次更改的这种分离非常重要，因为如果在一个版本中有多个更改，则调试错误变得非常困难。

这样做会很好，直到出现问题。

• 假设我们将Feature1推送到1％流量，找到数字是坏的，并且在12小时内计算出来，Feature2已合并为master。在这种情况下，如果我们想要Feature2去恢复错误的Feature1，直到我们修复它的bug，就需要在Feature1上完成git revert。
• 在上面的例子中，Feature1非常重要，我们也发现了什么错误并知道修复。然后我们需要从master恢复Feature2，将Feature1修复合并到master并重置队列。
• 如果在功能之外有一些紧急修复，此时生产位于Feature0，并且Feature1处于试用状态。我们希望Feature0上的紧急修复程序达到100％。这次我们需要从master恢复Feature1。

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

Answer 1

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

如何使用您提到的场景：

上午9点生产（100％）在发布标签1上。 功能A已完成，因此分支 featureA 合并为开发

每天上午10点展示时间...将开发合并到发布，剪切（标记2）并将发布标记2展开到1％

上午11点有人完成对功能B的编码并将 featureB 合并到开发

中午12点紧急情况！功能A有一个错误。将生产（1％）回滚到标记1.从发布标记2中取一个分支（记住发布分支不包含功能B），称为 bugfixA ，并开始修复bug。

下午4点错误修复得到签署 - 将 bugfixA 合并到发布，进行剪切（标记3）并滚动。还要将 bugfixA 合并到开发中，并针对开发运行所有测试，以确保Bugfix A不会与功能B冲突。

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

同时某处标记3（包含功能A及其补丁）通过12小时测试并进入100％......

Answer 2

假设您已阅读Naomi的回复。 这是我们最终合作的内容：

如Naomi所述，拥有一个发布分支并开发分支。这里唯一的区别是我们允许合并在发布HEAD（后面开发）和开发HEAD之间的任何时候发布。这允许我们限制正在发布的功能的数量以及解锁开发人员，以便在功能完成时将其新功能从功能分支合并到开发分支。

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

这最大限度地减少了我们的还原案例。