京东POP研发敏捷工程实践之——持续集成
2018-11-12
来源：京东信息化+ POP平台测试组
持续集成是源于极限编程的实践，现在随着敏捷开发的流行，为了提高团队的交付能力，持续集成被越来越多的团队应用。
那么什么是持续集成呢？
简单来说就是频繁、持续的对于团队多个成员提交的代码进行集成（构建），并且给予反馈。一个典型的持续集成周期应该包括以下几个步骤：检查代码库是否有新的提交、获取代码、编译、单元测试、代码审查、部署、验证（自动化测试）
那为什么要做持续集成呢？
看过ThoughtWorks公司“熊节”的一次分享说：“持续集成是为了确保个人每天提交的代码不要给团队添乱”。都说“不怕神一样的对手，就怕...”。那么通过持续集成的频繁构建、实时反馈，让团队成员及时知道系统现在的状态，并能及时修复产生的问题。
那做好持续集成要具备什么基础设施？
第一是做好配置管理，包括代码、配置文件、构建脚本、数据库脚本。
第二是自动化测试，根据测试四象限（熊节PPT），把单元测试、组件测试、集成测试、功能验收测试按照分层策略实现自动化。
那么POP平台的持续集成是具体怎么实现的呢？
-使用了什么样的工具？
-面对不同的分支策略如何执行？
-都有哪些流程？
-设定了什么样的通过标准？
-如何反馈结果？
-不足与改进？
首先工具是 Jenkins + Maven + SonarQube + EAT测试框架。
Jenkins的角色是任务调度，maven来管理编译、打包、测试等软件生命周期，
SonarQube是个很好的代码审查平台，EAT测试框架很好的支持了分层自动化测试实现。
那么有的团队采用单分支策略，每次提交都会执行代码合并；而有的团队采用特性分支策略，代码合并的周期较长。虽然特性分支是持续集成所不推荐的，但是实际上还是很多团队需要这样做的。那么面对多分支策略目前有两种方法：一是创建一个伪主干，所有分支会及时合并到这里实现频繁集成的效果，二是只在主干上做持续集成，这样效果会有所打折，但是基本两三天集成一次的频率产生的风险也会明显小于上线前集中合并代码。
目前持续集成的流程是：获取代码、编译、单元测试、代码审查、部署、自动化测试。还根据执行测试的多少分为了提交构建和次级构建两种任务类型。提交构建因为每次提交代码都会执行，执行频率高、要求反馈快（小于15分钟），所以只执行增量的代码扫描和主要功能的自动化测试。而次级构建由于执行时间较长，可以设置为每天晚上执行，比如执行全量的代码扫描和针对页面开发的自动化测试用例。
目前因为单元测试失败率较高，所以除了单元测试没有设置通过标准以外，其他流程一旦达不到标准便会构建失败。代码审查的标准根据不同团队定制，自动化测试通过成功率来衡量，执行太慢的自动测试会定为失败用例，用例通过率不达标则构建失败。
反馈目前有两种方式，一种是通用的邮件反馈，一种是通过持续集成面板中的红、黄、绿三种状态来反馈。第二种更加直观，红色代表构建失败、黄色构建中、绿色构建成功。
大家都知道极限编程是很讲究纪律和规则的，那么持续集成这个实践除了工具、流程以外更加重要的是团队成员要养成遵守规则的习惯。一旦构建失败，就要停止开发新的代码，首先修复问题使构建成功。
经过敏捷教练杜伟忠和姜信宝的指导，POP研发的敏捷转型已经走出了第一步，各个团队的Scrum、Kanban都已经熟练的应用起来。那么做好工程实践正是我们持续学习，实现敏捷进化的体现。
希望在进化的过程中和大家多多沟通，关于持续集成具体的实践或工具使用可以联系POP平台测试团队。
（本资讯于2015-06-01首次发布）
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
