我一直在处理我公司的CI扩展问题，同时试图弄清楚在CI和多个分支机构中采用哪种方法。在stackoverflow，多个功能分支和持续集成上也存在类似的问题。我开始了新的话题，因为我想进行更多的讨论并提供有关问题的一些分析。
到目前为止，我发现我可以采用2种主要方法（或者可能采取其他一些方法？）。
每个分支有多套工作（在这里谈论詹金斯/哈德森）
人们使用shell工具，ant脚本和Jenkins CLI解决此问题的一些示例。看到：
将在您的CI群集上造成更多负载
因此，似乎如果我想为开发人员提供针对其自定义分支的CI，则需要Jenkins的特殊工具（API或shellscript或其他东西？）并进行缩放。或者，我可以告诉他们更多地合并到DEV，并在定制分支上不使用CI地生活。您会选择哪一个？或者还有其他选择？
当谈到扩展CI时，实际上是在扩展CI服务器的使用，以处理您所有的功能分支以及主线。最初，这看起来是一种好方法，因为分支机构中的开发人员可以获得CI作业所包含的自动化测试的所有优势。但是，您在管理CI服务器作业时遇到了麻烦（就像您已经发现的一样），更重要的是，您实际上并没有在做CI。是的，您正在使用CI服务器，但是您并没有持续集成所有开发人员的代码。
执行真实的CI意味着您所有的开发人员都将定期提交主线。说起来容易，但难的是要做到这一点而不会破坏您的应用程序。我强烈建议您查看持续交付，尤其是 第13章：管理组件和依赖项中 的“ 保持应用程序可发布” 部分。要点如下： __
隐藏新功能，直到完成为止（又称为Feature Toggles）。 以一系列小的更改为增量进行所有更改，每个小更改都是可发布的。 使用抽象分支来对代码库进行大规模更改。 使用组件解耦应用程序中以不同速率变化的部分。
除了通过抽象进行分支外，它们非常容易解释。这只是一个花哨的名词：
在需要更改的系统部分上创建一个抽象。 重构系统的其余部分以使用抽象层。 创建一个新的实现，直到完成，该实现才成为生产代码路径的一部分。 更新您的抽象层以委托给新的实现。 删除旧的实现。 如果不再合适，请删除抽象层。
第14章“高级版本控制”中 “ 分支，流和持续集成” 部分的以下段落总结了影响。 __
与创建分支机构并投入工夫来重新架构和开发新功能相比，渐进式方法无疑需要更多的纪律和关怀- 实际上确实需要更多的创造力。但这大大降低了更改破坏应用程序的风险，并将为您和您的团队节省大量时间，以解决合并问题，并使应用程序进入可部署状态。
放弃功能分支需要花费很多心思，您总是会遇到阻力。以我的经验，这种抵制是基于开发人员对主线提交代码感到不安全，这是一个合理的考虑。反过来，这通常是由于缺乏对上述技术的知识，信心或经验，并且可能是由于对自动化测试缺乏信心。前者可以通过培训和开发人员支持来解决。后者是一个非常困难的问题，但是分支并不能提供任何额外的实际安全性，它只是推迟了这个问题，直到开发人员对代码有足够的信心为止。
