多年之后因为项目需要又开始自己动手配置Jenkins。这次尝试了一下multiple configuration project这个类型的配置，对于如何使用以及适用的场景（尤其是android和iOS的编译场景）记录一下自己的感受。（文中英文部分实在是不知道翻译成什么中文比较合适，jenkins自己的汉化翻译又太....）
什么是多配置（multi-configuration）
详细的说明可以直接阅读官方wiki
简单来说，它是一组job的集合，这些job之间的差别就是配置不同，比如：一个基础库，同一套代码需要编译linux、windows、mac平台的debug和release版本，以前我们是建立3个job分别对应三个环境，如果我们的job不能一次把debug和release都编出来的话，我们就需要建立6个job，如下：
| debug | release | |
|---|---|---|
| windows | job1:win+debug | job2:win+release |
| linux | job3:linux+debug | job4:linux+release |
| mac | job5:linux+debug | job6:linux+release |
虽然Jenkins提供了从已有的job复制的功能，那也是要新建并修改5次啊 o(≧口≦)o
从上表我们可以发现，总共6个job，唯一的不同就是平台和编译类型的不同，看起来我们可以通过将这些组合变成6个参数，那就可以只用一个job就搞定了，你是不是想到了参数化，不失为一种办法，可以试试o(￣3￣)oo(￣3￣)o
言归正传，multi-configuration的核心其实就是上面的表格，将条件排列组合成一组，放在一个项目里面，而不是一个组合一个项目。比如下图就是设置的一个app编译不同环境服务器对应的不同版本的多配置项目后得到的配置矩阵：
通常你会在项目页面的左上角看到它
同时可以看到，我们可以配置哪些配置需要构建，哪些不需要，比如图中的product环境的debug版本的配置就不会构建。
每一次的构建都会把配置都构建，并且将结果保存在一起，如下图，构建#7里面我指定的配置在#7这轮里面的构建结果、对应的归档等都可以在里面，通过Configuration Matrix里面对应的入口（那些圆形的图标，同时这些图标也和构建一样，表示了每个配置的构建成功与否）我们可以进入到具体的配置的构建结果页面，其和一般的构建结果页面完全一致。
Screen Shot 2017-05-27 at 13.09.41.png
如何配置
具体的配置和一般的freestyle项目一样，主要是以下几点：
-
新建项目选择multi-configuration project
新建项目
-
通过add axis设定配置矩阵
配置矩阵
aixs有三种：“Label expresse”使用slave node的label的表达式值作为配置项，即你可以将构建指定在对应label的slave上执行。比如我们有几个mac mini作为slave，它们的label被设置为“iOS”， 并且还有其他的slave，我们不希望iOS的项目在执行的时候被分配到非mac机器上，只需要增加一个“Label expression”的axis，并只填写一个“iOS”的值，那么当multi-configuration下的各个配置同时执行时，它们都只会在这些mac机器上执行。或者简单点使用“slaves”类型的axis，在指定label值或者slave的名字，如下图：
这里会直接列出label或者slave的名字供选择
每个axis包含一个名字和对应的值，最后的矩阵就是这些值的的全排列（那axis排列），比如文中提到的test_mult这个项目，就是配置了type和env两个axis。type有“debug”和“release”两个值，env有“Env_test” “Demo” “Product”三个值。所以整个矩阵就有第一张图里面的6种组合。
添加axis
-
添加配置的过滤规则（如果需要的话）
比如上图，test_mult里面Prodect环境的Debug版本我们是不编译的，是通过“Combination Filter”来实现的，如下图
Combination Filter
Filter里面是填写Groovy的表达式，只有表达式值为真的配置项从会被构建，具体写法可以点击combination filter后的“?”来了解
-
如果想先构建一个（或几个）配置作为验证，如果这个配置能够达到预期再接着构建其他配置的话（称为： touchstone build），勾选上“Execute touchstone build first”并且设置好对于的groovy表达式即可，jenkins会先执行表达式为真配置，并且在构建结果达到你设定的期望“stable” 或者“unstable”后再执行余下的配置
Touchstone Build
执行过程（简述）
jenkins会按照配置矩阵（config matrix）生成对应的工作目录
image.png
再在对应的目录下进行相关的构建工作（同步代码、编译、blahblah），并收集相关信息。�在每个目录下做的事情和一般的freestyle项目一样。
适用场景
- 降低劳动强度，避免通过复制配置不同的项目
- 不同配置需要快速、并行构建
- 多配置情况下，希望并行快速的同时，又想节省slave资源：先跑一个配置的构建，如果构建成功了，才同时并行跑其他所有配置
- 在事件驱动可自动触发构建（比如：使用gerrit、gitlab等带有钩子的代码仓库）的项目中，不同配置构建的时候不想一次触发就所有配置都并行构建，希望一个接一个构建的：可以通过multi-configuration project 中勾选“Run each configuration sequentially" 来实现
Android项目中使用
- 如果工程还是Ant工程，multi-configuration project可以帮你并行编译，节省编译时间
- 如果工程已经是gradle的，除非想不同配置依次编译（我想大多数情况大家应该都不需要），否者不适用：以上面提到的工程为例，同样是编译5个配置的apk，利用的gradle的flavor，一次gradle build，耗时4分29秒，而用multi-configuration 并行的跑，却耗时7分16秒。原因就是上面提到的multi-configuration的执行过程，相比gradle的build flavor打包流程的效率低。
- 如果使用的是比较老版本的android plug，而又有多个配置都要编译，并且你还需要搜集一下每个编译过程中的文件。比如：有多个不同flavor的relase版本需要编译，每个的代码混淆后的mapping文件你都需要搜集，那利用multi-configuration只需在项目配置里面archive workspace里面的mapping文件即可，在构建后的各个配置对应的目录里面它们就乖乖的在那里了。不过，这个需求还是用最新的android gradle plugin吧，因为目前它已经改变了，不在是所以flavor共用一个输出文件夹，而是生成和flavor一一对应的文件夹，这样你用一个普通的freestyle项目就可以了，只需要在最后archive不同目录下的mapping文件即可
iOS项目中使用
可以大大提高编译效率，即使在配置的iOS编译机单机性能不强的情况下，只要slave数量*executors 的值大于等于一个multi-configuration project里面的matrix数量，一次代码提交到所有matrix打包完，耗时1分钟是完可能的。以目前的项目为例：3台mac mini，2core 8G, 以前在一个普通project里面通过增加多个build 步骤打包4个配置的ipa，总耗时16分钟；用multi-configuration并行打包，只耗时7分钟。
零配置的Multi-configuration Project == 普通的Project？
可以说是：因为你不加任何配置，那整个项目的设置和普通的freestyle的项目没什么区别。
也可以说不是：运行起来的机制不同，它会在构建的时候使用一个默认配置来跑，相关的文件、结果都在其下。构建的时候你会发现有一个executor在同时跑两个任务，具体的影响好没有去看，不过作为强迫症者，表示不能忍。
test_mult相当于主任务
网友评论