互联网时代，人人都在追求产品的快速响应、快速迭代和快速验证。不论是创业团队还是大中型企业，都在探索属于自己的敏捷开发、持续交付之道。fir.im 团队也在全面实施敏捷，并推出新持续集成服务— flow.ci ，以帮助企业将开发测试流程自动化，更快速地交付产品。
这篇文章将以我们实际开发为例，从敏捷方法论的角度来讲解 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 就无法交付质量足够好的软件！
欢迎分享你的观点。
_
P.S.想要现场 slide 的同学，请扫码下图关注公众号flow_ci，并回复关键词「ci实践」即可获得 :)