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

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

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

1、我们面临的要求和挑战

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

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

现在针对服务端的集成发布有很多可以参考的实践，但对客户端的集成发布来说，我们依然面对如下难点。

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

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

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

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

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

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

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

3、怎么做客户端持续集成

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

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

流程化

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

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

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

无人化

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

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

数据度量

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

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

4、效果

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

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

5、总结与规划

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

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

原文链接
本文为云栖社区原创内容，未经允许不得转载。