Tinker
本文给出了Jenkins引入Tinker实现的持续集成的一种实现思路
介绍
接入tinker的项目在生成生产包时，还有额外的产物，一个基准包，以及混淆相关的map文件，当要打补丁的时候，需要基准包和相关文件才能正确合成补丁包。通常情况下，开发人员需要在发布版本的时候手动保存基准包文件，然后在需要时将备份的基准包文件拷贝到Android工程中进行补丁包的生成。人工并不靠谱，如果出现基准包忘记备份或是错误版本的基准包，都会导致补丁包生成失败，而且手动工程比较复杂，往往需要开发人员来处理，效率低.
在jenkins持续集成系统中，通过gradle可以方便的进行打包，tinker使用了tinkerPatch的脚本，会在打包后在build目录下生成基准包，我们需要处理的以下两点：
- 打生产包时备份基准包
- 打补丁时，将基准包拷贝到指定位置
gradle中可以方便的运行python脚本，在jenkins上安装好Python环境，在apk模式下打正式包的时候Python处理基准包：
- 打包完成后，压缩基准包
- 将压缩包拷贝到机器的指定目录，目录名用唯一id（时间戳）
- 打印id在job的console里，方便查找
需要合成补丁时，将代码提交到git仓库上，jenkins选择patch模式打包，与apk模式的操作相反：
- 根据id获取压缩包路径
- 解压压缩包到指定的合成目标目录
- 将补丁包作为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
