pipeline：pipeline 使用之 Shared Libraries

前言

随着pipeline交付流水线在团队中的推广，使用pipeline脚本的job也迅速增加。虽然我们已经基于公司的技术栈特点做了一个尽可能通用的pipeline脚本样例，让搭建者只需要修改几个赋值参数就可以在自己的项目中应用，初衷是希望所有人能理解pipeline中的过程，但也发现一些比较麻烦的问题，比如有些人不熟悉具体的脚本拿来随意删改导致各种错误，还有就是我们在pipeline脚本中增加一些新功能时又需要通知所有的pipeline维护人员去修改，过程非常纠结。

这时候就意味着我们需要用到pipline的共享库功能（Shared Libraries）了，在各种项目之间共享pipeline核心实现，以减少冗余并保证所有job在构建的时候会调用最新的共享库代码 。

这篇我们就介绍下pipeline的这个黑科技：Shared Libraries

目录结构

Shared Library通过库名称、代码检索方法（如SCM）、代码版本三个要素进行定义，库名称尽量简洁，因为它会在脚本中被调用，在编写 Shared Library的时候，我们需要遵循固定的代码目录结构。

Shared Library代码目录结构如下：

src目录就是标准的Java源目录结构。执行Pipeline时，该目录将添加到类路径中。

vars目录托管定义可从Pipeline访问的全局脚本(一般我们可以在这里编写标准化脚本)。通常，每个.groovy文件的基本名称应使用驼峰（camelCased）模式，.txt（如果存在）可以包含格式化处理的文档。

resources目录允许libraryResource从外部库中使用步骤来加载相关联的非Groovy文件。目前内部库不支持此功能。

定义全局库

这里只介绍全局 Shared Library的方式,通过Manage Jenkins » Configure System » Global Pipeline Libraries 的方式可以添加一个或多个共享库。

这些库将全局可用，系统中的任何Pipeline都可以利用这些库中实现的功能。并且通过配置SCM的方式，可以保证在每次构建时获取到指定Shared Library的最新代码。

动态加载库

从2.7版本起，Pipeline: Shared Groovy Libraries plugin插件提供了一个新的参数“library”，用于在脚本中加载（non-implicit）库

如果只需要加载全局变量/函数（从vars/目录中），语法非常简单：

此后脚本中可以访问该库中的任何全局变量。

采用此方式从src/目录中引用类也是可以的,不过只能动态地使用库类（无类型检查），从library步骤的返回值通过指定名称访问它们。比如static可以使用类似Java的语法来调用方法：

使用该library步骤时，您还可以指定一个版本,该指定版本将会覆盖默认版本。

Shared Libraries实战

我们在https://testerhome.com/topics/10010已经介绍了一个项目基本样例，可以看到过程已经非常复杂（实际上我们后来还加了很多更复杂的功能），让普通业务工程师管理起来确实有点困难。

通过参数化处理后，除了一些各项目的业务变量，整个过程在所有项目都是通用的，完全适合采用共享库的方式进行改造，屏蔽脚本的复杂度。

在改造之前我们勾画了两种思路：pipeline模块库和模版库（姑且这么叫吧）。

1.模块库方式

模块库的方式，其实就是考虑把各个stage的实现通过函数化的方式抽象出来，比如获取代码的stage实现我们就抽象出codeFetch()，单元测试的 stage我们就抽象出unitTest（）.

特点：业务工程师负责维护pipeline的初始赋值和整体结构，灵活度高，可自主裁剪stage场景

不足：整体结构还是比较复杂，需要维护的共享脚本比较多，无法对交付流水线过程进行统一管理，Declarative Pipeline只支持script部分脚本的共享库。

pipeline代码样例：

共享库代码：

2.模版库方式

Declarative 1.2（released in late September, 2017），开始支持整条Declarative Pipeline作为共享库，使用条件如下：

特点：可以将整条declarative pipeline作为共享库让各个项目调用，业务工程师只需要维护初始化赋值参数即可。

不足：公司技术栈不统一的话，pipeline模版库的适配能力需要比较强（比如可能会出现虚拟机/docker共存，gradle/maven共存等多种情况），可能需要定义多个模版库，不过这些问题通过groovy代码逻辑上应该都可以控制。

pipeline代码样例(敏感信息隐藏)：

共享库代码：

通过这种方式，整个pipeline脚本的实现和复杂度就被封装到Shared Library中。而且如果我要在原来的流水线基础上，新增一个stage的代码比如安全测试，或者需要对原有代码逻辑进行修改，只需要库开发人员修改共享库的功能，相关场景的项目在map赋值时增加相应的赋值参数即可。

后记

Shared Libraries的方式抽象了各种项目之间共享的代码（甚至整条完整的pipeline），有效降低了业务工程师使用pipeline脚本的复杂度。

同时通过外部源代码控制（SCM）的方式，可以保证最新提供的库代码功能可被所有pipeline项目即时使用，在大团队推广和协作过程中可起到非常重要的作用。

主帖直达：https://testerhome.com/topics/9977