移动端持续集成的落地

作者介绍:

移动端持续集成背景介绍

我今天给大家分享的主题主要是移动端持续集成的移动端落地。先给大家介绍一下我的一些背景,大概做了十年左右的软件的质量研发,还有DevOps 的一些工作。然后经历了外资企业还有一些互联网,比如说360。

然后移动端持续集成的背景,现在app 端主要是两大阵营。一个是安卓,一个是IOS。

安卓市场占有率目前比较高,大概是85%以上,IOS 比较低一点,大概百分之十几,因为IOS没有安卓碎片化那么严重,所以安卓定制的厂商也比较多,所以安卓占有的市场也比较高。

现在移动互联网的时代一般来说,都在端上。比如说用的手机安卓还有IOS、微信等等。但是这些东西,又有不同的厂商,比方说有华为、三星、小米、诺基亚的等等,他们其实都基于Google,包括Ios和微信这些其实也是端上的一些服务。

但是这些端上服务越来越多,那我们怎么基于端上的服务,做一些持续的集成?因为这些东西每天构建的次数也是非常多的,频率也是非常高的。

可能大家都非常了解,持续集成这些东西。我就先把简单的流程讲解一下。大概情况就是说,一些代码去代码仓库去拉代码,然后这些环境是可以用的,可以给你们的后台看到。

主要我讲的APP端的持续的集成主要是以安卓为主来讲,因为我们公司目前百分之九十都是基于安卓发布版本和集成的工作,大概的流程也就是一开始获取代码,然后对代码进行编译,然后进行测试,测试通过之后打包,打包变成APP包,然后再发到对应的安卓的市场上,或者等等的一些渠道商,然后再发邮件发出来,如果用JenkinsX集成,这一套用JenkinsX对安卓的一个发布。

如果是Jenkins也非常的方便,对安卓做的一些发布,最终编译就可以用二维码做出来之后,就用二维码打出来,一扫二维码,就可以安装安卓APP。

这是持续集成的流水线,我看又是重复地之前讲过的一些东西,大家不是太了解的同学可以看一下。

大概在本地的持续集成上,提交你的代码,去版本的控制系统里面,你可以是git,当然有的公司人家很传统,还在CSV还在用,有了git分布式比这个更先进,代码不易丢失。

到了代码仓库之后,触发你的CI持续集成,然后可以到一些任何的环境上,比如说测试的环境,有类生产环境有生产环境,这个名字也没有那么准确。有的公司可能他会有自己的开发环境等等。

在下面这一块,是持续集成,我把它又单独拎出来一部分,这个持续的集成其实说的比较泛,但是持续集成你去提交代码,然后自动地检测,然后在里面做了一些代码的静态检测或者自动化测试,等等一系列的东西,才把代码打包发到环境上。

这里面可能是大家经常用到的持续集成的技术,应该有人在玩的非常熟,比如说Jenkins。在座的各位玩的非常熟,这里面其实是对于代码质量做一些控制监测。比方说单元的测试,你的UI,然后压测,对APP的测试等等。

我大概把市面上几乎90%以上的CI都列出来,基本上也是Jenkins,现在发展到JenkinsX,然后也可以跟Kubernetes来集成。

现在还有一款产品叫team city,我不知道大家用过没有,我前一段用过。其实大家用的IDE非常多,然后那个公司推的一款CI的产品。

这一款产品,你要做持续集成的时候,你必须在对应的机器上,你装好你的agent,然后收集一些持续集成的一些然后发布到agent机器上去执行。

然后第三个Go 是 Thoughtwork 他们公司的一个持续集成工具,这个工具我没有用过,但是我也了解过,大家基本的原理,也是上面的那种模式。

第四个是Bamboo,其实大家对Atlassion这个公司了解的话,其实你们也非常的了解,他是3A服务器,这个产品跟javaKubernetes这些东西集成是非常不错的,因为他们公司自产。

然后接下来的Gitlab CI,也是非常不错的其实,可以推荐给大家用。 然后还有一个是Travis CI,CI的话,其实大家在GIthup上,经常去交流的人其实都知道,如果你们给老外的一些项目去提交一个PR的时候,很多人都写一个文件,那个文件里面,都是里面配了一些持续工具里面的一些构建的信息。

底下是360内部用的一个CI服务器,这一款CI服务器,作为一个移动服务器来讲,主要做安卓方面的持续集成用。

移动端持续集成技术介绍

我基本上把CI的整个流程划了一下,就是对APP端做这种持续集成,大家都要可能走哪些流程。

大概的情况是说,有一个CI服务器,然后你每天会提交你的需求,有可能是你的产品,往这里面提需求,然后开发拿到这个需求去开发,然后去提交代码。

一般来说大家,可能说你的代码提交到git仓库上就完了。提交完之后,你可以在你的CI服务器上做这种持续的集成构建,那这个持续集成的时候,我们也就不可避免地有你这个自动化的测试。对你的自动化测试的过程中,你还会引入到一个二进制包的概念。

然后,你去做构建的时候,无非就是两个场景。一个是你的Ios,一个是你的安卓。安卓我们其实现在用的是比较多的,主要是基于Gradle,安卓打包基于Gradle任务来打包的。

IOS一般来说,是Xcode,但是ioc它搞的比较严,你不是太利于去做这种CI,因为你把它的包,ipi包打出来之后,你上传到他的APP里面,然后你还要经过人家的苹果的严格的审核之后,你的APP才能的上线。

它不像安卓似的,只要把安卓的APP包打好了,我发到渠道商那边,你就可以在安卓市场等等二维码都可以下载。

所以基本上来说,CI这一块,其实IOS是比较难做的。还有IOS会涉及到一系列的安全性的问题,你要管理他的证书等等。这大概是个的流程,大家可以通过这个流程,对这一方面有所认识。

然后我又对刚刚那个情况进行了一个补充,大概是这么一个流程。就是说你本地的一些开发,不管你是H5开发,你是安卓的开发,你是IOS的开发。然后你们其实最终是往Git上去提交你们代码。

提交完代码之后,然后你的代码再去布置到你的Jenkins上,然后Jenkins再到各个渠道包。IOS就是ipa的包,然后安卓APK,然后最终把这个东西包,BOD出来之后,再拷你的自动化测试。

IOS和安卓都可以下载下来,大概是这么一个流程,底下也是这个流程的步骤,大家非常清晰地可以看到,他走了哪些步。

这个是我把安卓单独地拎出来,因为今天重头戏主要讲安卓。IOS持续集成这一块,做的还是能力有限,所以安卓方面我们还是做的不错。

基于安卓的持续集成,就是说把原代码提交到服务器上,当然你也有完整的控制,一会儿有详细的介绍。

然后你的代码再布置到CI上,通过你的构建,测试安卓会有自己的静态恢复的检查,然后他通过自己的检查,把不符合规范的时候,给拎出来,后面还可以做一些检查,我们也用的比较多,然后把这些东西全部拆除完之后,就下载到手机上都可以下载。

大家对安卓的具体的打包的APP不是很了解,大概通过这个步骤,可以清晰地了解到,安卓的打包,到底是怎么持续的集成。

你最终的打包之后,你这个东西到底是怎么做的,我主要是讲安卓,以安卓为主,一个安卓的再到你的APK,里面就存了这么多东西,然后你的那些安卓的代码,最终会编译成一个资源的文件,最终安卓这一块还会有组的描述文件。

然后把他们整体,打成一个APP包,这样的话就可以部署到安卓的市场上。然后安卓有一个特别需要注意的地方,他和你普通的程序包不太一样,比如说你加Java之后就可以随便用,他最终还会加一个签名,这是这个移动端,产品的特殊地方。

关于IOS我也是在网上自己总结了一下,如果想做一个IOS的打包上传大概有这么几个步骤,先需要申请IOS的证书,导入IOS的密钥串,然后再去导上,然后创建APP,然后再上传,再提交审核,APP审核通过。

刚刚说到了安卓打包的时候,会有一系列的流程,这个流程对它进行了一个一系列的签名的一个过程,他可能分了这么几部分,如果你通过你的V2签名之后,接下来会往下走,如果再走到V1这个,会有一个回退,最终你的签名通过,所以说安卓这儿,控制打包的时候,会有一个签名的过程。如果你不签名到不了他这个APP。

下图就是我把Grodle打包,就是有一个安卓的任务,其实是指定了安卓的编译的ITT的版本,把它配置之后,自己就会找到安卓的版本SDK,然后通过安卓自带的一些东西,把相对的包依赖过来,再去打包。

这是安卓上面我截了几个图,如果在安卓如果要开发一个代码,你要产生一个APK,下面就可以通过第二种的方式,也就是说相对于加密的文件,这个的话上面我又做了一个简单的总结,这些谷歌那边的要求。

也就是说如果使用了VI就得加密,如果同时使用V1V2不一定可行。

下面的这个简单介绍一下,这两种签名方式是谷歌和安卓提供了,下面这个大家可以自研的,也就是我们Tim自己写的,有了这个工具的话,我做持续集成非常的方便。

然后,接下来还是对安卓的APK打包,进行一个简单的介绍。然后它基本上的步骤,可以是源代码,通过编译器,找资源的文件,然后再到APK包,最终要去打包成一个APK,要发布到渠道包上,这个发布的时候,就有一个签名。

所以其实他那个签名,最终要有一个密钥的文件做一个后桥,这样的话你APK是安全的。

我简单介绍一下,IOS的一些打包,你也可以用开源的组件,基本上下面是一些简单的命令,通过简单的命令,你就可以通过IOS进行持续的打包,无非就是把这些东西塞到你的平台上就OK了。

那关于整个持续集成,刚刚讲了一部分,可能是讲的不是太全。我通过这一张图给大家讲的更全一点,其实整个持续集成的流程图,通过这张图就看的非常的明确,一个开发一个代码,去版本的控制中间,再到3A服务器上,他会走一系列的流程,之前是1.0,接下来是2.0,2.0比1.0更高级。

然后底下你看他走了很多的步骤,这个图画的还是非常不错的。但是每个公司自己的情况也不一样,也不一定非这几种角色。

然后整个持续集成的流程图中,有可能这个流程中用到的一些技术,一些关键的点,其实我也列在这里,大家通过这些东西可以非常清晰地看到,这边是Kubernetes,包括你的性能,你的安全,包括你的自动的构建,然后通过这些工具到了你的平台上,当然这些里面,也是基于趋势,再往Kubernetes方向上发展,基于这些东西,平台你还可以对它做ERK日志,这其实偏运维了,有点DevOps那种味道。

这是我在平台那边,搭建了一个Jenkins的环境,大家当然也非常的兆,然后每个兆会承载业务线的产品,每天都会有几次,甚至几十次的构建,这个去构建我们的每天的安卓的APK,我们一些中间件服务,但是这个语言也不局限于一种语言,不是安卓一种语言,PPT、JAVA语言等等。

你可以把下面的插件装上,大家稍微看一看应该可以搞定没有什么问题。

然后,这个Jenkins你做的过程中,里面你也可以做成流水线,就像我们这个中间,这个流水线一开始通过CI,调用了自动化的测试方法,我的性能,我的安全测试,然后最终通过了之后,我再让我的测试发布到这个环境里。

讲到CI持续集成这一块,你不讲DevOps非常的庞大,我多列几张图,能让大家加深持续集成,在整个生态中的一些情况。就是一个8字型的。

这个上面主要讲了持续的集成,你的代码怎么打上去,你的代码去发布上去,然后怎么在你的源代码上面拉上来,就是变更之后怎么去做,就是这一套的流程。

这个8字型的这个技术的站,包括持续的集成,包括原代码的管理,包括你的部署,包括你的最终的交付,还有一些技术,最终还要用到Monitor,最终给客户部到这个东西,所以这才能形成一个E字的闭环,否则的话,你光有部署,没有Monitor的话,这是不完善的。

这个其实是非常经典的一般来说做持续集成,做这种配置的人,对这个了解一下还是没有坏处的。

移动端持续集成流程介绍

做持续集成之后,也做持续地交付之后,无非持续集成中间,加入了安全性的代码的工作,但是这个东西也不是百分之百保你,这个过程中,其实我一直认为,你从根源上切断他是最直接的,根源上就是源代码,如果从根源上切断的话,对他的分支策略是非常的熟悉,大家可以看一看相关的资料。

大概是这种情况,开发的提交,然后再到一定的程度Monitor会出现了一个1.0,2.0。

然后如果有了漏洞之后,再去合到你的这个Monitor上面去,刚刚讲了代码,做质量这一块,其实又有很多的技术站,那把这个技术站细分出来的话,其实是有很多的可以去研究的。比方说你对单测,你对代码静态检测的话,这个东西是非常的必要的。

有很多人认为,你做这些东西有什么作用吗?作用非常的多,我们用了一些静态检测的一些工具,做静态的检测单元测试。最终,把这些测试都做完之后,你再做性能的压力安全性等等,再去发你的这种全系统压力测试。

移动端持续集成的案例分享

刚刚讲了那么多,讲了一堆的持续的集成,回到今天的主题,其实是移动端的持续集成是怎么做的,基本上我们移动端的持续集成是这么多的集成,一般你的ADB,你的Build这些还有CI这些必须都有。

但是接下来我们公司内部的程序,专门为安卓这个平台做的,因为安卓的版本比较多,我们有几百上千次的发布,因为我们每天都几百次的在上面操作,所以说还是有这么多的东西出来的,大概我把我们这个平台的架构画了一下,大概是这么一个情况。

基本上不管你是什么决策,你的口进来之后,这个平台是我们自己的平台,你们可以自研一下这些的平台,以满足你自己的业务的需求,不一定非要用现成的,用现成的也是可以解决一些先成的,比如说Jenkins非常不错。

我们分了几部分,几部分是我们抽象出来的脚本库,你也会有很多的地下的版本,然后这些版本要给开发,要给业务人员用,那开发会在自己的上面建自己的任务然后去构建。

然后它又要定制化自己安卓的一些发布,那必然要写一些代码,这样的话他会有自己的一个自定义脚本库的概念,他自己传上去,只要我们的平台支持技术传上来,就可以了。

然后这里面有自己的安卓的公共库,项目、构建、用户、权限,然后还有每天生成的产物,然后这个产物里面就会有签名和没有签名过的APK,你这些信息量是可以做不同纬度的统计,所以加了一个统计和检索的功能。

我们用了一些技术库,然后我们基于自己的ID机房,当然也可以部署到私有云,这就是我们的平台长成这个样子,基本上技术站,就是这么一个情况,也没有美化太漂亮什么的,但是已经是足够用了,因为他这里面也涉及到很多的功能点。

包括我们这个历史记录,就是每天你构建了多少次的版本的发布,安卓可能有自己每天都会发布,你会有历史的记录,但是这个历史记录是给他保留多少天。还有你们公共库的管理,组织成员、代码授权,而且这个最重要的,代码授权。

就是说在这个里面,严格地权限控制,不同角色的人都可以去触发,都可以编译所以做了严格的代码权限的管理,还有一些简单的功能,还有大的功能就是定制日志,就是基本上这么几块功能,做的是比较平面化的界面,就会进入编译的时间,他的代码详情,他是否是什么状态,然后他的编译的产物,这是他的APP,后面这些一个任务,这个任务是可以进行编辑复制操作等等,非常的简单。

那接下来是公共库。刚刚我说了,架构里面是有一个公共库,公共库里面会放一些自定义的东西。

也就是说在这个里面,会定义自己的公共库,我们现在限制不是所有人可以编辑的,这是有一定权限的人才会做的,会影响到移动端产品的发布。所以你把公共库改的话,所有的权限都发不过去,就是你想发的时候。然后涉及的代码的仓库,我们这样是有代码仓库的设置。

我们用到的有SV、STP大概构建的界面主要是这些的情况,主要用到的技术站,主要是地下的构建出来的就是哪个版本下的APK。然后从24一直到27,将来这个版本一直是可控的。

也就是说你在构建的时候,你还指定你的安卓的代码是不一样的,有的是两点几的版本,有的搞的是最新的版本,就得满足他不同的需求。然后还有JDK,还有安卓的SDK,你要把这些全部编译好,这些东西也是动态可以加的。

然后在这儿其实就相当于Jenkins里面的语言,让你去自定义你的构建的任务,然后去定义你的环境,去执行你的一些命令。当然这些命令前提在我们平台上已经支持了,在这个地方有一个签名,就是说对我APK出来的时候,可能做一些签名的工作。

这里我想给大家说一下,可以开发自定义一堆的脚本,在公共库里面,当时设计的理念是,让人随便定义他的脚本,自己构建一些步骤和过程,其实这些东西下载的时候,前面是把公共库的代码克隆,然后和你的安卓的脚本对应的目录下,然后你这个里面就好说了,我找了一个例子,就是大概传了20多个参数,自定义你的参数就可以了,然后编辑好的你参数之后,你进行一个签名。

但是这里面又加了一些功能,比如说有没有加固。因为你对着APP的时候,为了更安全的时候,有这种加固,当然这是另外一个话题。编辑完之后,下面有邮件的模板,可以进行发布,然后这里也可以执行脚本,然后做一些什么事情,也是可以支持的。

刚刚给大家说的公共库,主要是这么一个东西。进来之后,它有基本的简单的信息,你可以Gif可以支持这个,现在CVS,你的分支名都可以加上。

其他的一些功能的话,就是代码权限的管理,还有产品的一些日志,还有一个定时的任务,因为在Jenkins上做定时的任务非常的方便,你直接把定时任务那一段的脚本,按几天几小时塞进去,他会定时执行你的任务。

我们在这儿也是做了这么一个东西,其实也是相当于自己做了这一套包装,也是相当于构建我们安卓的APK。

检索和统计这一块,其实对每天的工作量,构建了多少次,签名了未签名的做一个统计,这些统计的价值,其实有一部分,是为了跟踪每个月,我们安卓或者说APP的发版的质量,第一个方面是这样。

第二个方面,当你日积月累的时候,通过整个优化,可以优化你整个的流程。其他的一些功能,其他的功能给大家看一下,因为涉及到安全的东西,我把安全的东西给划掉了。

基本上对用户的信息进行修改,然后这个信息,可以给他授角色。角色名称是自己定,自己起,主要作用就是通过不同的角色在操作你的任务的时候,你可以有编译权限或者没有编译权限。

这是我们机房的任务,和Jenkins是一样的,我们配置之后这儿是可以可视化,原理差不多,只不过我们高了一层。

这是一个产品的日志,每天构建安卓的成千上万次的信息,通过抓取可以看到信息。后面这个是我们做的一个监控平台,就是专门去监控我们每天构建出来的APP,然后包括APP安装的一些分布的情况。

这个是我们纯写代码做出来的一个平台,这个平台每天定时地监测到APP平时的一些情况,在全国情况到底是一些什么样的。然后厂商的排名的等等都可以看到。

这也是一个对这种APP的曲线的监控,刚刚其实咱们讲的DevOps,最后监控也是非常重要的,没有监控的话,也是不完善的,如果出了问题,怎么办。

我截了IOS的图,这个更偏一些业务。也就是说这个APP装了之后发布之后,对我的渠道商业化的转化是多少。其实这个更偏向于APK安装的统计信息,比如说全国的统一情况是这样的。基本上我今天给大家分享的就是这些。

视频内容

原文发布于微信公众号 - DevOps时代(DevOpsTimes)

原文发表时间:2018-08-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏子勰随笔

SDK之关于SDK的一些想法

28016
来自专栏java思维导图

为什么一定要前后端分离?

由于近期前端抽不出资源,博主最近接手一个前端项目的代码维护工作。拿到手一看,一脸懵逼,和博主当年所学的jsp开发方式、利用ajax来请求数据的单页面开发方式完全...

1574
来自专栏大数据钻研

十年来,编程领域有什么重要进展?

编程语言层出不穷,然而内核是万变不离其宗。我个人看法觉得是以下几个方面的变化比较明显。 语言本身: 1. 工业标准 网页标准有 W3C 控制,尤其是浏览器的开发...

3585
来自专栏程序你好

微服务Microservices——应用架构的未来

能够构建、演变和扩展大型应用程序对于组织来说是至关重要的,但是所涉及的挑战使其成为一项困难的任务。正因为如此,微服务已经成为构建现代云应用的主导模式,它将单个组...

1702
来自专栏企鹅号快讯

前后端分离实践

前后端分离并不是什么新鲜事,到处都是前后端分离的实践。然而一些历史项目在从一体化 Web 设计转向前后端分离的架构时,仍然不可避免的会遇到各种各样的问题。由于层...

4408
来自专栏架构师小秘圈

为什么一定要前后端分离?

作者:孤独烟,中国平安研发工程师,目前负责云平台架构设计以及需求研发工作。毕业后一直从事Java开发工作,在Web开发、架构设计上有多年的实战经验。在MySQL...

1492
来自专栏JAVA高级架构

分布式之闲侃前后端分离的必要性

762
来自专栏企鹅号快讯

代码学习与实践:开篇-测试深入了解代码的好处及实践

1 缘起 最近在负责测试的项目,相对来说比较复杂。从业务上来看,涉及商品添加、审核、交易、支付、退款、换号、管理等多个流程,从代码逻辑上来看,划分了9个模块,还...

2148
来自专栏程序你好

为什么应该使用微服务(Microservices) ?

如今,微服务非常流行。几乎每个人都喜欢。不仅仅是Netflix、亚马逊或谷歌,似乎几乎每个人都采用了这种架构风格。虽然微服务已经存在了很长一段时间,也有很多关于...

4293
来自专栏性能与架构

内容平台 Medium 的技术体系

Medium 是全球知名的内容平台,访问量惊人 据半年前的数据统计,用户在 Medium 上阅读时间的总和已经达到 2600年,每月有2500万阅读者,每周有数...

3756

扫码关注云+社区

领取腾讯云代金券