如何实现“持续集成”？闲鱼把研发效率翻了个翻

阿里妹导读：业务的快速发展，须要咱们更快速地响应，和更高质量产品的交付。如何从原来大(xiao)迭(pu)代(bu)的开发模式切换为精益开发模式？以 2-1-1（2周需求交付周期，1周需求开发周期，1小时集成时长）为愿景驱动改进，达到持续交付价值，响应业务要求成为咱们的目标。今天，闲鱼工程师琪钰为咱们分享：闲鱼是怎样朝着这一目标前进的？切换为精益开发模式后，又面临了哪些问题和挑战？

名词解释：精益开发模式，团队基于看板组织协做，以持续地交付需求为目标，需求按优先级，逐步进入开发、提测。因为在项目协做中，采用看板泳道来管理需求，所以在闲鱼，同窗们习惯称之为泳道模式。

一、咱们面临的要求和挑战

• 业务对交付响应时间要求愈来愈快。闲鱼业务正处于高速发展中，反摩尔定律告诉咱们，交付越迟，商品价值打折得就越厉害。速度为王，为了知足业务快速迭代和试错对技术团队可否快速交付需求提出了更大的挑战。
• 团队规模变大，项目沟通成本愈来愈高。随着闲鱼业务和技术的快速发展，交付的环境也愈来愈复杂，协做的角色愈来愈多。整个研发过程包含需求管理、开发、测试、发布、回归等关键活动，涉及aone（研发协做平台，主要是需求、bug管理等）、代码库、打包平台、自动化测试平台等多个系统，沟通协同的成本愈来愈高。
• 多分支并行开发增长额外成本。项目开发切换为精益开发模式最核心的改变就是各需求是独立的互不影响，能够分别独立进行测试和集成，保持主干的稳定，随时拉发布分支进行灰度发布。但多分支并行开发，也带来了新的问题，原来打包配置、手动打包、安装测试包等人工成本，都成倍的增长。
• 随时来的提测都可以测。以前客户端发布版本时间固定，批量开发、批量提测，测试介入比较晚。项目开发切换为精益开发模式对技术质量团队提出了更高的要求，面对多需求同时提测的状况，如何更快地响应测试。

因此，构建一个贯穿从需求到代码开发，再到测试整个过程的流程，并将其工具化、自动化就显得十分必要和紧迫，而持续集成就是这一流程的重要形式体现，构建一个高效的持续集成系统摆在咱们面前。这将必定程度下降开发过程当中的沟通成本，流程工具化，加速自动化。

如今针对服务端的集成发布有不少能够参考的实践，但对客户端的集成发布来讲，咱们依然面对以下难点。

二、客户端持续集成的难点

• 如何将研发过程当中各环节关联起来，一个需求从建立到发布的关键活动以下：建立需求->建立代码分支->建立打包项目->提交代码->打包->提交测试->修复->提交集成->发布

如何作到需求和代码分支关联，确保代码可追溯；

如何作到代码分支和打包项目关联，代码变动可自动触发打包；

如何作到代码范围和测试范围关联，确保测试回归范围。

• 多分支并行，如何有条不紊的进行集成。并行需求分支越多，意味着提交集成时，可能的冲突的几率就会越大。如何下降集成的冲突，以及集成后主干的稳定性，确保集成质量；
• 如何作到一提交代码就触发测试，测试进一步左移；
• 如何下降自动化测试的成本，提升测试效率；

而要解决上面的这些难点，缺乏一站式的工具平台支撑（集团内平台对服务端的发布有很好的支持，但对于客户端的集成发布来讲，涉及平台工具比较多）。

三、怎么作客户端持续集成

为了解决从需求建立到发布整个项目研发过程当中协同、构建、集成和测试等遇到的问题，提升团队的持续交付能力。针对客户端集成发布，咱们的总体方案的目标是首先是拉通整个需求交付流程中各个环节，简化持续交付工做，提供及时的质量反馈机制，让开发同窗关注在业务的开发；有效提升集成成功率及缩短集成发布周期，让版本可以按时上线你们可以按时下班；建设可视化、自动化、智能化的持续集成流水线，让业务需求真正的可持续交付。

空谈误国，实干兴邦。在谈论更多的改进以前，咱们先把基础本的流程经过工具先串起来，只有先看到总体，而后再发现问题逐步改进。

流程化

咱们的核心流程是这样的，一旦建立需求分支，交付通道就已创建，直到需求发布。

• 首先开发按照规范建立需求分支后，自动将分支和需求进行绑定，同时建立打包项目后，自动将需求和打包地址进行绑定，这样开发同窗一旦提交代码，就能够根据需求、代码提交内容等，给出影响范围，同时自动触发打包，开发和测试同窗不用再担忧最新的包中是否有刚提交的内容，每次变动都会触发打包；
• 打包成功后，根据 merge request、push 定时等不一样的触发方式，及分支类型，自动触发相应的测试件，进行一系列的自动化测试；
• 测试件执行完后，执行结果将被及时反馈出来，确保每次代码变动都是通过测试验证的，测试进一步左移，并将问题在团队项目协做看板上将问题标示出来，帮助团队在项目协做中可以持续的发现问题从而提升集成质量，下降发布风险，保证业务更快更顺畅的交付。

当完成了第一步，将整个流程打通以后，咱们发现，在整个流程中，依然有不少是依赖人工操做的地方，这是最容易出错，而且极低地影响效率的地方，对咱们来讲，这是改进的机会，因此，第二步咱们的重点就是作好无人化和自动化。

无人化

为了支撑持续集成流水线的运行，以无人化、自动化、可扩展为目标，及基于最小研发成本原则，咱们作得事情主要分为精益开发流程协同支撑无人化及测试验证自动化两部分。

fish CI 主要是研发流程支撑，如需求绑定、监听变动、触发打包、触发测试等，fish guard 主要测试件调度、执行，结果通知，及后续测试件接入扩展部分。目前已接入的测试件主要有 UI 遍历、UI 识别、monkey、单元测试等。后续计划按照分层测试的原则，接入更多的测试件，如代码静态扫描、weex 自动化测试、服务端测试件等，加强测试件覆盖度，拓展自动化测试边界。关于这一部分，咱们将在后面的文章中作更深刻的分享。

数据度量

管理学之父彼得德鲁克说：“若是你不能度量它，你就没法改进它”，其实也是咱们整个持续集成流水线的自检，咱们到底作得怎么样，持续交付的能力如何，咱们定义了以下指标用于后续统计。

指标主要分为响应能力、效率、质量三个维度，经过响应能力的这些指标，能够反应出打包变快了，质量反馈变快了，集成变快了，集成频率变高了；有效率的指标，反应出流水线工做的有效性，成功率越高说明流水线越稳定；最后质量，主要从代码质量和项目测试质量来度量，经过修改的文件数，模块分布能够反映出代码的拆分、依赖等状况；经过项目测试中 bug 的分布和库存，能够反映出项目质量状况，是否及时发现及时修复，是否达到发布标准等。

四、效果

闲鱼从3月中旬开始试运行精益开发模式（持续交付模式）到如今，闲鱼全部的业务需求所有走精益开发模式，咱们交付的速度，由一个月一个版本到两周一个版本。这离不开咱们在流水线各个环节中的改进，如打包变快了，需求分支构建次数愈来愈多，集成频率愈来愈高，以及自动化测试验证及时反馈集成质量状况。此外，闲鱼在精益开发模式下质量得到了明显提高，以下图所示：

绿色分割线左半部分，是以前未切换到泳道模式前的一个版本，bug 趋势看，前面编码阶段，测试基本未介入，大量的代码批量集成后集中测试，在缺陷充分被移除后，才能交付，没法持续交付。绿色分割线右半部分，是某个业务线的缺陷趋势图，小批量的持续集成、及时测试和发现问题、及时修复，能够快速持续交付。

五、总结与规划

简单总结下，咱们作的事情，第一步是拉通整个交付过程，有一个稳定的交付过程，第二步保证交付的效率，即响应变快了，集成变快了，质量反馈变快了，第三步持续交付，关键词是“持续地”，频次上提出了更高的要求，集成的频率变高了，之前一个月集成一次，如今天天都能集成，从一个月一次，到 nightly build，再到随时集成。即相比之前，让开发同窗“更”有信心集成一次变动并发布。

所以，咱们的终极目标就是7*24随时发布，没有发布窗口限制，真正作到交付流水线自动化无人化和全自动化测试，下降持续构建成本，拓展自动化测试边界。

---

本文做者：琪钰

阅读原文

本文来自云栖社区合做伙伴“阿里技术”，如需转载请联系原做者。