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