干货分享——POP研发持续集成实践

持续集成是源于极限编程的实践，现在随着敏捷开发的流行，为了提高团队的交付能力，持续集成被越来越多的团队应用。

那么什么是持续集成呢？简单来说就是频繁、持续的对于团队多个成员提交的代码进行集成（构建），并且给予反馈。一个典型的持续集成周期应该包括以下几个步骤：检查代码库是否有新的提交、获取代码、编译、单元测试、代码审查、部署、验证（自动化测试）。

那为什么要做持续集成呢？看过ThoughtWorks公司“熊节”的一次分享说：“持续集成是为了确保个人每天提交的代码不要给团队添乱”。都说“不怕神一样的对手，就怕猪一样的队友”。那么通过持续集成的频繁构建、实时反馈，让团队成员及时知道系统现在的状态，并能及时修复产生的问题。

那做好持续集成要具备什么基础设施？ 第一是做好配置管理，包括代码、配置文件、构建脚本、数据库脚本。 第二是自动化测试，根据测试四象限，把单元测试、组件测试、集成测试、功能验收测试按照分层策略实现自动化。

那么POP平台的持续集成是具体怎么实现的呢？

• 使用了什么样的工具？
• 面对不同的分支策略如何执行？
• 都有哪些流程？
• 设定了什么样的通过标准？
• 如何反馈结果？
• 不足与改进？

首先工具是 Jenkins + Maven + SonarQube + EAT测试框架。

enkins的角色是任务调度，maven来管理编译、打包、测试等软件生命周期， SonarQube是个很好的代码审查平台，EAT测试框架很好的支持了分层自动化测试实现。

那么有的团队采用单分支策略，每次提交都会执行代码合并；而有的团队采用特性分支策略，代码合并的周期较长。虽然特性分支是持续集成所不推荐的，但是实际上还是很多团队需要这样做的。那么面对多分支策略目前有两种方法：一是创建一个伪主干，所有分支会及时合并到这里实现频繁集成的效果，二是只在主干上做持续集成，这样效果会有所打折，但是基本两三天集成一次的频率产生的风险也会明显小于上线前集中合并代码。

目前持续集成的流程是：获取代码、编译、单元测试、代码审查、部署、自动化测试。还根据执行测试的多少分为了提交构建和次级构建两种任务类型。提交构建因为每次提交代码都会执行，执行频率高、要求反馈快（小于15分钟），所以只执行增量的代码扫描和主要功能的自动化测试。而次级构建由于执行时间较长，可以设置为每天晚上执行，比如执行全量的代码扫描和针对页面开发的自动化测试用例。

目前因为单元测试失败率较高，所以除了单元测试没有设置通过标准以外，其他流程一旦达不到标准便会构建失败。代码审查的标准根据不同团队定制，自动化测试通过成功率来衡量，执行太慢的自动测试会定为失败用例，用例通过率不达标则构建失败。

反馈目前有两种方式，一种是通用的邮件反馈，一种是通过持续集成面板中的红、黄、绿三种状态来反馈。第二种更加直观，红色代表构建失败、黄色构建中、绿色构建成功。

大家都知道极限编程是很讲究纪律和规则的，那么持续集成这个实践除了工具、流程以外更加重要的是团队成员要养成遵守规则的习惯。一旦构建失败，就要停止开发新的代码，首先修复问题使构建成功。

那么持续集成有什么作用？

首先是代码质量的提升，通过借助工具（SonarQube）把代码审查纳入到CI过程中，促使开发人员每次提交后都能够及时反馈代码质量情况。通过频繁的集成和代码审查，在确保新增代码质量的情况下，逐渐通过重构和增加测试来提高遗留代码的质量。坚持下来，获得的成绩是显而易见的。

另外对于研发效率的提升是通过以下两方面来获得提升的：一是保持稳定的测试环境，开发提交的变更总是第一时间通过CI来检验是否能够正常编译、构建和部署，及时反馈问题，及时修改，大大减少了以往测试环境的调试时间；二是通过大量的自动化回归测试频繁执行来保证系统核心功能点时刻能够正常运行，大大节省了手工测试人员的工作量。就拿POP研发中实施持续集成较早的【京麦团队】来说，已经具备了很强的交付能力。

经过敏捷教练杜伟忠和姜信宝的指导，POP研发的敏捷转型已经走出了第一步，各个团队的Scrum、Kanban都已经熟练的应用起来。那么做好工程实践正是我们持续学习，实现敏捷进化的体现。 在持续推进POP持续集成的过程中，POP平台测试团队与各个POP产品线的童鞋一起在基础平台搭建和实践落地方面积累了一些经验，也踩过了一些坑。 希望在持续改进的过程中和大家多多沟通，关于持续集成相关的实践后面陆续分享给大家。