fir.im 持续集成技术实施

互联网时代,人人都在追求产品的神速响应、急速迭代和飞跃验证。不论是创业团队或者大中型公司,都在啄磨属于自己的急忙开发、持续交付之道。fir.im
团队也在周全实施敏捷,并盛产新持续集成服务—
flow.ci
,以赞助公司将开发测试流程自动化,更高速地交给产品。

12月一来,春季忧心忡忡而至。近来,flow.ci
带来了那个新的法力优化,帮您越是简化开发工作流。一起来看看这一个关键:

6月15日,fir.im CTO
郭扬在“光环国际·2017敏捷春天峰会”带来了《敏捷工程执行的木本——持续集成》的技巧实施,从便捷方法论的角度分享了不止集成流程的身分实践与
fir.im 团队的 CI 技术实施。解说实录整理如下,希望能带给您有的心想。

  • ##### 支持 iOS 项目 Xcode8.3 构建

fir.im

iOSer 们根本来了,flow.ci 已扶助最新的 Xcode8.3
版本举行构建,选用版本时直接选取 Xcode8 即可 🙂

郭扬,fir.im
CTO,曾就职于迈凯伦DAIMLER立异实验室,Thoughtworks,Sony移动通信,新浪等店铺,担任
DevLead,负责组建技术团队,管理项目进度与项目风险,软件及 DevOps
的架构设计、高并发条件下的属性调优、敏捷教练等工作。

  • ##### 援助 Git 仓库的缓存

频频集成做哪些

没完没了集成的概念出现在 2001 年,它其实是一个 XP
极限编程的工程实践。那么持续的是什么样,集成是什么样吗,分外简单就是“平昔不停地融为一体代码”。

穿梭集成是把代码频繁的统一到骨干,通过活动构建的法门注脚软件的质地,让协会快速的响应质地,飞速的修补问题,神速的给客户解决问题,神速地交给更好的软件质料。

构建工作流到 Git Clone 这一步,打开 flow_cache_repo 按钮,可径直缓存
git 仓库,缩小下载时间。

大家为啥要做持续集成

开发人士对下面的软件开发场景很熟悉,比如:

  • 此情此景一:开发了新功能,老成效发生新的 bug;
  • 意况二:修好一个 bug,又暴发任何 bug,甚至出现连环 bug;
  • 场景三:出现的 bug
    相比较多,修改代码要很小心,不熟练的模块一般不敢动,怕引起问题;

没完没了集成是何等解决这么些题材,马丁(Martin) 福勒 大师曾经说过:

“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

从这张图上得以见到,持续集成形成一个圆满的闭环。通过不停的购并举行连发地反省、调整,同时,项目标透明性也赢得了最大的反映。

  • ##### 构建形成后,可直接在 flow.ci 扫码下载使用

fir.im 怎么样开展不断集成实践

这是一个广阔的不停集成流水线:

fir.im

在普通的支出进程中,程序员在该地提交代码,持续集成流水线要求先做几次地点集成,在位置开展表明后交付到源代码管理仓库中,之后源代码工具会暴发webhook
触发到持续集成系统中。当构建/测试成功后,会立马通过钉钉或邮件通告团队(测试/研发/boss/产品主管)集成状态,产品经营或项目老总收到通告后会在测试环境做验收测试,那是一个相比较完美的反馈环。

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

iOS 与 Android 项目,在工作流中添加 fir.im 上传插件,配置好 Token,
changelog 等音讯。成功构建后,可一直在 flow.ci
构建结果页面扫码下载安装进行测试,不需要登录到 fir.im, 体验更通畅。
(P.S.这只是大旨的产物存储,后续会不停优化)

为什么要做地方集成

率先,代码在中远距离举行管制,每个人都会交到代码,远程的代码仓库会时有发生变化,所以在本土集成的时候要求举行代码合并,以免出现分支冲突和代码顶牛。其次,不要借助于无休止集成系统给你结果,可能需要
30 分钟的年华,不要让开发人士等待,一定要先做当地集成。

flow.ci

如何做版本提交

再说一个交给的题材,我们尽量确保每五回提交都是一个完整的提交,也就是原子提交。

当代码变动你想创立提交时,这些提交相应尽量的为数不多,并且包含一个不可分割的风味(feature)、修复(fix)或优化(improved)。

拿每个产品开发都会赶上的 login
功用开发举例,当填完的用户名和密码传到数据库,做完验证后给用户再次回到一个结果。这咋样是一个原子提交?比如,提交认证一个用户名,这是一个完完全全的
feature ;验证密码是否吻合格式(6位/8位),这也是一个一体化的 feature
;当自身表明完用户名和密码后再盛传数据库之后,查询正确与否,这也是一个完好的
feature ;保证每趟提交是一个完好的 feature 或修复了一个
bug,不要代码写成半截。

再来看看这期 CI Weekly,整理了软件开发模型对照分析、持续集成 Web
实践、知乎客户端的测试与持续集成、Docker 的实施故事小文、基于 Docker
的CI/CD、DevOps 开源工具等技巧分享,一起来看望~

不止集成系统

那里讲的是狭义的无休止集成系统,平时的 CI
系统接到提交之后会触发构建,构建会有音信重返比如 commit id 、commit
信息、代码变更等,收到代码提交后会触发自动构建,接着安装倚重举行编译,并触及质料担保流程,也就是说自动化测试集。

fir.im

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

fir.im

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

软件开发模型与经过改进

软件开发模型直接影响软件开发的周期和软件质量,是软件开发的集团管制格局。
本文介绍了软件工程中开发模型,包括沃特(Wat)erFall模型、螺旋模型、增量模型、RUP(Rational
Unified Process)、XP极限编程、Scrum、边做边改模型(Build and Fix
Model)等等,来看看哪些从中选用符合你的团队的开支模型。(via:虎扑@PetterLiu

fir.im 的敏捷环境

fir.im 是一个内测分发平台,大家也做了一个相接集成 CI
产品-flow.ci。先来看一下我们正在接纳的很快环境:

fir.im

  • Trello 看板;
  • 三个条件(类生产环境,测试环境,生产环境);
  • CI
    工具(Jenkins/flow.ci

乐乎客户端测试团队转型实践

这篇著作讲解了乐乎客户端测试团队经历的付出、测试团队的转型实践,从分析测试团队现状到生产力改进、团队人才建设等等,一起探访作者咋样引导团队拓展转型。(via:运动支付前线@李乐)

说一下 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
结合的方法结合我们每一天构建,那是一个全体的构建政策和上线频率。

Web 持续集成工作推行

随着事情和集体不断扩充,团队面对的题材也更为具挑衅性。作者渐渐将一些自动化工具和办法引入到日常工作中,并总括了这一年来做持续集成的获取经验教训。
(via: 公众号运维帮@王集鹄​​​​)

fir.im 的无休止集成系统衍变过程

加拉加斯不是一天建成的,持续集成不是一开端就是应有尽有的,持续集成系统的嬗变过程是稳中求进的。是比较特出的支付工作流——持续部署,也大致会经历这些演化阶段:

  • 中期阶段:提交代码-自动部署;
  • 相似等级:提交代码-代码静态分析-自动部署,最简便先再出席代码静态分析;
  • flow.ci
    阶段:提交代码-代码静态分析-自动化测试集-自动部署;

    fir.im

这是大家在用的自动化测试集,下边分别说下静态检查分析、单元测试、验收测试、性能测试的实际用途。

DevOps实战-基于Docker的CI/CD

本篇博客作者利用了Spring Boot, GitLab, Jenkins,Docker and
Slack,一步步兑现全方位的不止部署流程。(via : 公众号逼格运维说@彪哥)

Step 1. 静态代码分析

各样公司都会有谈得来的代码规范,代码静态分析工具可以保证代码质量,现成的工具有
java 的 FindBugs,ruby 的 rubocop
等。利用代码检查工具得以襄助协会意识可重构的地方,输出产出 – HTML
报告,也会意识地下 bug;有的代码检查工具还会检查出部分安全漏洞。

这三点是代码静态分析最着重的听从。这里也享受一个 GitHub
地址
,列出一部分主流语言的代码分析工具,可以参考一下。

张大胖的docker之路

这篇小著作以程序员的看法,写了骨干咋样一步步爱上 docker 的故事,Build
once , run anymore.(via:公众号码农翻身@老刘)

Step 2. “单元测试”

此处的
“单元测试”也助长了集成测试,毕竟创业集团要求资源最大化。程序员一定要写单元测试,要制服开发的惯性思维,不要甩锅。下边有一对留意的点和大家分享:

  • 测试异常——不仅仅测试无误意况,也要知难而进测试非常;
  • 调减耦合——保证单独的可测试性;
  • 效果分别——单元测试流太长,领先 20
    分钟的话要详细想转手如何将功能独立拆开,效能更高;
  • 测试=需求——从测试代码看到各类 class 是为啥的,同时出现 bug
    时,第一时间是看测试,想想怎么从测试中复现;

DevOps发展的9个趋势

用作 DevOps 的爱好者,作者总计了 DevOps
将来上扬的多少个样子,文中也讲到一些
微服务、Docker、自动化测试、DevOps编程语言等,感兴趣的可以参考一下。(via
:
ThoughtWorks@顾宇

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 会不会改变:)

Top DevOps Tools: 50 Reliable, Secure, and Proven Tools for All Your DevOps Needs

此处列出了 50 个一流的
DevOps工具,一起探访它们各自的特点啊。(via:stackify.com


以上是 CI Weekly #17 的持有技能分享,
如有问题,请联系我们~

Happy building!
flow.ci

CI Weekly 围绕『 软件工程效能提升』
举行一多元技术内容分享,包括国内外持续集成、持续交付,持续部署、自动化测试、
DevOps 等进行学科、工具与资源,以及部分工程师文化有关的程序员 Tips
。同步于
flow.ci
Blog、微信公众号、官方乐乎微博专栏简书,欢迎关注或投稿:)

Step 4. 性质测试

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

属性测试会有部分不引人注目,有为数不少体系会暴发缓存。flow.ci
的属性测试跑在 docker
上,是一个干净独立的条件,需要让系统预热运行一下。Locust/JMeter/LoadRunner是眼前相比流行的习性测试工具。
flow.ci
目前用的是 locust,可以参照一下。

不停集成的可视化、数据解析

我们以为一个好的缕缕集成系统也要成功连串进度的透明化,最传统的艺术是发送有关的邮件,但真相上有几人去看吗?为此我们购买了一个大的屏幕来缓解这一个问题,用来每一天指示团队的某个构建结果。当然也得以用闪烁灯或音频的办法。

fir.im

说到多少总计分析,整个 ci
流程跑下来爆发的很多数量也相当有挖掘的市值。比如,对于代码静态分析有些许
Offence、Risk、Bug,对于单元测试有失利率、测试覆盖率;对于验收测试或性质测试有稍许的败北率,这一个多少都有可能变为衡量一个程序员的正式。

fir.im

结语

CI 就像盖楼房的脚手架一样,没有脚手架就没办法盖出一个十足高的楼,没有 CI
就无法提交质地丰富好的软件!

欢迎分享您的见识。


P.S.想要现场 slide
的同窗,请扫码下图关注群众号flow_ci,并还原关键词「ci实践」即可拿到 🙂

fir.im

Post Author: admin

发表评论

电子邮件地址不会被公开。 必填项已用*标注