背景
Jenkins 2.0开始推行Pipeline as Code,实现从CI到CD的转变。 Pipeline实际上是一套Groovy DSL,用Groovy脚本描述CI/CD的流程,Jenkins可以从代码库中获取脚本,实现了Pipeline as Code。Pipeline将原来独立运行的多个任务连接起来,可以实现更加复杂的CI/CD流程。
一个新东西的出现,必然有它适合的场景或者它能解决的痛点。相信很多公司的CI/CD都是围绕jenkins构建的,随着项目的增多,jenkins中配置的项目Job会越来越多,job的生命周期无法跟踪,master是整个系统的单点,job无法快速迁移,有些job需要耗时很久等等问题,Pipeline就是为解决这些问题诞生的。
特性
Pipeline以代码实现,通常会被检入到scm管理中,使团队能够编辑、审阅和迭代其部署流水线Pipeline可以在Jenkins master被计划重启或意外重启之后继续存在。Pipeline在继续运行之前,可以选择停止并等待人员的输入或批准。Pipeline支持复杂的真实CI/CD需求,包括fork/join、loop及并发任务。Pipeline插件支持对其DSL的自定义扩展,以及与其他插件集成的多个选项。
ps:以上特性都是官方自吹自擂的,在我看来就第一点最为重要,pipeline as code
配置模式
Pipeline的配置方式有两种模式:declarative和script
script:在web界面直接编写脚本,不好移植,和1.x的使用方式一样,只是编写脚本的语言不一样
declarative:是编写在一个名叫jenkinsfile的文件中的,可以跟随scm进行版本控制,2.x真正的精髓所在
ps:本文主要以jenkinsfile为主要实验对象
jenkinsfile
pipeline { agent any parameters { choice(name: 'CHOICE',choices:['dev','stg','prd']) } environment { name = 'dalu' } options { timeout(time: 1, unit: 'HOURS') retry(2) } stages { stage('Checkout') { steps{ echo 'Checkout blue-test' checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: 'xxx', url: 'http://xxx/bule-test.git']]]) } } stage('Build') { parallel { stage('Build1') { input { message "should we continue" ok "yes,we should" } steps { echo 'Build 1' } } stage('Build2') { steps { echo 'Build 2' } } } } stage('Test') { steps { echo 'Testing..' echo "$BRANCH_NAME" echo "$BUILD_ID" echo "$BUILD_DISPLAY_NAME" echo "$JOB_NAME" echo "$BUILD_TAG" echo "$JENKINS_HOME" } } stage('Deploy') { steps { echo 'Deploying....' echo "Choice: ${params.CHOICE}" sh 'tar czvf tt.tgz kafka_tomcat_alter.py' } } } post { always { echo 'i will always run...' } }}
实战