Jenkins+Tinker的持续集成方案

Tinker

本文给出了Jenkins引入Tinker实现的持续集成的一种实现思路

介绍

接入tinker的项目在生成生产包时，还有额外的产物，一个基准包，以及混淆相关的map文件，当要打补丁的时候，需要基准包和相关文件才能正确合成补丁包。通常情况下，开发人员需要在发布版本的时候手动保存基准包文件，然后在需要时将备份的基准包文件拷贝到Android工程中进行补丁包的生成。人工并不靠谱，如果出现基准包忘记备份或是错误版本的基准包，都会导致补丁包生成失败，而且手动工程比较复杂，往往需要开发人员来处理，效率低.

在jenkins持续集成系统中，通过gradle可以方便的进行打包，tinker使用了tinkerPatch的脚本，会在打包后在build目录下生成基准包，我们需要处理的以下两点：

1. 打生产包时备份基准包
2. 打补丁时，将基准包拷贝到指定位置

gradle中可以方便的运行python脚本，在jenkins上安装好Python环境，在apk模式下打正式包的时候Python处理基准包：

1. 打包完成后，压缩基准包
2. 将压缩包拷贝到机器的指定目录，目录名用唯一id（时间戳）
3. 打印id在job的console里，方便查找

需要合成补丁时，将代码提交到git仓库上，jenkins选择patch模式打包，与apk模式的操作相反：

1. 根据id获取压缩包路径
2. 解压压缩包到指定的合成目标目录
3. 将补丁包作为artifacts在job上提供下载

整个的jenkins设计思路大致如下示意图：

tinker00.png

生产包和补丁包的gradle指令相同：

jenkinsRelease
-PSOURCE_PATH=./QtsCustomer/build/outputs
-PBAK_SOURCE_PATH=./QtsCustomer/build
-PBAK_TARGET_PATH=/Users/Shared/Jenkins/ApkStore/Android/Student/Tinker


//补丁产物
QtsCustomer/build/outputs/apk/**/tinkerPatch/**/**/*.apk

使用

为了方便集成，生产包和补丁包都是可配的，在jenkins上提供了一个TYPE字段的类型：

• APK
• PATCH

两种类型。

• 正常流程下，我们会选择APK生成来构建一个生产包：

tinker01.png

• 同时会在该job的console下打印出baseId：

tinker02.png

• 在需要补丁的情况下，将TYPE改为PATCH，同时传入对应的baseId：

tinker03.png

• 会在job中展示补丁包，按需下载即可：

tinker04.png