种种团队或者习惯的措施和关怀点都不均等,从火速方法论的角度分享了不止集成流程的品质实践与

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

乘胜软件安顿的更加成熟,敏捷、DevOps、CI/CD、Docker等词语逐渐现身在工程师的视野中。对于持续集成,业界也绝非一个通用的形式,每个社团或者习惯的办法和关怀点都差距。持续集成最重大的在于「持续」与「自动化」,这篇小说依照那多个关键点,将
CI 系统分为三个进阶进度,来探视你们的团伙处在哪个阶段。

创设一个高质量的 Android 应用 最大的挑衅是怎么着?
在总体开发流程中,也许 Coding 时莫名的 bug,也许是 Android
开发包容性难题,多版本多渠道自动打包难题,也有开发工具拔取等等。

十一月15日,fir.im CTO
郭扬在“光环国际·2017敏捷春季峰会”带来了《敏捷工程实践的内核——持续集成》的技术实施,从高速方法论的角度分享了无休止集成流程的品质实践与
fir.im 团队的 CI 技术实施。演讲实录整理如下,希望能带给你有些盘算。

先是进阶 — 代码级其余合一,那是初期的无休止集成

在前期的不止集成进程中,不借助独立的穿梭集成工具,一般语言的 build
工具基本放手,比如 java 的maven/gradle/ant/ivy,c/c++ 的make
/premake,同时也会加入代码风格检查,静态代码分析,单元测试调用,测试覆盖率检查等进步成效。接下来的付出准备条件、运行测试、备份旧版本、新本子打标签以及反映机制等其他重复的作业全由手工完毕,会费用很多时间。

每个分裂段位的 Android
开发者,都会有例外的答案。怎样自动化整个开发-打包-分发的流水线可能的确必要思想。

fir.im

其次进阶 — 集成 Workflow,基本落实了确实的不停集成

单纯的编译-营造工具逐渐地不可以知足产品快捷交付的需求。

凡事开发流程的主心骨从「代码级其余融会」转移到了更自动化地编译更完善的测试注明,致力于在最短的年月内意识难点,缩小开发周期,进步软件品质。相比广泛的一个气象,某个协会先举行代码
Build,触发单元测试、集成测试,打包测试截至后再自行计划到测试环境,循环往复,形成「编译-创设-测试-集成-计划到测试环境」的
Workflow.

flow.ci
是融入了 workflow
机制的不断集成(CI)服务,也得以精通为自动化流程平台,除了集成代码、编译、测试之外,还足以合二为一常用的工具、灵活自定义流程,匡助你们作育一个更雅观智能的缕缕集成系统。

flow.ci

那篇小说将因而实际的教程向大家来得使用
flow.ci心想事成
Android 应用自动化持续集成,并将 APK 文件计划到 fir.im
第三方应用分发平台。分发完了后,使用 Webhook、邮件、Slack
布告加入测试的人手的一多样步骤,让您全自动化地成功全套开发流程。

郭扬,fir.im
CTO,曾就职于保时捷戴姆勒(戴姆勒(DAIMLER))立异实验室,Thoughtworks,Sony移动通信,网易等公司,担任
DevLead,负责组建技术公司,管理项目进度与项目危机,软件及 DevOps
的架构设计、高并发条件下的性质调优、敏捷教练等工作。

其三进阶 — 持续交付与安插,绝对成熟的缕缕集成系统

在上个进阶中,产品是自动布署在测试环境,手动计划在生产条件。之所以如此选择,是因为产品在从须求到安排的进程中,会经历多少种分裂的环境,例如
QA
环境、各类自动化测试运行环境、生产环境等。那些环境的搭建、配置、管理,在不一致条件中的具体安顿是比较复杂的。平常会遇到那样一种现象:明明在测试环境已经安顿成功,但线上环境又并公布局故障。那种状态很可能是生产条件和测试环境的异构造成的。

那会儿必要创新你的 CI 系统,建立标准的条件安排顺序,在 Workflow
中追加布署预生产环境并举办灰度集成测试的流程,做好线上环境安排后的回归测试。到此地,已经真的完结了无休止交付。

绵绵交付并不是指软件每一个转移都要及早布署到产品环境中,它指的是其它的代码修改都足以在其他时候实施布置。而“持续安排”,即活动安插到生产条件中而无需手工干预:得到一个版本后,自动计划该版本到生产条件中。实践声明,相对独立飞速地配置新功用是一个骨干竞争力,可以减轻大规模功效改变的危害。

CI/CD

没完没了安排,是相对成熟的持续集成系统。

“开发人员提交代码,持续集成服务器获取代码,执行单元测试,根据测试结果决定是不是布署到预演环境,假使成功布置到预演环境,举行总体验收测试,若是测试通过,自动安插到产品环境,全程自动化高效运转。”

了解 flow.ci

flow.ci
是融入了 workflow
机制的频频集成(CI)服务,也能够知晓为自动化流程平台,除了集成代码、编译、测试之外,还足以合二为一常用的工具、灵活自定义流程。1
分钟即可到位开发测试环境搭建,开启第二个 Build。


flow.ci,我们把品种的开支工作流称为
flow ,每个 flow
触发器插件整合。系统基于不一样的言语和条件提供相应的 flow
模版,触发器和插件。Flow 的自定义极度简单,只须要 One-Click
即可添加你须要的插件。它恐怕是一个代码静态分析检测工具(比如
Eslint),可能是一个数据库(比如
Mysql/MongoDB/Redis),也恐怕是一个音讯公告插件(比如 邮件/Slack)等。

更令人瞩目于代码,其余的琐事交给
flow.ci
自动化完结吧 🙂

随处集成做什么样

不停集成的概念现身在 2001 年,它其实是一个 XP
极限编程的工程实施。那么持续的是怎么样,集成是怎么样吗,至极不难就是“一向不停地合一代码”。

不停集成是把代码频仍的联结到基本,通过自动打造的主意阐明软件的质量,让集体高速的响应质量,疾速的修补难题,快捷的给客户解决难题,快捷地付诸更好的软件品质。

第四进阶 — 并行多 workflow 集成以及个性化集成,基于 Docker 的持续集成

随着项目和团队规模增进,模块之间看重关系变得复杂,如何确保代码品质的还要,保险代码创设的一致性和乌兰察布久安,成为一大挑战。Docker
可以便宜地以“容器化”的办法布置,它如同集装箱一样,打包了富有着重,在其余服务器上布署很不难,不至于换服务器后发现种种配置文件散落一地,那样就解决了编译时依赖和运行时信赖的标题。

还有一个难点,开发的分段越来越多,每个活跃分支都进展环境安插和集成测试,对随地集成环境的维护花费也就越高。Docker
的飞跃启动和镜像仓库是自然为 CI/CD
设计的,之前启动一个虚拟机必要几秒钟,而启动 Docker
只要求几分钟,让相互的不断集成才能成为可能。

此时此刻,比较广泛的基于 Docker 举行连发集成的流程如下:

  • 开发者提交代码;
  • 触发镜像创设;
  • 营造镜像上传至私有仓库;
  • 镜像下载至执行机器;
  • 镜像运行

PS:目前
flow.ci
还未协理 Docker. 下图以 Jenkins 作为 CI/CD
的测试运行引擎,在方方面面持续集成系统中选拔 Docker 的流程图。

Docker & 持续集成

终极,开发公司面对尤其复杂的环境,须要组合团队的实在境况,定制出符合的方案,不断优化整个自动化开发工作流,从而打造出一套更符合的不断集成系统。


【参考】

探究持续集成,持续交付,持续安顿时期的界别

穿梭集成系统的变异之路

搭建 Android 应用的遍地计划

设置 Andr​​oid 持续布署流程万分简单:

咱俩怎么要做持续集成

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

  • 此情此景一:开发了新成效,老作用暴发新的 bug;
  • 情景二:修好一个 bug,又发生其余 bug,甚至出现连环 bug;
  • 现象三:出现的 bug
    相比多,修改代码要很严格,不熟稔的模块一般不敢动,怕引起难题;

纷来沓至集成是何等解决这一个题材,马丁 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

从这张图上可以见见,持续集成形成一个周密的闭环。通过不断的融会举行持续地检查、调整,同时,项目标透明性也得到了最大的反映。

1.创办项目

flow.ci

fir.im 怎么样开展连发集成实践

那是一个科普的源源不断集成流水线:

fir.im

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

假若测试通过验收截止后,持续集成系统会活动触发安排到类生产环节或测试环境,或由专人手动陈设到生育环境。

2.关联代码仓库

flow.ci

怎么要做当地集成

先是,代码在长途进行田间管理,每个人都会提交代码,远程的代码仓库会爆发变化,所以在当地集成的时候须求举行代码合并,以防出现分支争持和代码争执。其次,不要借助于不断集成系统给你结果,可能要求30 秒钟的时光,不要让开发人员等待,一定要先做地点集成。

3.增选要合并的种类

flow.ci

怎么着做版本提交

再说一个付出的难题,大家尽量保证每一趟提交都是一个总体的付出,也就是原子提交。

当代码变动你想创造提交时,这几个提交相应尽可能的少量,并且带有一个不可分割的风味(feature)、修复(fix)或优化(improved)。

拿每个产品开发都会遇见的 login
作用开发举例,当填完的用户名和密码传到数据库,做完验证后给用户重临一个结出。这什么样是一个原子提交?比如,提交证爱他美个用户名,那是一个整机的
feature ;验证密码是还是不是切合格式(6位/8位),那也是一个完完全全的 feature
;当我表明完用户名和密码后再传播数据库之后,查询正确与否,那也是一个完全的
feature ;有限协理每趟提交是一个完好的 feature 或修复了一个
bug,不要代码写成半截。

4.早先你的首先个 Flow

flow.ci

flow.ci

慎选品种项目 Android ,开启默认的 flow 模板 ,包涵 Intialize – Git Clone

  • Cache – Build 的流程。

接踵而至 蜂拥而至集成系统

那里讲的是狭义的无休止集成系统,常常的 CI
系统接到提交之后会触发打造,营造会有音信再次回到比如 commit id 、commit
音讯、代码变更等,收到代码提交后会触发自动营造,接着安装看重进行编译,并触及品质担保流程,也就是说自动化测试集。

fir.im

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

fir.im

接下去,大家实际讲一下 fir.im 团队如何开展连发集成实践的。

5.选项语言版本,单击创设项目

flow.ci

慎选项目语言的本子,除了 Java for Android
外,flow.ci
提供 Node.js , Ruby , PHP , Python 的多语言、多版本的付出测试环境。

继续会协助更加多语言。

fir.im 的神速环境

fir.im 是一个内测分发平台,我们也做了一个不息集成 CI
产品-flow.ci。先来看一下我们正在利用的全速环境:

fir.im

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

6.点击“+”添加插件,自定义 flow

flow.ci

在条件和言语等上马配置落成后,flow.ci 会提供一套 基本 flow
模版,内含通用流程插件和流程触发设置。借使您有定制化的必要,点击图中“+”或者“删除”“编辑”,实时设置就足以。

说一下 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
结合的法门组成大家每天打造,那是一个完好无缺的创设政策和上线频率。

7.在插件列表中找找 Infer Analyzer 插件,选用丰裕

flow.ci

Infer Analyzer 是 脸书 推出的 Java
静态代码分析工具,添加这一个插件到你的 Flow 模板可以扶持拦截早期错误。

fir.im 的接踵而至 蜂拥而至集成系统衍生和变化进度

亚特兰大不是一天建成的,持续集成不是一早先就是完善的,持续集成系统的嬗变进程是稳中求进的。是比较理想的开发工作流——持续布署,也大概会经历那多少个衍变阶段:

  • 初期阶段:提交代码-自动布置;
  • 诚如等级:提交代码-代码静态分析-自动安顿,最简易先再插足代码静态分析;
  • flow.ci
    阶段:提交代码-代码静态分析-自动化测试集-自动陈设;

    fir.im

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

8. 继续拉长 fir.im Uploader 插件

flow.ci

fir.im Uploader 插件将出口的 apk 文件上传到
fir.im
应用内测平台,添加那些插件须要加上你的 fir.im 账号的 API
token。其它,该插件协助变量,能够直接拉取 github
的提交日志,作为版本更新日志。

Step 1. 静态代码分析

种种商家都会有投机的代码规范,代码静态分析工具能够保险代码质量,现成的工具有
java 的 FindBugs,ruby 的 rubocop
等。利用代码检查工具得以帮衬协会意识可重构的地点,输出产出 – HTML
报告,也会发现地下 bug;有的代码检查工具还会检查出一些安全漏洞。

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

9.做到后,仍能增加邮件、Slack等音讯公告插件

flow.ci

落成那套自动化流程之后,只必要开发新作用,提交代码即可。图为跑完所有持续计划流程,健康的品种景况。


麻烦可循的天职就应有工具化自动化,那是程序员们的死活追求。即使你也想神速搭建
Python 项目的自动化持续集成,来
http://flow.ci
首页提交申请,约请码随后会发送到邮箱。

期待你的举报。

Happy Building!
flow.ci team

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

结语

CI 就如盖大楼的脚手架一样,没有脚手架就不能盖出一个足足高的楼,没有 CI
就不可能提交质量足够好的软件!

迎接分享你的见解。


P.S.想要实地 slide
的同学,请扫码下图关心群众号flow_ci,并还原关键词「ci实践」即可获得 🙂

fir.im

相关文章