Jenkins已经成为大量公司最常用的一种持续集成工具了,但是目前pipeline的普及程度可能依然低于30%,大量的团队依然使用自由风格这种笨重的方式,给统一构建过程、构建集中管理带来极大的不便。笔者通过下面的18个问题来讲解一下为什么企业级持续集成服务需要使用pipeline的构建方式。
很多人认为jenkins2.0的最大改变是增加了pipeline,实际上pipeline在Jenkins1.0中已经有了这个概念,而jenkins2.0中最大的改变应该是pipeline as code,即以代码的方式描述pipeline。
由于pipeline编写需要代码能力 ,并且pipeline的中执行步骤直接影响了最后构建产物的质量,所以建议pipeline需要由持续集成服务部门统一编写、统一管理。此持续集成服务部门可以由工程效能团队、测试团队、ci团队等兼任。编写好的pipeline需要标记模版的使用方法和作用,需要相关的文档或者json串记录模版的这些属性,那么业务部门就可以自助的使用这些模版 ,并在无形之间执行了我们在模版中设置的一些质量扫描测试的工作,并收集回了整个软件生命周期的元数据,用于我们对业务的质量进行评判。
由统一的持续集成服务部门编写pipeline的模版和所需的类库,将这些模版和类库存放到gitlab等源码仓库中统一进行版本控制管理。并将源码地址配置到jenkins的Share Library的功能中,业务开发人员如需Jenkins进行构建,只需传递自己所需的参数,调用持续集成服务部门已经写好的library,就可以自行设置构建任务了。
Git仓库保存流水线模版:
Pipeline中引用模版:
声明式pipeline比较简单,也是Blue Ocean支持的语法格式,但此种pipeline在jenkins2.5之后才支持,成熟度有待发展,是官方推荐的方式。
Jenkins2.0最早支持 的pipeline,如果对Groovy语法很熟悉,可选择脚本式pipeline,可以实现更复杂的逻辑。
Jenkins2.0中提供了流水线语法查询的功能,可以自动生成流水线代码片断,直接拷贝粘贴就可以
Pipeline一般的应用是来做集成构建的,也就是把源码打包成制品,所以pipeline中涉及的最基础的工具一定是源码仓库和制品仓库,以及构建过程中使用的每种语言的打包工具。
源码仓库:用于管理源代码,常用gitlab、github、svn等
制品仓库:用于管理制品,常用Artifactory。
打包工具:如mvn、go、npm、docker等
Jira:关联需求信息
Sonarqube:代码静态扫描
Xray:制品漏洞扫描
JMeter:性能测试
Junit:单元测试
JaCoCo:代码覆盖率
Ansible,saltstack:发布
质量关卡,即构建过程中的质量门,为确保每一个版本都能高质量发布,建议将以下指标与部署包关联,作为整个pipeline构建过程的质量关卡,如果有未达到的情况,记录并处理。关卡包括:
代码静态扫描的issue数量
80%以上的单元测试覆盖率
漏洞扫描的结果
开源许可证扫描
不同环境是否具备不可变基础设施
集成测试是否通过
性能测试结果
较高的接口测试覆盖率
DevOps成熟度标准中建议做到一次构建,多次部署。目的是为了在测试环境测过的包可以在不改变任何环境和依赖的情况下发布到生产线上。发布时重新打包往往会因为源码版本变更、基础环境变更等因素导致发布事故。
最佳实践是使用制品提升仓库级别的方案,使用Artifactory可以用起promotion的属性进行制品提级。
Jenkins支持参数化构建,包括凭据参数、字符参数、密码参数、布尔值参数、文件参数、文本参数、运行时参数、选项参数等。在pipeline中设置方法可以直接在片断生成器中生成。(语法获取可以使用片段生成器,搜properties)
Jenkins pipeline支持并行构建任务,解决多个环境进行构建,或多个环境进行发布的场景。使用串行十分影响效率,采用并行方式,通常是将命令下发给不同的agent,节省构建时间。(语法获取可以使用片段生成器,搜parallel)
Pipeline中经常涉及到这样一种场景,需要调用其他系统的api,难免会使用到一些key或者密码 ,但是这些信息直接明文写到pipeline中非常不优雅,并且存在很大的安全隐患,所以在我们不希望展示这些key的场景下,可以使用Jenkins的凭证特性,解决这种问题 。(语法获取可以使用片段生成器,搜withCredentials)
某些特定场景下,如每天凌晨需要对项目进行一次clean的全量构建,占用的时间和资源较多,我们可以使用Jenkins的构建触发器功能触发定时任务进行构建。(语法获取可以使用片段生成器,搜properties)
此触发方式使用的较少,最佳实践以webhook的方式触发构建更方便,但是在少量特殊场景,如每天需要构建,但是版本不发生变化时不构建可以应用此触发器
在集成测试的时候需要大量的此类操作,公共组件构建了最新的版本要同时触发所有依赖他的构建项目进行构建,确保此版本能正常被业务应用使用。
通过Git的钩子(webhook)功能触发Jenkins构建任务,这种构建模式比较常见,DevOps成熟度标准中也把这一条当作三级评估的准则,是否每一次提交代码都能触发完整的构建过程,决定了我们持续集成的速度和效率。
为实现需要人工校验是否继续进行后续流程,对接审批流程等操作,Jenkins支持了构建等待的功能,可以在构建过程中暂停任务,等待下一步信号。(语法获取可以使用片段生成器,搜input)
在实际的项目中,往往需要多分支同时进行开发,如果每一个分支都创建一个jenkins项目 ,管理起来非常不方便。这种场景下需要使用多分支pipeline。常使用when参数来判断分支。