在持续集成中处理多个分支

Question

我一直在处理我公司的CI扩展问题，同时试图弄清楚在CI和多个分支机构中采用哪种方法。在stackoverflow，多个功能分支和持续集成上也存在类似的问题。我开始了新的话题，因为我想进行更多的讨论并提供有关问题的一些分析。

到目前为止，我发现我可以采用2种主要方法（或者可能采取其他一些方法？）。

• 每个分支有多套工作（在这里谈论詹金斯/哈德森）

  • 编写工具来管理额外的工作
  • 批量创建/修改/删除作业
  • 每个分支的每个作业的自定义设置（SCM url，dep管理存储库重复项）

  • 人们使用shell工具，ant脚本和Jenkins CLI解决此问题的一些示例。看到：

    1. http://jenkins.361315.n4.nabble.com/Multiple-branches-best-practice-td2306578.html
    2. http://jenkins.361315.n4.nabble.com/Is-it-possible-to-handle-multiple-branches-where-some-jobs-should-on-on-each-one-without-duplicatin-td954729。 html
    3. http://jenkins.361315.n4.nabble.com/Parallel-development-with-branches-td1013013.html

  • 将在您的CI群集上造成更多负载

  • 开发人员的反馈周期变慢（如果基础架构无法处理新的负载）
  • 每2个分支有多组作业（开发和稳定版）
  • 手动管理这两个集合（如果您更改作业的配置，请确保在另一个分支中进行更改）
  • PITA，但至少很少要管理
  • 其他多余的分支机构在进入开发之前不会获得完整的测试套件
  • 开发者不满意。开发人员为什么要关心CI扩展问题。他有一个简单的请求，当我分支时，我想测试我的代码。简单。

因此，似乎如果我想为开发人员提供针对其自定义分支的CI，则需要Jenkins的特殊工具（API或shellscript或其他东西？）并进行缩放。或者，我可以告诉他们更多地合并到DEV，并在定制分支上不使用CI地生活。您会选择哪一个？或者还有其他选择？

Answer 1

当谈到扩展CI时，实际上是在扩展CI服务器的使用，以处理您所有的功能分支以及主线。最初，这看起来是一种好方法，因为分支机构中的开发人员可以获得CI作业所包含的自动化测试的所有优势。但是，您在管理CI服务器作业时遇到了麻烦（就像您已经发现的一样），更重要的是，您实际上并没有在做CI。是的，您正在使用CI服务器，但是您并没有持续集成所有开发人员的代码。

执行真实的CI意味着您所有的开发人员都将定期提交主线。说起来容易，但难的是要做到这一点而不会破坏您的应用程序。我强烈建议您查看持续交付，尤其是
第13章：管理组件和依赖项中 的“ 保持应用程序可发布” 部分。要点如下： __

• 隐藏新功能，直到完成为止（又称为Feature
  Toggles
  ）。
• 以一系列小的更改为增量进行所有更改，每个小更改都是可发布的。
• 使用抽象分支来对代码库进行大规模更改。
• 使用组件解耦应用程序中以不同速率变化的部分。
  
  

除了通过抽象进行分支外，它们非常容易解释。这只是一个花哨的名词：

1. 在需要更改的系统部分上创建一个抽象。
2. 重构系统的其余部分以使用抽象层。
3. 创建一个新的实现，直到完成，该实现才成为生产代码路径的一部分。
4. 更新您的抽象层以委托给新的实现。
5. 删除旧的实现。
6. 如果不再合适，请删除抽象层。
   

第14章“高级版本控制”中 “ 分支，流和持续集成” 部分的以下段落总结了影响。 __

与创建分支机构并投入工夫来重新架构和开发新功能相比，渐进式方法无疑需要更多的纪律和关怀-
实际上确实需要更多的创造力。但这大大降低了更改破坏应用程序的风险，并将为您和您的团队节省大量时间，以解决合并问题，并使应用程序进入可部署状态。

放弃功能分支需要花费很多心思，您总是会遇到阻力。以我的经验，这种抵制是基于开发人员对主线提交代码感到不安全，这是一个合理的考虑。反过来，这通常是由于缺乏对上述技术的知识，信心或经验，并且可能是由于对自动化测试缺乏信心。前者可以通过培训和开发人员支持来解决。后者是一个非常困难的问题，但是分支并不能提供任何额外的实际安全性，它只是推迟了这个问题，直到开发人员对代码有足够的信心为止。