搭建持续集成打包平台的方案分析

　　该平台主要实现的功能有3点：

　　定期对GitHub仓库进行检测，若有更新则自动执行构建打包；构建成功后根据ipa/apk生成二维码，并可在历史构建列表中展示各个版本的二维码，通过手机扫描二维码可直接安装对应版本；在构建结果页面中展示当次构建的成果物（Artifact，如.ipa、.app、.apk、info.plist等文件），供有需要的用户进行下载。

　　接下来，本文就开始对平台建设的完整实现过程进行详细介绍。

　　安装Jenkins

　　Jenkins依赖于Java运行环境，因此需要首先安装Java。

　　安装Jenkins的方式有多种，可以运行对应系统类型的安装包，可以通过docker获取镜像，也可以直接运行war包。

　　我个人倾向于直接运行war包的形式，只需下载jenkins.war后，运行如下命令即可启动Jenkins。

　　$ nohup java -jar jenkins_located_path/jenkins.war --httpPort=88 &

　　如果不指定httpPort，Jenkins的默认端口为8080。

　　Jenkins插件

　　Jenkins有非常多的插件，可以实现各种功能的扩展。

　　针对搭建的iOS/Android持续集成打包平台，我使用到了如下几个插件。

　　GIT pluginSSH Credentials PluginGit Changelog Plugin： 获取仓库提交的commit logbuild-name-setter：用于修改Build名称deion setter plugin：用于在修改Build描述信息，在描述信息中增加显示QRCode（二维码）Post-Build Plug-in：在编译完成后通过执行脚本实现一些额外功能

　　Xcode integration： iOS专用（可选）Gradle plugin： Android专用（可选）

　　安装方式也比较简单，直接在Jenkins的插件管理页面搜索上述插件，点击安装即可。

　　创建项目（Job）

　　在Jenkins中，构建项目以Job的形式存在，因此需要针对每个项目创建一个Job。有时候，一个项目中可能有多个分支同时在进行开发，为了分别进行构建，也可以针对每个分支创建一个Job。

　　创建Job的方式有多种，本次只需要创建Freestyle project类型的即可。

　　Main page -》 New Item -》 Freestyle project

　　对于一个持续集成打包平台，每次打包都由4步组成：触发构建、拉取代码、执行构建、构建后处理。对应的，在每个Job中也对应了这几项的配置。

　　配置Git代码仓库

　　要对项目进行构建，配置项目的代码仓库是必不可少的。由于当前我们的项目托管在GitHub私有仓库中，因此在此需要对Git进行配置。

　　在【Source Code Management】配置栏目下，如果之前GIT plugin安装成功，则会出现Git选项。

　　配置Git代码仓库时，有三项是必须配置的：仓库URL地址（Repository URL）、仓库权限校验方式（Credentials），以及当前Job需要构建的代码分支（Branches to build）。

　　在配置Repository URL时，选择HTTPS URL或SSH URL均可。不过需要注意的是，Credentials要和Repository URL对应，也就是说：

　　如果Repository URL是HTTPS URL形式的，那么Credentials就要采用GitHub用户名密码的校验方式；而且，如果在GitHub中开启了2FA（two-factor authentication），那么还需要在GitHub中创建一个Personal access token，输入密码时将这个Personal access token作为密码进行输入。如果Repository URL是SSH URL形式的，那么就需要先在Jenkins所在的服务器上创建一个SSH秘钥对，并将公钥添加到GitHub的SSH keys中，然后在填写Credentials时，选择SSH Username with private key的校验方式，填入GitHub Username、SSH私钥、以及创建SSH秘钥对时设置的Passphrase。

　　如果对Git权限校验的概念还比较模糊，可以参考《深入浅出Git权限校验》。

　　在配置Branches to build时，可以采用多种形式，包括分支名称（branchName）、tagName、commitId等。其中分支名称的形式用的最多，例如，若是构建master分支，则填写refs/heads/master，若是构建develop分支，则填写refs/heads/develop。

　　除了以上关于Git的必填配置项，有时根据项目的实际情况，可能还需要对Jenkins的默认配置项进行修改。

　　比较常见的一种情况就是对clone的配置进行修改。

　　在Jenkins的默认配置中，clone代码时会拉取所有历史版本的代码，而且默认的超时时限只有10分钟。这就造成在某些项目中，由于代码量本身就比较大，历史版本也比较多，再加上网络环境不是特别好，Jenkins根本没法在10分钟之内拉取完所有代码，超时后任务就会被自动终止了（错误状态码143）。

　　这种问题的解决方式也很简单，无非就是两种思路，要么少拉取点代码（不获取历史版本），要么提高超时时限。对应的配置在Advanced clone behaviours中：

　　Shallow clone：勾选后不获取历史版本；Timeout （in minutes） for clone and fetch operation：配置后覆盖默认的超时时限。

　　配置构建触发器

　　代码仓库配置好了，意味着Jenkins具有了访问GitHub代码仓库的权限，可以成功地拉取代码。

　　那Jenkins什么时候执行构建呢？

　　这就需要配置构建触发策略，即构建触发器，配置项位于【Build Triggers】栏目。

　　触发器支持多种类型，常用的有：

　　定期进行构建（Build periodically）根据提交进行构建（Build when a change is pushed to GitHub）定期检测代码更新，如有更新则进行构建（Poll SCM）

　　构建触发器的选择为复合选项，若选择多种类型，则任一类型满足构建条件时就会执行构建工作。如果所有类型都不选择，则该Jenkins Job不执行自动构建，但可通过手动点击【Build Now】触发构建。

　　关于定时器（Schedule）的格式，简述如下：

　　MINUTE HOUR DOM MONTH DOW

　　MINUTE： Minutes within the hour （0-59）HOUR： The hour of the day （0-23）DOM： The day of the month （1-31）MONTH： The month （1-12）DOW： The day of the week （0-7） where 0 and 7 are Sunday.

　　通常情况下需要指定多个值，这时可以采用如下operator（优先级从上到下）：

　　适配所有有效的值： * ，若不指定某一项，则以 * 占位；M-N适配值域范围，例如7-9代表7/8/9均满足；M-N/X或*/X：以X作为间隔；A，B，C：枚举多个值。

　　另外，为了避免多个任务在同一时刻同时触发构建，在指定时间段时可以配合使用H字符。添加H字符后，Jenkins会在指定时间段内随机选择一个时间点作为起始时刻，然后加上设定的时间间隔，计算得到后续的时间点。直到下一个周期时，Jenkins又会重新随机选择一个时间点作为起始时刻，依次类推。

　　为了便于理解，列举几个示例：

　　H/15 * * * *：代表每隔15分钟，并且开始时间不确定，这个小时可能是：07，：22，：37，：52，下一个小时就可能是：03，：18，：33，：48；H（0-29）/10 * * * *：代表前半小时内每隔10分钟，并且开始时间不确定，这个小时可能是：04，：14，：24，下一个小时就可能是：09，：19，：29；H 23 * * 1-5：工作日每晚23:00至23:59之间的某一时刻；

　　配置构建方式

　　触发策略配置好之后，Jenkins就会按照设定的策略自动执行构建。但如何执行构建操作，这还需要我们通过配置构建方式来进行设定。

　　常用的构建方式是根据构建对象的具体类型，安装对应的插件，然后采用相应的构建方式。例如，若是构建Android应用，安装Gradle plugin之后，就可以选择Invoke Gradle ，然后采用Gradle进行构建；若是构建iOS应用，安装Xcode integration插件之后，就可以选择Xcode，然后选择Xcode进行构建。

　　该种方式的优势是操作简单，UI可视化，在场景不复杂的情况下可以快速满足需求。不过缺点就是依赖于插件已有的功能，如果场景较复杂时可能单个插件还无法满足需求，需要再安装其它插件。而且，有些插件可能还存在一些问题，例如对某些操作系统版本或XCode版本兼容不佳，出现问题时我们就会比较被动。

　　我个人更倾向于另外一种方式，就是自己编写打包脚本，在脚本中自定义实现所有的构建功能，然后在Execute Shell中执行。这种方式的灵活度更高，各种场景的构建需求都能满足，出现问题后也能自行快速修复。

　　另外，对于iOS应用的构建，还有一个需要额外关注的点，就是开发者证书的配置。

　　如果是采用Xcode integration插件进行构建，配置会比较复杂，需要在Jenkins中导入开发证书，并填写多个配置项。不过，如果是采用打包脚本进行构建的话，情况就会简单许多。只要在Jenkins所运行的计算机中安装好开发者证书，打包命令在Shell中能正常工作，那么在Jenkins中执行打包脚本也不会有什么问题。

　　构建后处理

　　完成构建后，生成的编译成果物（ipa/apk）会位于指定的目录中。但是，如果要直接在手机中安装ipa/apk文件还比较麻烦，不仅在分发测试包时需要将好几十兆的安装包进行传送，体验用户在安装时也还需要通过数据线将手机与计算机进行连接，然后再使用PP助手或豌豆荚等工具进行安装。