背景
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...'
}
}
}
實戰