DevOps微课 | Jenkins pipeline模版化

点击上方“中兴开发者社区”，关注我们

每天读一篇一线开发者原创好文

一、背景

目前大量项目使用Jenkins Pipeline作为CI的任务编排，使用Jenkins Pipeline带来的好处有：

1.（版本）管理方便；

2.调试方便（通过Reply进行调试）；

3.通过Gerrit trigger + Multibranch插件实现多分支Pipeline自动化。

但是，每个项目CI管理员都需要从头开始学习Pipeline语法，导致项目CI上线有一定难度；编写的脚本五花八门，占用资源不合理或者编排混乱，这种失控状态最终导致整个云CI运作更加困难。

为了解决上述问题，经过几个项目实践，本文提供一种规范化和简化的云CI方法：

1.通过配置文件定义要做的事情（做什么）

2.编写或者复制类似的项目编写的Jenkinsfile（怎么做）

通过这两个步骤，带来的好处显而易见：

（1）项目维护成本降低（功能不丢失）

（2）可控

（3）规范化、模板化

（4）解耦Jenkins（使用其他系统与业务无关）

二、解决方案

虽然Jenkinsfile已经通过groovy脚本语言进行编写，对应到项目的CI,不外呼多组“在某节点上执行某些命令生成某些制品”的执行过程，但是每位CI人员都需要学习groovy语法，成本过高，时间长。实际上上面只需要关心要做的事情，至于怎么做，则交给Jenkinsfile，这样做扩展性、可维护性、规范性均大幅提高。下面从项目配置文件和Jenkinfile两个方面说明各自的用途。

1.项目配置文件

目前常用的配置文件通常采用ini、xml、json、yaml等格式，通过对比分析，yaml作为CI的配置为上选，yaml编写容易、扩展性高、学习使用成本低（10分钟学习即可）。

在配置文件中需要根据业务特点进行抽象描述，只需要描述出Pipeline中各个功能点，实现和串接过程由Jenkinsfile实现。根据CI特点可抽象出：

（1）节点是什么，在哪儿执行

（2）执行什么命令

（3）被执行对象从哪儿来、依赖对象有哪些

（4）产出物是哪些

从上图可以看出，已经将业务模型描述完整，在实际的项目使用中可能有不同的差异，只需要根据需要进行扩展，总之配置文件只需要定义好要做什么即可。其他动作交给jenkinsfile去做；对于不同的项目类型进行抽象，此时可将配置文件模式化，这种方式的复用程度比较高，对于已经有类似项目的模板后，只需要修改业务相关的部分即可。

2.Jenkinsfile

使用Pipeline的项目基本上均会采用Jenkinsfile方式编写，然而能否将CI维护人员能力分层呢，显然可以将维护人员分为开发人员和

业务维护人员：

（1）开发人员负责编写模板和实现对模板的解析

（2）业务维护人员负责维护业务配置

开发人员编写jenkinsfile对config文件进行解析执行，使得业务维护人员不但是业务设计人员也是测试维护人员，维护成本大大降低。

从上图看将Jenkinsfile和config.yaml从repository中检出，Jenkinsfile负责解析配置文件进行工作，只有当现有的业务模型满足不了项目需求，才需要添加配置元素并编写相对应的脚本代码。对于同类型的项目只需要简单修改配置文件即可完成。

三、意义

从项目来看，采用配置和脚本分离方式，有利于CI的稳定，脚本维护成本高于配置文件维护成本; 项目只关注项目CI的定义，不需要考虑如何实现。

从整个云CI来看，将项目分类维护，降低项目上云CI的成本，方便度量以及系统性都会好一些。对将来更换云CI支持软件可以做到无缝切换，例如将CI切换到PaaS平台，那么对于项目来说，不需要关心，这就是分层设计的好处。

 

四、参考资料

YAML 语言教程

http://www.ruanyifeng.com/blog/2016/07/yaml.html?f=tt