fir.im持续集成技术实践
互联网时代,人人都在追求产品的快速响应、快速迭代和快速验证。不论是创业团队还是大中型企业,都在探索属于自己的敏捷开发、持续交付之道。fir.im 团队也在全面实施敏捷,并推出新持续集成服务 — flow.ci ,以帮助企业将开发测试流程自动化,更快速地交付产品。 这篇文章将以实际开发为例,从敏捷方法论的角度来讲解 CI 技术实践与演变过程,大概分为三个部分,希望带给你一些参考。
持续集成做什么
持续集成的概念出现在 2001 年,它其实是一个 XP 极限编程的工程实践。那么持续的是什么,集成是什么呢,非常简单就是“一直不停地集成代码”。
持续集成是把代码频繁的合并到主干,通过自动构建的方式验证软件的质量,让团队快速的响应质量,快速的修复问题,快速的给客户解决问题,快速地交付更好的软件质量。
我们为什么要做持续集成
开发人员对下面的软件开发场景很熟悉,比如:
- 场景一:开发了新功能,老功能产生新的 bug;
- 场景二:修好一个 bug,又产生其他 bug,甚至出现连环 bug;
- 场景三:出现的 bug 比较多,修改代码要很谨慎,不熟悉的模块一般不敢动,怕引起问题;
如上面所说,持续集成不能消除 bug ,但能更容易地发现 bug,更快速地修复,提升产品质量。那么,持续集成能给我们带来哪些价值?[attach]1818[/attach]从这张图上可以看到,持续集成形成一个完美的闭环。通过持续的集成进行不断地检查、调整,同时,项目的透明性也得到了最大的体现。fir.im 如何进行持续集成实践这是一个常见的持续集成流水线:[attach]1819[/attach]在日常的开发过程中,程序员在本地提交代码,持续集成流水线要求先做一次本地集成,在本地进行验证后提交到源代码管理仓库中,之后源代码工具会发出 webhook 触发到持续集成系统中。当构建/测试完成后,会及时通过钉钉或邮件通知团队(测试/研发/boss/产品经理)集成状态,产品经理或项目经理收到通知后会在测试环境做验收测试,这是一个比较完美的反馈环。假如测试通过验收完毕后,持续集成系统会自动触发部署到类生产环节或测试环境,或由专人手动部署到生产环境。为什么要做本地集成首先,代码在远程进行管理,每个人都会提交代码,远程的代码仓库会产生变化,所以在本地集成的时候要求进行代码合并,以免出现分支冲突和代码冲突。其次,不要依赖于持续集成系统给你结果,可能需要 30 分钟的时间,不要让开发人员等待,一定要先做本地集成。如何做版本提交再说一个提交的问题,我们尽量保证每一次提交都是一个完整的提交,也就是原子提交。“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.” — Martin Fowler
拿每个产品开发都会遇到的 login 功能开发举例,当填完的用户名和密码传到数据库,做完验证后给用户返回一个结果。那什么是一个原子提交?比如,提交验证一个用户名,这是一个完整的 feature ;验证密码是否符合格式(6位/8位),这也是一个完整的 feature ;当我验证完用户名和密码后再传到数据库之后,查询正确与否,这也是一个完整的 feature ;保证每次提交是一个完整的 feature 或修复了一个 bug,不要代码写成半截。持续集成系统这里讲的是狭义的持续集成系统,通常的 CI 系统收到提交之后会触发构建,构建会有信息返回比如 commit id 、commit 信息、代码变更等,收到代码提交后会触发自动构建,接着安装依赖进行编译,并触发质量保证流程,也就是说自动化测试集。[attach]1820[/attach]自动化测试集包括代码静态检查-单元测试-集成测试-验收测试-性能测试,也会有压力测试、回归测试、monkey test等等一系列的测试。[attach]1821[/attach]接下来,我们具体讲一下 fir.im 团队如何进行持续集成实践的。fir.im 的敏捷环境fir.im 是一个内测分发平台,我们也做了一个持续集成 CI 产品-flow.ci。先来看一下我们正在使用的敏捷环境:[attach]1822[/attach]当代码变动你想创建提交时,这个提交应该尽可能的小量,并且包含一个不可分割的特性(feature)、修复(fix)或优化(improved)。
- Trello 看板;
- 三个环境(类生产环境,测试环境,生产环境);
- CI 工具(Jenkins/flow.ci)
整个团队的构建频率可以看下这张图:[attach]1825[/attach]本地集成的频率非常高,远程构建对应的是 feature 分支,会相对低一下。QA 环境对应的是 develop 分支的构建粒度。这样的构建每天都会产生,所以做完之后不要积压,一定要保持上线节奏。[attach]1826[/attach]kanban + scrum 结合的方式构成我们每日构建,这是一个整体的构建策略和上线频率。fir.im 的持续集成系统演变过程罗马不是一天建成的,持续集成不是一开始就是完美的,每个开发者心中都有一个比较理想的自动化工作流——持续部署,大概会经历这几个演变阶段:我们会做代码 review ,当 feature 分支提 pr 到 develop 分支上,这样 develop 分支的构建条件是:当收到 pr 之后,开始跑持续集成。假如部署完成整个测试跑过了产品经理验收之后,没毛病了,终于可以发布了到 master 分支。
- 最初阶段:提交代码-自动部署;
- 一般进阶:提交代码-代码静态分析-自动部署,最简单先再加入代码静态分析;
- 高级进阶:提交代码-代码静态分析-自动化测试集-自动部署;
- 测试异常——不仅仅测试正确情况,也要主动测试异常;
- 减少耦合——保证独立的可测试性;
- 功能分离——单元测试流太长,超过 20 分钟的话要详细想一下如何将功能单独拆开,效率更高;
- 测试=需求——从测试代码看到每个 class 是干什么的,同时出现 bug 时,第一时间是看测试,想想如何从测试中复现;