以下内容根据讲师PPT和视频整理而成。
什么是持续集成？
大师Martin Fowler认为持续集成是一种软件开发实践，在实践中团队开发成员会频繁的进行任务的集成，通常每个成员每天都会集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建来验证，从而尽快地发现集成错误，快速进行修复。
如上图所示，一个完整的持续集成环节包括：首先项目经理创建一个项目，将项目成员添加到项目中；开发人员在项目中拉取开发分支进行代码开发，在开发过程中，开发人员将代码提交到代码仓库（如SN、GIT）；后端的持续集成任务会定时扫描代码仓库，如果发现代码有变更，马上触发一次CI构建，一次CI包括源码下载、代码编译、静态扫描、单元测试、覆盖率分析、sona检查、环境打包部署、自动化用例执行等；再以消息的形式反馈结果给代码提交人或者项目关注人。消息的形式有两种，一种是即时消息，如阿里内部的旺旺、钉钉，让开发人员第一时间收到CI结果概况，如有问题，可以进行快速修复；另一种是邮件通知，可以看到CI结果详情，帮助问题的定位和跟踪，有益于驱动大家修复问题。
持续集成的优势
持续集成有哪些好处呢？
首先来看一幅图，大家应该都比较熟悉，冰山一角，如果把它移植到研发测试流程上面来讲，我们看的到的冰山，就好比开发阶段发现的Bug，比起海面以下的冰山，简直就是小巫见大巫。因此，持续集成给我们带来的直接好处，就是不断的发现海面以下的Bug，让我们能在开发阶段尽可能多的解决问题；其次，Bug越往后面发现，处理它的成本会越高，付出的代价也越大，因此，持续集成能帮助到我们降低项目研发成本；最后，如右侧图片所示，当持续集成不断的完善项目时，会潜移默化的推动着我们测试前移的动作，从没有集成的1，到集成初期的2，最终不断完善的集成3，成本越来越低、代码质量越来越高、发布时间越来越短 、从而使产品的品质越来越好。
持续集成涉及整个项目生命周期的人员，包括需求方、开发、测试、产品经理等。对于开发人员，他们希望能有单测、覆盖率、findbugs、sonar等自动化集成工具，尽早发现缺陷，这样流入测试环节的问题就会变少，从而保证代码质量；对于测试人员，他们希望尽早集成发现缺陷，提高待测质量，降低项目风险；产品经理则希望项目能按期、保质保量的安全上线。因此我们需要一个持续集成平台来保障上述利益。
平台演进
下面来介绍一下平台演进的过程。
主流的持续集成工具主要有：
- Jenkins，它的前身是Hudson ，是一个可扩展的持续集成引擎。它的功能比较强大，支持分布式任务构建。
- GoCD，一款先进的持续集成和发布管理系统，由ThoughtWorks开发，其前身为CruiseControl，是ThoughtWorks在做咨询和交付交付项目时自己开发的一款开源的持续集成工具，ThoughtWorks专门成立了一个项目组，基于Cruise开发出了GoCD这款工具。使用GoCD来建立起一个项目的持续部署pipeline是非常快的，非常方便，它的不足点是插件较少、开源时间短、用户群体较小；
- Apache continuum，其安装和配置都较为方便；
- Strider 是一个开源的持续集成和发布服务器，使用 Node.js 开发；
- TeamCity是一款功能强大的持续集成（Continue Integration）工具，包括服务器端和客户端，目前支持Java、.Net项目开发，是一款商业软件；
- Atlassian Bamboo 是一款持续集成构建服务器软件(Build Server)商业软件；
- Travis CI是一个基于云的持续集成项目，目前已经支持大部分主流语言了，比如C、PHP、Ruby、Python、Nodejs等。和Jenkins类似，Travis CI也是开源的，不过Travis和Github集成非常紧密，官方的集成测试托管只支持Github项目， 不过用户也可以搭建一套自己的方案。
通过对上述持续集成工具的比较，阿里最终选择了Jenkins这一工具，Jenkins作为一款开源软件，有着丰富的插件（目前已达几百个），还可以自定义插件以及修改或增加Jenkins扩展点，来进行Jenkins功能扩展。
对于小团队而言，Jenkins完全可以满足需求了，但是对于一个成百上千，甚至更多人的团队来讲，就显得有点弱了。第一，Jenkins不能自动创建Jenkins任务，必须在Jenkins平台上手工创建，大大降低了集成效率，而且需要大家都掌握创建Job的方法以及Job上的配置，不利于工具推广；第二，其数据显示不能定制化，如果想要集成数据在一个页面上显示，那么Jenkins是无法满足这个要求的；第三，数据不能持久化，目前Jenkins的数据是通过文本的方式保存的，而且量很大，不利于数据维护和后续的数据分析；第四，执行机掉线没有报警功能，不会及时通知管理员及时处理；第五，数据反馈机制比较单一，Jenkins仅支持邮件的方式进行发送通知；第六，通过项目信息查询任务困难，Jenkins没有项目的维度，只有Job的维度，不方便查找。
因此，单测集成平台Amon应运而生，它始于2012年，目前已有10多家公司，正在使用这一产品。Amon的优势在于其任务全自动构建，并支持大规模集成、数据持久化，具有丰富的报表和多维度的数据分析，Amon和Jenkins详细功能对比如上图所示，这里不再一一叙述。
我们针对Jenkins插件进行了新增和修改，以便它们适应于Amon，主要包括：
- Maven pom内容修改插件，它能满足一些特定功能；
- Maven多模块构建插件，支持多路径发现pom文件；
- MQ构建结果通知插件，它能够通过消息的形式发送到平台；
- Hosts修改插件，以此支持特定服务的测试；
- Cppcheck编译扫描结果插件；
- Antx文件自动生成插件；
- 支持cobertura结果合并插件；
- 支持cobertura增量覆盖率插件；
- 支持jshint扫描插件
- 支持多执行机空间清理插件
- Sonar-runner自动找java路径
集成实践
目前，阿里内部集成状况是支持10w+的日均构建数，平均每秒发生四次构建，这是一个非常庞大的量。我们的平台是如何来做支撑的呢？
首先，系统通过负载均衡模块将集成任务分配至各集群中；在每个集群中都有大量Jenkins机器来做持续集成构建，它是可以进行横向扩展的，因此我们就能很好地进行大规模的构建。在构建过程中，难免会有一些任务排队等待，这样会导致一些用户等待时间较久。
我们针对这一情况进行了优化：相同集群的Slave可以灵活、自由调度，如果某台Jenkins任务比较吃紧，它就会从最空闲的Jenkins上调度一台Slave过来支持当前的任务构建，以解决任务排队严重的问题。但是，过于频繁的Slave调度势必会影响到系统处理时间和性能。因此，接下来将详细讲解负载均衡做到最优任务分配的原理。
这里提到的负载均衡和常见的负载均衡还是存在差异的。这里提到的负载均衡任务集成自驱的，也就是其可以定时自动构建，因此，你不太清楚一个任务一天回构建多少次，也不清楚一次构建的时长是多少。在分配任务的时候，可能比较难以选择，如果仍然按照平均分配的方式，势必会形成每个Jenkins上任务个数相同，但是基于每个任务的构建时长和频率都存在差异，这样又会导致一些Jenkins排队非常严重，那么如何解决这个问题呢？
首先需要了解一下Jenkins中的参数：其中n表示任务数、m表示执行机数、T表示最大构建负载（T=m*8*60），如超过最大负载值，任务排队现象会加重；Jenkins第k个任务构建总耗时用tk（tk=任务最近一次构建耗时（分钟）*该任务历史日均构建次数）表示。根据上述参数，可以计算出Jenkins当前的负载值H，公式为：
利用当前的负载值，进行任务分配，做到最优化：当任务分配到Jenkins时，同时需要增加Jenkins的负载值以及修改该任务的平均耗时和平均构建频率，不断地调整，以便于趋于稳定；当任务关闭时，需要减去相应的时间来调整负载值。该算法的思路较为简单，但实现时比较困难，主要是由于任务的耗时和频率会发生变化，需要实时调整以改变负载值，让集成任务分配到最合适的Jenkins上去。
