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

Question 1

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

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

每个分支多套工作（在这里谈论詹金斯/哈德森）
- 编写工具来管理额外的工作
  - 批量创建/修改/删除作业
  - 每个分支的每个作业的自定义设置（SCM url，dep管理存储库重复项）
  - 人们使用shell工具，ant脚本和Jenkins CLI解决此问题的一些示例。看到：
- 将在您的CI群集上造成更多负载
- 开发人员的反馈周期变慢（如果基础架构无法处理新的负载）
每2个分支有多套作业（开发和稳定版）
- 手动管理这两个集合（如果您更改作业的配置，那么请确保在另一个分支中进行更改）
  - PITA，但至少很少要管理
- 其他多余的分支机构在推向开发人员之前不会获得完整的测试套件
- 开发者不满意。开发人员为什么要关心CI扩展问题。他有一个简单的请求，当我分支时，我想测试我的代码。简单。

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

Question 2

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

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

隐藏新功能，直到完成为止（又称为Feature Toggles）。

以一系列小更改为增量进行所有更改，每个小更改都是可发布的。

使用抽象分支来对代码库进行大规模更改。

使用组件解耦应用程序中以不同速率变化的部分。

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

在您需要更改的系统部分上创建一个抽象。

重构系统的其余部分以使用抽象层。

创建一个新的实现，直到完成，该实现才成为生产代码路径的一部分。

更新您的抽象层以委托给新的实现。

删除旧的实现。

如果不再合适，请删除抽象层。

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

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

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

Question 3

我会为每个分支机构分别设置工作。我之前已经做过，如果您正确设置了Hudson / Jenkins，就不难管理和设置。创建多个作业的快速方法是从具有类似要求的现有作业中复制并根据需要进行修改。我不确定是否要允许每个开发人员为自己的分支机构设置自己的工作，但是由一个人（即构建经理）来管理这并不需要太多工作。自定义分支合并到稳定分支后，可以在不再需要相应的作业时将其删除。

如果您担心CI服务器上的负载，则可以设置CI的单独实例甚至单独的从属，以帮助平衡多台服务器上的负载。确保正在运行Hudson / Jenkins的服务器足够。我使用过Apache Tomcat，只是必须确保它具有足够的内存和处理能力来处理构建队列。

重要的是要清楚要使用CI实现的目标，然后找出一种无需大量人工或重复就可以实施的方法。使用其他由CI服务器执行的外部工具或脚本没有问题，这些工具或脚本有助于简化整体构建管理过程。

Question 4

我会选择dev + stable分支。而且，如果您仍然想要自定义分支并且担心负载，那么为什么不将这些自定义分支移到云中，让开发人员自己管理它，例如，http : //cloudbees.com/dev.cb 这是Kohsuke现在所在的公司。还有一个Eclipse Tooling，因此，如果您使用的是Eclipse，则将其紧密集成到dev env中。

Question 5

实际上，真正存在问题的是带有功能分支的构建隔离。在我们公司中，我们有一组单独的Maven项目，它们都是较大发行版的一部分。这些项目由不同的团队维护，但是对于每个发行版，所有项目都需要发布。现在，一个功能分支可能从一个项目重叠到另一个项目，这就是构建隔离变得很痛苦的时候。我们尝试了几种解决方案：

在每个功能分支的关系中创建单独的快照存储库
在专用奴隶上共享本地存储库
对上游存储库使用repository-server-plugin
通过一个私有存储库在一件事中构建全部内容

实际上，最后的解决方案是最有前途的。所有其他解决方案都缺乏一种或另一种方式。与job-dsl插件一起，可以轻松设置新功能分支。只需复制并粘贴groovy脚本，调整分支并让种子作业创建新作业。确保种子作业删除了非托管作业。然后，您可以轻松地在不同的Maven项目上使用要素分支进行缩放。

但是正如汤姆在上面所说的那样，最好克服功能分支的必要性，并教开发人员进行干净的集成，但这是一个更长的过程，而且对于许多不再需要使用的遗留系统部件，结果尚不清楚。

我的2美分