高效APP自动化实践进取之路之自动化打包

目标 - 要干啥

APP程序的打包与普通应用程序的步骤类似又有不同，类似之处在于其基本过程都是一样的，大都是三步曲：获取源代码-》编译-》生成可执行程序；不同之处在于其编译工具不同，依赖的环境不一样而已。对于较大型尤其是商业使用的APP，其运行环境一般区分为测试环境，演示环境，生产环境，等等，因此需要生成不同环境下的部署包。

方案 - 啥方法

虽说一般按照三步曲（获取源代码--》编译--》打包）来完成打包，但是细细地说来，打包的基本步骤可以分成下面几个过程：

打包基本步骤

如果咱不是开发APP的成员，仅负责打包自动化工作，此时咱就需要搭建一套编译环境，完成一些准备工作，比如拷贝编译依赖文件，下载依赖包等。不同项目使用的工具和环境也各不相同，找研发人员取经是最快的方法，大力推荐，可以少走弯路节省很多精力。

不管是单打独斗还是团队合作，源代码一般都用配置管理工具来共享和做版本管理。代码是不断变化的，所以咱们就需要在打包的时候获取（指定分支下的）最新代码。这就需要配置编辑环境下的源代码连接到配置代码库，配置相应的账号和授权等。此时注意，如果产品的代码库有多个分支，一定要获取指定分支下的版本。

如果APP有后台服务，需要连接到各种服务器（数据库服务器，中间件服务器，消息服务器，短信服务器，邮件服务器，等等），那强烈建议编写打包脚本，统一管理的服务连接信息。若要生成多种环境（测试环境、演示环境、生产环境、其他各种环境，等等）下的编辑包，建议将这些脚本各自独立管理，避免参数错误造成的环境连接错误问题，减少解决这些问题带来的开销。

脚本写好后，运行脚本生成部署包。

如果对产品有安全要求，部署包生成后，要对其进行安全加固。强烈建议生成测试包后，将其备份到相应的文件服务器中，便于管理和分享。

实践 - 怎么做

如前文所说，不同项目使用的工具不同，这里以一种实践的具体实现作为举例。这次用到的开发工具是Android Studio，代码管理工具是git，打包脚本是shell脚本，用Jenkins进行打包。

搭建编译环境

先下载最新版本的Android Studio（地址：http://www.android-studio.org），下载完成后，按照指引默认完成安装。

安装完成后，获取项目的代码，创建工程，搭建编译环境。此时一般就是配置AS工程，获取编译需要的各种第三方依赖库，一般分成两种，一种可以通过本地获取，另一种需要联机下载。通过本地获取的包可以直接找研发人员获取，联机包下载的时候经常会遇到下载国外包太慢甚至下载不下来的问题，此时可以通过切换到国内的镜像库来完成。

如果使用Jenkins完成打包，此时建议先创建Jenkins工程，再去配置AS工程，因为Jenkins工程创建完成后，会有一些Jenkins特有的目录结构和路径，将AS代码工程直接创建在Jenkins工程路径下可以节省调试的成本。

获取指定分支最新代码

配置AS，连接代码库，获取指定分支的最新代码。

如果使用Jenkins打包，可以在Jenkins工程中配置访问代码库，并且指定分支。Jenkins会在每次打包完成后，通过访问代码库的代码提交记录，自动生产此次版本对应的版本变更记录。

编写打包脚本

根据工程的特点，编写生成安装包的脚本。

建议与研发人员配合，将各种APP需要访问的服务地址和服务开关提取出来，通过配置文件或者其他特定方式保存，这样就可以通过指令的方式生成各种不同环境下的部署包。比如说需要访问服务地址如下：

（1）数据库类型和数据库访问地址；

（2）各种后台服务的访问地址；

（3）短信服务器的访问地址；

（4）第三方服务的访问地址；

（5）其他各种需要访问的地址；

各种开关和配置如下：

（1）调试日志开关，日志方式和日志级别；

（2）特定服务开关；

（3）角色权限配置；

（4）等等。

通过抽取这些环境信息和开关设置等，可以很方便的生成各种环境下需要的部署包：

（1）测试环境；

（2）演示环境；

（3）生产环境；

（4）挡板环境；

（5）覆盖率环境；

（6）其他各种指定环境，等等。

如果使用Jenkins打包，可以配置调用命令行来调用batch或者shell脚本。

生成测试包

设置环境参数，运行打包脚本，生成测试包。

打包完成后，可以在Jenkins中直接编写脚本生成带有时间戳的部署包，将其拷贝到指定路径下进行发布。

安全加固

调用安全加固脚本，对生成的测试包进行加固，生成加固后的新测试包。

发布与备份

将生成的测试包拷贝到测试发布路径和版本备份路径下。

使用 - 怎么用

这里说点技术之外的话，就是测试过程中的版本发布节奏控制。建议测试人员掌握版本发布的节奏，每次测试工作完成或者达到预期目标后再生成新的版本测试，而不是研发人员每次有了一点修改就直接生成测试版本驱动下一次测试。这样做的目的是为了保证测试质量，每个版本测试达到一定目的后再做下一轮测试，比如说变更代码覆盖率达标，或者测试完成已提测功能，等。

敏捷开发的持续集成（比如说，daily build日构建）是建立在大量的自动化测试或者单元测试/白盒测试的基础上的。咱们一般的项目如果前提准备工作都没做，就直接跳到下一步，这是埋下了很大的质量隐患的。因为基本上不可能每天都能把所有的用例都跑一遍，一次都没跑完下一个版本就来了，大部分情况下大家都是直接继续执行下面的测试，而不再执行已经跑过的测试了。不是大家不想再执行一遍，实在是没人没时间，直白点，就是项目组没钱，负担不起这个成本。

结束语

虽然打包一般是测试工作的第一步，但自动化打包不一定是APP自动化工作的第一步。我们完全可以先去做测试用例的自动化，在有需要时再做自动化打包工作。但是自动化打包一定是持续集成工作必不可少的一部分，其价值体现在稳定的版本输出和随时可用的最新包，减少因为手工打包带来的时间开销，和解决手工打包错误的开销。