Jenkinsのスクリプト型パイプラインと宣言型パイプライン

1. 概要

「Pipeline-as-code」は、DevOpsに関係するすべての人がJenkinsパイプラインを作成および維持できるようにするためのアイデアです。 実際、t は、この「コードとしてのパイプライン」の原則を実際に適用する2つの方法です。スクリプトパイプラインと宣言型パイプラインです。「pipeline-as-code」を使用すると、Jenkinsはパイプラインを通常のファイルとして扱うことができます。 DevOpsに関係する人々は、これらのファイルをSCMで保存、共有、および使用することができます。

2. 宣言型パイプラインとその利点

宣言型パイプラインは、「コードとしてのパイプライン」の原則に対する最近のアプローチです。記述と理解は非常に簡単です。構造は少し複雑に見えるかもしれませんが、全体として、いくつかの基本的なセクションしか含まれていません。「パイプライン」ブロックは、パイプラインの宣言全体を含むメインブロックです。この例では、の「エージェント」、「ステージ」、および「ステップ」のセクションのみを検討します。

pipeline –パイプライン全体が含まれています
- agent –このパイプラインを処理するマシンを定義します
- stages –パイプラインのステージを宣言します
  - ステップ–特定のステージ内の小さな操作

この構造が宣言型パイプラインでどのように見えるかを確認しましょう。

pipeline {
    agent any
    stages {
        stage('Hello World') {
            steps {
                sh 'echo Hello World'
            }
        }
    }
}

宣言型パイプラインのもう1つの重要な部分は、directivesです。実際、ディレクティブは追加のロジックを含めるための便利な方法です。これらは、ツールをパイプラインに含めるのに役立ち、トリガー、環境変数、およびパラメーターの設定にも役立ちます。一部のディレクティブは、ユーザーに追加情報の入力を求めることができます。 これらのディレクティブの作成に役立つ使いやすいジェネレーターがあります。

前の例では、「steps」はステージで実行されるロジックを含むディレクティブです。ステップを作成する便利な方法を提供する専用のスニペットジェネレーターがあります。

宣言型パイプラインの能力は主にディレクティブから得られます。宣言型パイプラインは、「script」ディレクティブを使用してスクリプト化されたパイプラインの能力を活用できます。このディレクティブは、スクリプト化されたパイプラインとして内部の行を実行します。

3. スクリプト化されたパイプラインとその利点

スクリプト化されたパイプラインは「pipeline-as-code」原則の最初のバージョンでした。Groovyを使用したDSLビルドとして設計され、卓越したレベルの電力と柔軟性を提供します。ただし、これにはGroovyの基本的な知識も必要であり、これは望ましくない場合があります。

これらの種類のパイプラインでは、構造に対する制限が少なくなります。また、「ノード」と「ステージ」の2つの基本ブロックしかありません。「ノード」ブロックは特定のパイプラインを実行するマシンを指定しますが、「ステージ」ブロックは、一緒に実行されたときに個別の操作を表すステップをグループ化するために使用されます。 追加のルールとブロックがないため、これらのパイプラインを非常に簡単に理解できます：

node {
    stage('Hello world') {
        sh 'echo Hello World'
    }
}

スクリプト化されたパイプラインを宣言型パイプラインとして考えますが、ステージのみを使用します。この場合の「ノード」ブロックは、宣言型パイプラインの「パイプライン」ブロックと「エージェント」ディレクティブの両方の役割を果たします。

前述のように、スクリプト化されたパイプラインのステップは、同じスニペットジェネレーターで生成できます。このタイプのパイプラインにはディレクティブが含まれていないため、ステップにはすべてのロジックが含まれます。非常に単純なパイプラインの場合、これによりコード全体を削減できます。

ただし、一部の定型文のセットアップには追加のコードが必要になる場合があります。これは、ディレクティブで解決できます。 このようなパイプラインのより複雑なロジックは通常Groovyに実装されています。

4. スクリプト化されたパイプラインと宣言型パイプラインの比較

gitからプロジェクトをプルし、テスト、パッケージ化、デプロイする3ステップのパイプラインを確認してみましょう。

pipeline {
    agent any
    tools {
        maven 'maven' 
    }
    stages {
        stage('Test') {
            steps {
                git 'https://github.com/user/project.git'
                sh 'mvn test'
                archiveArtifacts artifacts: 'target/surefire-reports/**'
            }
        }
        stage('Build') {
            steps {
                sh 'mvn clean package -DskipTests' 
                archiveArtifacts artifacts: 'target/*.jar'
            }
        }
        stage('Deploy') {
            steps {
                sh 'echo Deploy'
            }
        }
    }
}

ご覧のとおり、すべてのロジックは「ステップ」セクション内にあります。したがって、この宣言型パイプラインをスクリプト化されたパイプラインに変換する場合、これらの部分は変更されません。

node {
    stage('Test') {
        git 'https://github.com/user/project.git'
        sh 'mvn test'
        archiveArtifacts artifacts: 'target/surefire-reports/**'
    }
    stage('Build') {
        sh 'mvn clean package -DskipTests' 
        archiveArtifacts artifacts: 'target/*.jar'
    }
    stage('Deploy') {
        sh 'echo Deploy'
    }
}

同じ機能のスクリプト化されたパイプラインは、宣言型のパイプラインよりも密度が高くなります。ただし、サーバー上ですべての環境変数が正しく設定されていることを確認する必要があります。同時に、Mavenのバージョンが複数ある場合は、パイプラインで直接変更する必要があります。このために、具体的なパスを直接使用することも、環境変数を使用することもできます。

スクリプト化されたパイプラインで役立つ「withEnv」ステップもあります。一方、宣言型パイプラインでは、Jenkins構成のツールのバージョンを変更するのは非常に簡単です。

前の例は、単純な日常のタスクの場合、これらのアプローチにほとんど違いがないことを示しています。ステップがパイプラインのすべての基本的なニーズをカバーできる場合、これら2つのアプローチはほぼ同じになります。宣言型パイプラインは、いくつかの一般的なロジックを単純化できるため、依然として好まれています。

5. 結論

スクリプト化されたパイプラインと宣言型パイプラインは同じ目標に従い、内部で同じパイプラインサブシステムを使用します。それらの主な違いは、柔軟性と構文です。 これらは同じ問題を解決するための2つの異なるツールであるため、これらを交換して使用することができ、使用する必要があります。

宣言型パイプラインの簡潔な構文により、このフィールドへのより迅速でスムーズな入り口が保証されます。同時に、スクリプト化されたパイプラインは、より経験豊富なユーザーにより多くのパワーを提供する可能性があります。 両方の世界を最大限に活用するために、スクリプトディレクティブを使用して宣言型パイプラインを活用できます。