fir.im 持续集成技术实践

本文涉及的产品
性能测试 PTS,5000VUM额度
简介:

        

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

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

    

    持续集成做什么

    持续集成的概念出现在 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

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

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

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

    fir.im

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

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

    为什么要做本地集成

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

    如何做版本提交

    再说一个提交的问题,我们尽量保证每一次提交都是一个完整的提交,也就是原子提交。

    

当代码变动你想创建提交时,这个提交应该尽可能的小量,并且包含一个不可分割的特性(feature)、修复(fix)或优化(improved)。

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

    持续集成系统

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

    fir.im

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

    fir.im

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

    fir.im 的敏捷环境

    fir.im 是一个内测分发平台,我们也做了一个持续集成 CI 产品-flow.ci。先来看一下我们正在使用的敏捷环境:
fir.im

  • Trello 看板;

  • 三个环境(类生产环境,测试环境,生产环境);

  • CI 工具(Jenkins/flow.ci)

    说一下 Git 分支管理

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

    fir.im

    多分支如何做频繁地持续集成?

    master 分支,即线上分支。线上通常会有一些 hotfix, 任何产品都不可能避免线上的 bug ,这些 bug 需要在 master 分支进行修复,修复完成后持续集成系统会告知已上线,收到团队反馈,这些代码会要求更新在 develop 分支上,之后所有团队也会收到相关通知,那么 feature 分支会有变化吗?答案是肯定的,因为频繁的集成可以防止代码偏离。这就是我们多分支构建的策略。
fir.im
还有一个策略——不同的分支不同的构建,持续集成系统跑完整个流程会很长,所以在 feature 分支频繁度会比在本地构建要高一些,但是也没有那么高。为了保证持续集成系统能快速地收到反馈,需要在 feature 分支上做一些定制的 workflow ,所以我们做了代码静态分析和单元测试。

    当 feature 分支的 card 做完之后(scrum 中 done 的含义是指测试验收完毕),集成到 develop 分支,develop 分支会自动部署到测试环境,会跑一个整个自动化测试集,为什么是这样的构建策略呢?

    

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

    整个团队的构建频率可以看下这张图:
fir.im
本地集成的频率非常高,远程构建对应的是 feature 分支,会相对低一下。QA 环境对应的是 develop 分支的构建粒度。这样的构建每天都会产生,所以做完之后不要积压,一定要保持上线节奏。
fir.im
kanban + scrum 结合的方式构成我们每日构建,这是一个整体的构建策略和上线频率。

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

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

  • 最初阶段:提交代码-自动部署;

  • 一般进阶:提交代码-代码静态分析-自动部署,最简单先再加入代码静态分析;

  • 高级进阶:提交代码-代码静态分析-自动化测试集-自动部署;
    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 做验收测试最核心的价值。
fir.im
其实,持续集成是一个工作流,当 push 代码的时候才会 run 起来,但是 flow.ci 本身系统也有外部依赖的特殊性,会依赖一些第三方的 sevice(比如 GitHub/GitLab 等),验收测试应该一直保持不断地运行,也可以叫持续测试吧。因为我们永远不能保证第三方的 api 会不会改变:)

    Step 4. 性能测试

    我们的性能测试做的比较简单,主要测试 api.因为 fir.im 做 app 的内测分发,我们需要性能测试保证 app 上传下载的正常稳定。性能测试是单用户的,压力测试是多用户的,这是两者之间的区别。

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

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

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

    fir.im

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

    fir.im

本文转自帅气的头头博客51CTO博客,原文链接http://blog.51cto.com/12902932/1924585如需转载请自行联系原作者


sshpp

相关文章
|
26天前
|
运维 Devops jenkins
DevOps实践:自动化部署与持续集成的实现之旅
本文旨在通过一个实际案例,向读者展示如何将DevOps理念融入日常工作中,实现自动化部署和持续集成。我们将从DevOps的基础概念出发,逐步深入到工具的选择、环境的搭建,以及流程的优化,最终实现一个简单而高效的自动化部署流程。文章不仅提供代码示例,更注重于实践中的思考和问题解决,帮助团队提高软件开发和运维的效率。
|
19天前
|
运维 监控 Devops
DevOps实践:自动化部署与持续集成的融合之旅
【10月更文挑战第7天】在软件开发领域,DevOps已成为一种文化和实践,它倡导开发(Dev)与运维(Ops)之间的协作与整合。本文将引导读者了解如何通过自动化部署和持续集成(CI)的实践来提升软件交付的速度和质量。我们将探讨一些实用的工具和技术,以及它们是如何帮助团队高效地管理代码变更、测试和部署的。文章将不包含代码示例,但会详细解释概念和流程,确保内容的通俗易懂和条理性。
124 62
|
19天前
|
运维 监控 Devops
DevOps实践:持续集成与部署的自动化之旅
【10月更文挑战第7天】在软件开发领域,DevOps已成为提升效率、加速交付和确保质量的关键策略。本文将深入探讨如何通过实施持续集成(CI)和持续部署(CD)来自动化开发流程,从而优化运维工作。我们将从基础概念入手,逐步过渡到实际操作,包括工具选择、流程设计以及监控和反馈机制的建立。最终,我们不仅会展示如何实现这一自动化流程,还会讨论如何克服常见的挑战,以确保成功实施。
55 9
|
2月前
|
Devops jenkins 测试技术
DevOps实践:持续集成与自动化测试的融合之道
【9月更文挑战第29天】在软件开发的快节奏竞赛中,DevOps如同一位智慧的舵手,引领着船只驶向效率与质量的彼岸。本文将揭开DevOps的神秘面纱,探索其核心理念如何通过持续集成(CI)和自动化测试的实践,实现软件开发流程的优化与加速。我们将一同见证代码从构思到部署的旅程,以及这一过程中的关键技术和工具如何协同工作,确保软件质量和交付速度的双重提升。
|
2月前
|
Devops jenkins Java
DevOps实践:持续集成和部署的自动化之旅
【9月更文挑战第20天】在软件开发的世界里,速度和质量是至关重要的。本文将带领读者踏上一场自动化之旅,深入探索DevOps文化中的两大支柱——持续集成(CI)和持续部署(CD)。我们将通过一个实际的案例,展示如何利用现代工具和技术实现代码从编写到部署的无缝转换,确保软件交付的高效性和可靠性。准备好让你的开发流程变得更加流畅和高效了吗?让我们开始吧!
|
2月前
|
运维 监控 Devops
拥抱 DevOps 文化:实现持续交付与部署的最佳实践
在软件开发领域,DevOps 强调开发与运维团队的协作,通过自动化、持续集成与部署等实践缩短系统开发生命周期,提升软件质量。其核心原则包括自动化、协作、度量与共享责任。实施 DevOps 需要建立跨功能团队、采用版本控制、持续集成与部署、自动化测试及监控反馈。常用工具有 Jenkins、GitLab CI/CD、Ansible、Prometheus 和 ELK Stack 等。DevOps 通过文化与技术变革,加速软件交付并提高客户满意度。
|
1月前
|
运维 Devops 测试技术
DevOps实践之路:从持续集成到自动化部署
【9月更文挑战第33天】在软件开发的海洋中,DevOps如同一艘航船,承载着敏捷开发与运维之间的桥梁。本文将带你领略DevOps的魅力,从持续集成的理念出发,穿越自动化测试的浪潮,直至自动化部署的港湾。我们将通过实际案例,探索如何构建一个高效、可靠的DevOps流程,让软件交付不再是梦魇,而是流畅的艺术。
|
2月前
|
运维 Cloud Native Devops
云原生时代的DevOps实践:自动化、持续集成与持续部署
【9月更文挑战第3天】未来,随着人工智能、大数据等技术的不断融入,DevOps实践将更加智能化和自动化。我们将看到更多创新的技术和工具涌现出来,为软件开发和运维带来更多便利和效益。同时,跨团队协作和集成也将得到进一步加强,推动软件开发向更加高效、可靠和灵活的方向发展。
|
4月前
|
监控 Devops 测试技术
DevOps实践:从持续集成到自动化部署的旅程
【7月更文挑战第31天】在软件开发领域,DevOps已经成为一种文化和实践,旨在通过改进开发和运维之间的协作,来加速软件交付和提高质量。本文将深入探讨DevOps的核心概念,包括持续集成(CI)、持续交付(CD)以及自动化部署,并分享实施这些实践的具体步骤和技巧,帮助读者构建更加高效、可靠的软件发布流程。
87 1
|
4月前
|
运维 Devops jenkins
DevOps实践之路:从自动化部署到持续交付
【7月更文挑战第16天】在当今快速迭代的软件生命周期中,DevOps已经成为提升效率、缩短产品上市时间的关键因素。本文将深入探讨DevOps的核心理念与实践,特别是如何通过自动化工具实现代码的持续集成和部署,以及如何构建有效的持续交付流程。我们将从理论出发,结合实际案例分析,为读者提供一套完整的DevOps落地方案。