fir.im 持续集成技术实践

互联网时代，人人都在追求产品的快速响应、快速迭代和快速验证。不管是创业团队仍是大中型企业，都在探索属于本身的敏捷开发、持续交付之道。fir.im 团队也在全面实施敏捷，并推出新持续集成服务
— flow.ci ，以帮助企业将开发测试流程自动化，更快速地交付产品。

4月15日，fir.im CTO 郭扬在“光环国际·2017敏捷春季峰会”带来了《敏捷工程实践的基石——持续集成》的技术实践，从敏捷方法论的角度分享了持续集成流程的质量实践与 fir.im 团队的 CI 技术实践。演讲实录整理以下，但愿能带给你一些思考。

郭扬，fir.im CTO，曾就任于奔驰戴姆勒创新实验室，Thoughtworks，索尼移动通讯，网易等公司，担任 DevLead，负责组建技术团队，管理项目进度与项目风险，软件及 DevOps 的架构设计、高并发条件下的性能调优、敏捷教练等工做。

持续集成作什么

持续集成的概念出如今 2001 年，它实际上是一个 XP 极限编程的工程实践。那么持续的是什么，集成是什么呢，很是简单就是“一直不停地集成代码”。

持续集成是把代码频繁的合并到主干，经过自动构建的方式验证软件的质量，让团队快速的响应质量，快速的修复问题，快速的给客户解决问题，快速地交付更好的软件质量。

咱们为何要作持续集成

开发人员对下面的软件开发场景很熟悉，好比：

• 场景一：开发了新功能，老功能产生新的 bug；
• 场景二：修好一个 bug，又产生其余 bug，甚至出现连环 bug；
• 场景三：出现的 bug 比较多，修改代码要很谨慎，不熟悉的模块通常不敢动，怕引发问题；

持续集成是如何缓解这个问题，Martin Fowler 大师曾经说过：

“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.” — Martin Fowler

如上面所说，持续集成不能消除 bug ,但能更容易地发现 bug,更快速地修复，提高产品质量。那么，持续集成能给咱们带来哪些价值？

从这张图上能够看到，持续集成造成一个完美的闭环。经过持续的集成进行不断地检查、调整，同时，项目的透明性也获得了最大的体现。

fir.im 如何进行持续集成实践

这是一个常见的持续集成流水线：

在平常的开发过程当中，程序员在本地提交代码，持续集成流水线要求先作一次本地集成，在本地进行验证后提交到源代码管理仓库中，以后源代码工具会发出 webhook 触发到持续集成系统中。当构建/测试完成后，会及时经过钉钉或邮件通知团队（测试/研发/boss/产品经理）集成状态，产品经理或项目经理收到通知后会在测试环境作验收测试，这是一个比较完美的反馈环。

假如测试经过验收完毕后，持续集成系统会自动触发部署到类生产环节或测试环境，或由专人手动部署到生产环境。

为何要作本地集成

首先，代码在远程进行管理，每一个人都会提交代码，远程的代码仓库会产生变化，因此在本地集成的时候要求进行代码合并，以避免出现分支冲突和代码冲突。其次，不要依赖于持续集成系统给你结果，可能须要 30 分钟的时间，不要让开发人员等待，必定要先作本地集成。

如何作版本提交

再说一个提交的问题，咱们尽可能保证每一次提交都是一个完整的提交，也就是原子提交。

当代码变更你想建立提交时，这个提交应该尽量的小量，而且包含一个不可分割的特性（feature）、修复（fix）或优化（improved）。

拿每一个产品开发都会遇到的 login 功能开发举例，当填完的用户名和密码传到数据库，作完验证后给用户返回一个结果。那什么是一个原子提交？好比，提交验证一个用户名，这是一个完整的 feature ；验证密码是否符合格式（6位/8位），这也是一个完整的 feature ；当我验证完用户名和密码后再传到数据库以后，查询正确与否，这也是一个完整的 feature ；保证每次提交是一个完整的 feature 或修复了一个 bug，不要代码写成半截。

持续集成系统

这里讲的是狭义的持续集成系统，一般的 CI 系统收到提交以后会触发构建，构建会有信息返回好比 commit id 、commit 信息、代码变动等，收到代码提交后会触发自动构建，接着安装依赖进行编译，并触发质量保证流程，也就是说自动化测试集。

自动化测试集包括代码静态检查－单元测试－集成测试－验收测试－性能测试，也会有压力测试、回归测试、monkey test等等一系列的测试。

接下来，咱们具体讲一下 fir.im 团队如何进行持续集成实践的。

fir.im 的敏捷环境

fir.im 是一个内测分发平台，咱们也作了一个持续集成 CI 产品－flow.ci。先来看一下咱们正在使用的敏捷环境：

• Trello 看板;
• 三个环境（类生产环境，测试环境，生产环境）;
• CI 工具（Jenkins/flow.ci）

说一下 Git 分支管理

咱们在应用 3 个分支 —— master／develop／feature 分支，对 feature 命名会有一些要求，持续集成系统必定会反馈到 trello 的 kanban 里，因此对于 feature 分支咱们也有这样的命名 feature/fci-{card number} 以方便区分。

多分支如何作频繁地持续集成？

master 分支，即线上分支。线上一般会有一些 hotfix, 任何产品都不可能避免线上的 bug ,这些 bug 须要在 master 分支进行修复，修复完成后持续集成系统会告知已上线，收到团队反馈，这些代码会要求更新在 develop 分支上，以后全部团队也会收到相关通知，那么 feature 分支会有变化吗？答案是确定的，由于频繁的集成能够防止代码偏离。这就是咱们多分支构建的策略。

还有一个策略——不一样的分支不一样的构建，持续集成系统跑完整个流程会很长，因此在 feature 分支频繁度会比在本地构建要高一些，可是也没有那么高。为了保证持续集成系统能快速地收到反馈，须要在 feature 分支上作一些定制的 workflow ,因此咱们作了代码静态分析和单元测试。

当 feature 分支的 card 作完以后（scrum 中 done 的含义是指测试验收完毕），集成到 develop 分支，develop 分支会自动部署到测试环境，会跑一个整个自动化测试集，为何是这样的构建策略呢？

咱们会作代码 review ，当 feature 分支提 pr 到 develop 分支上，这样 develop 分支的构建条件是：当收到 pr 以后，开始跑持续集成。假如部署完成整个测试跑过了产品经理验收以后，没毛病了，终于能够发布了到 master 分支。

整个团队的构建频率能够看下这张图：

本地集成的频率很是高，远程构建对应的是 feature 分支，会相对低一下。QA 环境对应的是 develop 分支的构建粒度。这样的构建天天都会产生，因此作完以后不要积压，必定要保持上线节奏。

kanban + scrum 结合的方式构成咱们每日构建，这是一个总体的构建策略和上线频率。

fir.im 的持续集成系统演变过程

罗马不是一天建成的，持续集成不是一开始就是完美的，每一个开发者心中都有一个比较理想的自动化工做流——持续部署，大概会经历这几个演变阶段：

• 最初阶段：提交代码－自动部署；
• 通常进阶：提交代码－代码静态分析－自动部署，最简单先再加入代码静态分析；
• 高级进阶：提交代码－代码静态分析－自动化测试集－自动部署；
  

这是咱们在用的自动化测试集，下面分别说下静态检查分析、单元测试、验收测试、性能测试的具体用途。

Step 1. 静态代码分析

每一个公司都会有本身的代码规范，代码静态分析工具可以保证代码质量，现成的工具备 java 的 FindBugs，ruby 的 rubocop 等。利用代码检查工具能够帮助团队发现可重构的地方，输出产出 – HTML 报告，也会发现潜在 bug；有的代码检查工具还会检查出一些安全漏洞。

这三点是代码静态分析最重要的做用。这里也分享一个 GitHub 地址，列出一些主流语言的代码分析工具，能够参考一下。

Step 2. “单元测试”

这里的 “单元测试”也加上了集成测试，毕竟创业公司要求资源最大化。程序员必定要写单元测试，要克服开发的惯性思惟，不要甩锅。下面有一些注意的点和你们分享：

• 测试异常——不只仅测试正确状况，也要主动测试异常；
• 减小耦合——保证独立的可测试性；
• 功能分离——单元测试流太长，超过 20 分钟的话要详细想一下如何将功能单独拆开，效率更高；
• 测试＝需求——从测试代码看到每一个 class 是干什么的，同时出现 bug 时，第一时间是看测试，想一想如何从测试中复现；

Step 3. 验收测试

验收测试是端对端的测试，从收到用户名密码到返回结果，是否是咱们所指望的一个值，这是验收 Acceptance Test，实际上是验收了整个功能。代码静态检查和单元测试，保证了咱们如何怎么去写代码，验收测试保证了写正确代码，符合开发需求。

flow.ci 作验收测试比较多，用的是比较流行的框架 Cucumber + Selenium WebDriver，目前支持 3 种数据库，5 种 git 仓库，7 种 开发语言跑在 docker 容器云上，支持 iOS 构建跑在 mac 机器上，要保证这些排列组合正常运行，这是 flow.ci 作验收测试最核心的价值。

其实，持续集成是一个工做流，当 push 代码的时候才会 run 起来，可是 flow.ci 自己系统也有外部依赖的特殊性，会依赖一些第三方的 sevice（好比 GitHub/GitLab 等），验收测试应该一直保持不断地运行，也能够叫持续测试吧。由于咱们永远不能保证第三方的 api 会不会改变:)

Step 4. 性能测试

咱们的性能测试作的比较简单，主要测试 api.由于 fir.im 作 app 的内测分发，咱们须要性能测试保证 app 上传下载的正常稳定。性能测试是单用户的，压力测试是多用户的，这是二者之间的区别。

性能测试会有一些不肯定性，有不少系统会产生缓存。flow.ci 的性能测试跑在 docker 上，是一个干净独立的环境，须要让系统预热运行一下。Locust/JMeter/LoadRunner是目前比较流行的性能测试工具。
flow.ci 目前用的是 locust,能够参考一下。

持续集成的可视化、数据分析

咱们认为一个好的持续集成系统也要作到项目进度的透明化，最传统的方式是发送相关的邮件，但实质上有几我的去看呢？为此咱们采购了一个大的屏幕来解决这个问题，用来时刻提醒团队的某个构建结果。固然也能够用闪烁灯或音频的方式。

说到数据统计分析，整个 ci 流程跑下来产生的不少数据也很是有挖掘的价值。好比，对于代码静态分析有多少 Offence、Risk、Bug，对于单元测试有失败率、测试覆盖率；对于验收测试或性能测试有多少的失败率，这些数据都有可能成为衡量一个程序员的标准。

结语

CI 就像盖楼房的脚手架同样，没有脚手架就没办法盖出一个足够高的楼，没有 CI 就没法交付质量足够好的软件！

欢迎分享你的观点。