신졸 @Toriyabot입니다.
정보계의 학부 출신은 아닙니다만 엔지니어로서 입사해, 최근에는 당사의 CI 환경의 개선을 실시하고 있습니다.
그 과정에서 Jenkins의 Pipeline 기능의 도입을 실시했습니다만, 이것에 대해서 간단하게 소개하고 싶습니다.

Pipeline이란?

Jenkins는 빌드, 테스트, 검사, 배포(일반적으로 빌드 및 일반) 등을 자동화하여 '계속 통합(CI)'을 지원하는 도구이지만 이 자동화된 일련의 흐름을 정의하기 위해 도입되었습니다. 타노가 파이프라인입니다.
작업의 신규 작성 화면에서 선택할 수 있습니다.

빌드 스크립트의 일련의 흐름을 Jenkinsfile에 설명

Pipeline에서는 "빌드"의 흐름을 Jenkinsfile이라는 groovy 기반 DSL로 작성합니다.
groovy의 코드로 쓰는 것으로, 지금까지 설정할 수 없었던 항목도 자유롭게 기술할 수 있고, 무엇보다 복잡해지기 쉬운 일련의 빌드의 흐름을 Jenkinsfile로서 버젼 관리할 수 있는 것이 큰 이점이라고 생각합니다.

Scripted Pipeline 및 Declarative Pipeline

덧붙여서 Pipeline Plugin 2.5까지는 문법으로서 Scripted Pipeline이라는 쓰는 방법이 사용되고 있었습니다만, 2.5 이후는 Declarative Pipeline이라고 하는 쓰는 방법이 추천 되었습니다 (부분적으로 Scripted Pipeline를 섞을 수도 있습니다).
정보를 검색할 때는 Scripted/Declarative의 차이에 주의해야 합니다.

샘플 코드

아래에 표시된 샘플도 Declarative Pipeline 스타일로 작성되었습니다.
코멘트를 많게 했기 때문에 무엇을 하고 있는지는 알기 쉬운 것이 아닐까 생각합니다.

Jenkinsfile

#!groovy
pipeline { // Declarative pipelineであることを宣言する
  agent any // どこで実行するか等の情報(どのノードか、どういうdocker imageかとかを指定する)
  stages {  // Stageを列挙する
    stage('チェックアウト') { 
      steps { // stageは必ずstepsをもつ
        // Slack通知
        // グローバルな環境変数がenvに入っている
        slackSend color: "good", message: "${env.JOB_NAME} - #${env.BUILD_NUMBER} Started! (<${env.BUILD_URL}|Open>)"
        // Githubのprivateリポジトリを使う時は認証情報の記述が必要
        checkout([$class: 'GitSCM', 
          branches: [[name: '*/master']],
          doGenerateSubmoduleConfigurations: false,
          extensions: [], 
          submoduleCfg: [], 
          userRemoteConfigs: [[credentialsId: 'idだよ', url: 'git@hogehoge']]
        ])
      }
    }
    stage('環境設定') {
      steps {
        sh './prepare_env.sh'
      }
    }
    stage('テスト') { 
      parallel { // parallelはstageの直下に書く
        stage('フロントテスト') {
          steps {
            sh './front_test.sh'
          }
        }
        stage('サーバサイドテスト') {
          steps {
            sh './server_test.sh'
          }
        }
      }
    }
  }
  post { // ビルド終了後の処理はここに書く
    always { // ビルド終了後、必ず行う処理
      junit "junit_output.xml" // 出力されたテスト結果ファイルを読み込む
    }
    success { // 成功した場合
      postBuildSlackSend("good", "SUCCESS")
    }
    failure { // 失敗した場合(どこかのステップでエラーを吐いた場合)
      postBuildSlackSend("danger", "FAILURE")
    }
    aborted { // 中断した場合
      postBuildSlackSend("warning", "ABORTED")
    }
    // changed, unstableもあるよ！
  }
}

// 自身で定義した関数の例
def postBuildSlackSend(bar_color, result) { 
  slackSend color: bar_color, message:"${env.JOB_NAME} - #${env.BUILD_NUMBER} ${result} after ${currentBuild.durationString.split(" and")[0]} (<${env.BUILD_URL}|Open>)"
}

코드 설명 지원: 코드 생성기를 사용할 수 있습니다!

그런데, 이 코드를 막상 스스로 쓰면 groovy 모르고 곤란했구나, 같은 기분이 됩니다만, 그러한 사람이라도 곧바로 사용할 수 있도록 코드 스니펫을 자동으로 생성해 주는 기능이 Jenkins에는 붙어 있다 합니다.

작업의 설정 화면에서 Pipeline Syntax라는 링크를 엽니다.

Snippet Generator가 열립니다. 이것은 checkout 처리를 실시하는 코드를 생성하려고 하고 있는 곳입니다.
이러한 필요 사항을 입력하는 것만으로 코드를 생성하는 기능이, 상당한 수, 준비되어 있으므로 의외로 곧바로, 사용할 수 있는 Jenkinsfile이 완성되는 것은 아닐까요.

결과 시각화: Stage View

Jenkins의 권장 플러그인인 Stage View Plugin을 사용하면 파이프라인을 시각화할 수 있습니다.
각 스테이지에서 소요 시간에 로그(의 끝 부분)를 발행할 수 있으며 결과 요약을 쉽게 확인할 수 있습니다.
어느 스텝에 시간이 걸리고 있는지 일목요연이므로, CI의 고속화를 목표로 하는 경우 등에 매우 편리합니다.

요약

Pipeline을 사용하면 빌드의 흐름을 코드로 관리할 수 있을 뿐만 아니라, 바삭바삭과 병렬 처리를 쓸 수 있거나 복수 머신을 건너는 것 같은 처리도 간단하게 쓸 수 있다고 하는 이점이 있습니다. 그 밖에도 빌드 도중에 Jenkins가 종료해도, Pipeline으로 작성한 작업이라면 Jenkins가 도중에 종료해 버려도, Jenkins를 재시작하면 작업을 계속할 수 있게 되어 있습니다.

소감

실제로 파이프라인의 작업을 운용해 보고, 한정된 계산 자원밖에 없는 가운데, 병렬 처리를 실시해 빌드의 실행 시간을 짧게 할 수 있었던 것은 좋았습니다. 또 GUI로 실시하는 대량의 설정을 코드에 떨어뜨려 버젼 관리할 수 있게 된 것은 안심감이 있었습니다. Stage View도 현대적인 UI로 좋네요.

여러분도 Pipeline에서 편안한 Jenkins 생활을 보내자!