移动端持续集成的落地

作者介绍：

移动端持续集成背景介绍

我今天给大家分享的主题主要是移动端持续集成的移动端落地。先给大家介绍一下我的一些背景，大概做了十年左右的软件的质量研发，还有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安装的统计信息，比如说全国的统一情况是这样的。基本上我今天给大家分享的就是这些。