こんにちは。テクマトリックスの長久保です。
Jenkinsは長年の歴史を持ち、現在でも過去に作成されたフリースタイルジョブが現役で稼働しているケースが多くみられます。
Jenkinsで稼働しているジョブの種類と数はhttps://stats.jenkins.io/statisticsで確認できます。ページ上ではジョブの種類がクラス名で表示されるため少々わかりづらいですが、ブログ作成時(2025/1/27)に公開されている最新のデータである2024年10月の内容を確認すると、数が多い順に以下になります。
| クラス名 | ジョブタイプ | 数 |
|---|---|---|
| org-jenkinsci-plugins-workflow-job-WorkflowJob | パイプライン | 55,407,946 |
| hudson-model-FreeStyleProject | フリースタイルジョブ | 20,610,423 |
| com-cloudbees-hudson-plugins-folder-Folder | フォルダ | 2,963,849 |
| org-jenkinsci-plugins-workflow-multibranch-WorkflowMultiBranchProject | Multibranch Pipeline （パイプライン) | 2,109,309 |
上記のように、2024年10月時点でも3割程度がフリースタイルジョブで稼働していることが分かります。
今回は、Jenkinsを利用したCI/CD環境構築において、公式でも推奨されている「パイプライン」、特に「宣言型パイプライン(Declarative Pipeline)」について、その魅力と具体的な活用方法を掘り下げてご紹介します。
目次
フリースタイルジョブ
フリースタイルジョブは、Jenkins登場当初からある基本的なジョブタイプで、GUIを使って手動で設定を行います。ビルド手順やテストの設定、通知や成果物の保存などを簡単に構築できるため、小規模で単純なジョブに適しています。
ただし、フリースタイルジョブでCI環境を構築した場合、以下のような課題が考えられます。
フリースタイルジョブの課題
- ジョブの管理が煩雑
フリースタイルジョブは1つのジョブに1つの役割を持たせるのが基本となります。たとえば「ソースコードをGitから取得しMavenでビルドをする、単体テストをする、検証環境にデプロイする、UIテストをする」というタスクに対して、それぞれフリースタイルジョブをGUIで設定することになります。
小規模の運用であれば問題ないかもしれませんが、プロジェクトが増えてジョブが数十、数百単位になると管理が大変になります。何をやっているジョブなのか、どのジョブが関連しているのかという把握も難しいですし、設定変更の反映漏れや、設定ミスも起こりやすくなります。フォルダやジョブの命名規則での運用も限度があるでしょう。 - 突然動かなくなったときに原因追跡が難しい
Job Configuration Historyプラグインを用いれば、Jenkins上で変更履歴を追跡することはできますが、変更内容の詳細な比較や、変更理由の記録などを管理することはできません。
例えばあるフリースタイルジョブが数日前まで正常に動作していたにも関わらず、突然エラーが発生するようになったとします。誰がいつ、どのような設定変更を行ったのかをGUIの履歴から追跡するのは手間がかかり、原因特定に時間がかかってしまいます。 - 他のプロジェクトに展開する際の手間
他のプロジェクトへ設定を再利用する場合、フリースタイルジョブの場合、「コピー＆ペースト」のような簡単な操作で設定を丸ごと移行することはできず、都度GUI上で設定する必要があります。手作業による転記作業は、タイプミスや設定漏れといった人的ミスが発生しやすいというリスクがあります。 - 属人化しやすい
複数のジョブを連携しているような環境だと、担当者以外は設定内容を把握しづらく、ノウハウが特定の担当者に偏りがちになります。GUIで設定された内容は、一覧性や検索性が低く、ジョブ全体の構成や詳細な設定内容を把握するのがより難しくなります。担当者が不在になった場合、ジョブのメンテナンスやトラブルシューティングが難しくなります。 - Gitブランチの増加に伴う課題
フリースタイルジョブは、基本的にジョブの設定が静的であるため、ブランチが増えるごとに都度ジョブを作成する必要があります。また、featureブランチ、releaseブランチ、mainブランチなど、ブランチごとに異なったテストやデプロイ処理等を実行したい場合、ブランチの作成の都度、個別のフリースタイルジョブを作成する必要が出てきます。これでは快適なCI/CD環境とは言えません。 - 複数開発環境でのビルドにおける課題
同じコードに対して、異なるバージョンの開発環境（例：Java 17と21）でビルドやテストを行いたい場合も、フリースタイルジョブではJava 17でビルドするジョブ、Java 21でビルドするジョブといったように、環境ごとに個別のフリースタイルジョブを作成する必要があります。これにより、前述のブランチ管理と同様にジョブ数が増加し、管理が煩雑になります。 - CI/CD環境構築に対しての機能不足
CI/CD環境を構築するにあたり、フリースタイルジョブの標準機能だけでは実現が難しいこともあります。例えば管理者の承認を待って処理を行うということや、特定の処理の実行結果に応じて実行する処理やジョブを切り替えるということもできません。
これらの課題に該当されているJenkins管理者も多いのではないでしょうか。これ以外にもフリースタイルジョブの課題はありますが、これらの課題のためフリースタイルジョブを用いてのCI環境は不向きであることがわかるかと思います。
こういった背景もあり、Jenkins 2.0以降ではPipeline（パイプライン）という仕組みが登場しました。パイプラインにより、ジョブの処理やフローをコードとして管理することが可能になりました。
パイプラインとは
Jenkinsのパイプラインとは、コードのビルド、テスト、デプロイなどを自動化するための一連のステップを定義するスクリプトです。これにより、CI/CDを効率的に実現できます。
パイプラインの最大のメリットは、CI/CDの設定をコードとして管理できることです。このコードはJenkinsfileというファイルに記述します。
パイプラインには以下の2種類があります。
- スクリプトパイプライン(Scripted Pipeline)
Groovyベースのスクリプト形式で、非常に自由度が高い。 - 2.宣言型パイプライン(Declarative Pipeline)
スクリプトパイプラインより制限された形式で、構文がシンプルかつ可読性が高い。
スクリプトパイプラインと比較した場合の宣言型パイプラインの優位性
スクリプトパイプラインはGroovyで実装可能な範囲であれば、複雑な処理も記述できる反面、習得コストが高いという側面があります。一方、宣言型パイプラインは、よりシンプルで分かりやすい構文を採用しており、Groovyの知識がなくても比較的容易に記述できます。
また、構造化されているため、パイプライン全体の構成が把握しやすくなります。それ以外にも構文エラーなどを早期に検出する機能が強化されています。
これらのことから、現在は宣言型パイプラインが推奨されています。
本ブログでも宣言型パイプラインを元に記載します。
実際の宣言型パイプラインの書き方
まずは、シンプルにechoを用いたサンプルで基本構造を紹介します。
pipeline {
agent any
stages {
stage('Build') {
steps {
echo "ビルドコマンドを記載"
// 例: sh 'mvn clean install'
}
}
stage('Test') {
steps {
echo "テストコマンドを記載"
// 例: sh 'mvn test'
}
}
stage('Deploy') {
steps {
echo "デプロイを実行"
// 例: sh 'scp target/myapp.jar user@server:/deploy/path'
}
}
}
}
宣言型パイプラインはpipelineブロックから始まり、次の構造を取ります。
pipeline {}ブロック内で、全体の構成を記述します。agent any：グローバルエージェントの指定です。anyは「Jenkinsの実行環境（エージェント）を任意に指定する」という意味になります。特定のエージェントに固定したい場合はagent { label 'my-agent-label' }のように書き換えます。stages {}の中で各ステージを定義します。ビルド、テスト、デプロイといった流れをステージ単位で整理することで、パイプラインの実行プロセスが視覚的にも分かりやすくなります。steps {}の中で実際の処理を記載します。
詳細な構文については、Pipeline syntaxのページを参照ください。
パイプラインのメリット
このようにJenkinfileで開発プロセスを定義することで、フリースタイルジョブで挙げられていた以下の課題が解決が期待できます。
1.ジョブの管理が煩雑
Jenkinsfileは、CI/CDの実行フローをコードとしてテキストファイルに記述します。これにより、ジョブの設定がGUI上に散在することがなくなり、Jenkinsfileという単一のファイルを見るだけで、そのジョブの全体像を把握することが可能になります。(部分的にJenkinsのGUIで設定する内容もあります)。
また、ビルド、テスト、デプロイといった開発プロセス全体を1つのジョブで定義することができるため、膨大なジョブ数を管理することもなくなります。
ジョブの実行結果についての視認性も高いです。パイプラインジョブの視認性については、以下ブログを併せて参照ください。
2.突然動かなくなったときに原因追跡が難しい
Jenkinsfileはテキストファイルのため、他のソースコードと同じようにバージョン管理システムで管理できます。過去のコミットログを参照することで、いつ、誰が、どのような目的で設定を変更したのかを正確に追跡できます。これにより、ジョブが突然動かなくなった場合でも、直近の設定変更履歴を確認することで、原因の特定を迅速に行うことが可能になります。
3.他のプロジェクトに展開する際の手間
Jenkinsfileを共有することで、同じCI/CDパイプラインをほかのプロジェクトに対しても簡単に展開できます。ビルドコマンドやテストスイートなどプロジェクト固有の設定値は、環境変数やパラメータとして定義することで、Jenkinsfile本体を修正することなく、柔軟にカスタマイズすることもできます。複数のプロジェクトで共通のCI/CD基盤を効率的に構築・運用することが可能になります。
また、共有ライブラリという仕組みを用いることで、よりほかのプロジェクトに展開しやすいパイプラインを構築することも可能です。
4.属人化しやすい
フリースタイルジョブでは、GUIの各設定項目を個別に確認する必要がありましたが、Jenkinsfileでは、CI/CDのプロセスや設定をコードとして記載するため、フリースタイルジョブと比較した場合、可読性や視認性が高いです。フリースタイルジョブと比較し、特定の担当者しか設定内容を理解できないという状況を回避しやすくなります。
5.Gitブランチの増加に伴う課題
フリースタイルジョブで挙げられていたGitブランチの増加に伴う課題も、JenkinsのMultibranch Pipelineを活用することで効果的に解決できます。
Multibranch Pipelineは、新しいブランチが作成されると、Jenkinsが自動的にそのブランチ用のパイプラインジョブを作成します。ブランチが削除されると、対応するパイプラインジョブも自動的に削除されるため、不要なジョブが残り続ける心配がありません。また、プルリクエストやマージリクエスト等の機能にも対応しています。
また、それ以外にも1つのJenkinsfile内でwhenディレクティブを使用することで、特定のブランチでのみ実行される処理を定義できます。これにより、例えば mainブランチではデプロイとUIテストを実行するが、それ以外のブランチの場合スキップするといった処理も1つのパイプラインで実装できます。
6. 複数開発環境でのビルドにおける課題
フリースタイルジョブのように、Java 17用、Java 21用と環境ごとにジョブを複製する必要はなく、単一のJenkinsfileで複数の開発環境に対応したビルドプロセスを定義できます。これにより、ジョブ数の増加を抑え、管理の煩雑さを大幅に軽減できます。
pipeline {
agent none
stages {
stage('Build with Java 17') {
agent { label 'java17' }
steps {
echo "Building with Java 17"
}
}
stage('Build with Java 21') {
agent { label 'java21' }
steps {
echo "Building with Java 21"
}
}
}
}
}
agent { label 'java17' }やagent { label 'java21' }のように実行するagentを指定すると、stage内の処理は指定したエージェントで実行されます。
7.CI/CD環境構築に対しての機能不足
ユーザーからの入力を待機するinputディレクティブや、パイプラインの実行結果に応じて処理を切り替えることができるpostセクション等、CI/CD環境を構築するうえで必要な機能の多くが標準機能として用意されています。
またそれ以外にも、パイプライン処理内の並列実行等、より柔軟にCI/CD環境を構築することが可能です。
フリースタイルジョブからパイプラインへの移行
フリースタイルジョブから宣言型パイプラインへの移行手順を、シンプルな例を交えながら解説します。
移行対象のフリースタイルジョブ
移行対象のジョブとして、以下の2つのフリースタイルジョブを用意します。
〇ジョブ名:ProjectA_build
- ソースコード管理
Gitを選択し、チェックアウトする対象や認証情報を選択。処理対象のブランチはmainブランチ - Build Steps
Windowsバッチコマンドの実行
コマンド: echo “exec build” - ビルド後の処理
他のプロジェクトのビルド。対象プロジェクト:ProjectA_test
〇ジョブ名：ProjectA_test
- Build Steps
Windowsバッチコマンドの実行 - コマンド
echo “exec test”
このジョブをパイプラインに移行します。
プラグインを活用しての移行
フリースタイルジョブから宣言型パイプラインに移行するためのプラグインが存在します。
Declarative Pipeline Migration Assistant
プラグインをインストールすると、フリースタイルジョブのサイドパネルにTo Declarativeメニューが表示されます。こちらをクリックすることで宣言型パイプラインに変換できます。
注意事項
このプラグインは「対象のフリースタイルジョブを宣言型パイプラインに変換する」のみのため、複数のフリースタイルジョブを自動で結合し宣言型パイプラインにすることはできません。
ProjectA_buildにはビルド後の処理としてProjectA_testが設定されています。この場合、ProjectA_build、ProjectA_testが実行される1つのジョブが作成されるのではなく、赤く囲った箇所の様に、ProjectA_testのジョブを呼び出す形で実装されます。この方法で移行した場合、宣言型パイプラインに変換したProjectA_build、ProjectA_testという2つのジョブが作成されることになります。
また、こちらのプラグインで対応されているプラグインには制限があります。対応されていないプラグインがフリースタイルジョブで利用されていた場合、警告が表示されます。
サポートされているプラグインと、警告の種類については、以下のページを参照ください。
Converting a Freestyle project to a Declarative Pipeline
Declarative Pipeline Migration Assistantプラグインの使用方法については、こちらのブログでも紹介されているので、併せてご確認ください。
フリースタイル ジョブを宣言型パイプラインに変換する
Blue Oceanプラグインを活用する
次に、複数のフリースタイルジョブを1つのパイプラインジョブに移行する方法を紹介します。
ただ、Jenkinsfileの構文を理解して、直接コードを書いて移行するというのは、初学者にとって少しハードルが高いかと思います。Blue Oceanプラグインを用いることで、より直感的にGUIでパイプラインを作成することが可能です。
移行の準備
- ステージを定義する
宣言型パイプラインでは、ビルド、テスト、デプロイといった流れをステージ単位で整理することで、パイプラインの実行プロセスが視覚的にも分かりやすくなります。
今回の場合、buildステージと、testステージに分けるのが良いでしょう。 - 具体的な処理を理解する
パイプラインの具体的な処理はsteps内に記載します。フリースタイルジョブで設定していたビルドスクリプト実行ステップを、パイプラインのstepsに移行します。
今回の場合はechoで文字列を出力するだけですが、実際の環境では様々なことを行っている場合があるので、フリースタイルジョブの設定を確認し、各ステージでどういった処理を行うのかを整理します。
今回は以下のようにパイプラインを定義します。
- buildステージ：echo “exec build”を実行する
- testステージ：echo “exec test”を実行する
実際にBlue Oceanで宣言型パイプラインを作成する。
Blue Oceanプラグインをインストールすると、サイドパネルにOpen Blue Oceanというメニューが表示されます。ここからBlue Oceanを起動します。
画面右上の「New Pipeline」からジョブを作成します。画面の案内通り、連携先のGit、認証情報を登録していきます。
登録を行い、編集画面に遷移すると、次のようにパイプライン作成画面に遷移します。
GUIを用いて、直感的にパイプラインを作成することが可能です。
Blue Oceanの詳細な利用方法については、こちらを参照下さい。
Jenkinsfileの管理
Blue Oceanで「Save & Run」を実行すると、GUIで設定した内容がJenkinfileに変換され、連携したGitに登録されます。
Blue Oceanを利用する際の注意
Blue Oceanプラグインは宣言型パイプラインを作成するために非常に有効なツールですが、すべての設定をBlue Ocean上で行うことはできません。例えば、Blue Oceanで設定できるstepには限りがあります。
それ以外にも、whenディレクティブやpostセクションなど、Blue Ocean上で設定できない構文も存在します。また、Blue Oceanプラグインについては、今後重大なセキュリティ問題または機能上の欠陥以外の機能実装はされないことがアナウンスされています(Blue Ocean status)。
個人的には、ステージやステップの大まかな枠組みをBlue Oceanで作成し、細かい部分については直接Jenkinsfileで編集する方法をお勧めします。
移行のポイント
- まずはステージ、ステージ内の処理を明確化
今回はbuildステージ、testステージとシンプルでしたが、実際の環境ではより複雑なフリースタイルジョブが運用されている場合もあるかと思います。まずはどういったパイプラインを作成するのか設計が必要です。 - Blue Oceanを用いて移行
Blue Oceanを用いてフリースタイルジョブで設定していたビルドスクリプト実行ステップを、パイプラインのstepsに移行します。 - カスタマイズ
視認性向上のためテストを細かくステージ分けしたり、並列実行を導入してみるのも良いでしょう。またそれ以外にも有用なオプション、ステージ等もありますので、Pipeline Syntaxのページを確認しながら実装を勧めるとよいでしょう。
まとめ
- フリースタイルジョブは簡単なジョブには向いているが、管理や追跡が困難になりやすい
- パイプライン（特に宣言型パイプライン）を使うと、ジョブの定義をコードとして管理・バージョン管理できたり、テストの並列化やプラグイン連携など、機能拡張が容易なのでメリットが多い
- スクリプトパイプラインに比べ、宣言型パイプラインは構文がシンプルで分かりやすいため、新規で作成する場合は宣言型パイプラインを推奨。
- フリースタイルジョブからの移行は少しずつステップを分割しつつ、Jenkinsfileを作り込んでいくとスムーズ
CI/CD環境の効率化において、Jenkinsパイプラインは非常に強力な手段です。初めて使う場合は、今回のサンプルを元に小さなパイプラインを組んでみるのがおすすめです。自動ビルドや自動テスト、デプロイをコード一元管理できる利便性を、ぜひ体験してみてください。
パイプラインを本格的に学習したい場合
もしパイプラインについて体系的に学習したい場合は、弊社にてJenkinsのトレーニングを実施しています。本日紹介したパイプラインや、よりメンテナンスのしやすい共有ライブラリを学習するコースもありますので、ぜひご活用ください。
Jenkinsトレーニング
Jenkins 管理-基礎
本コースは、Jenkinsインスタンスをセットアップし実行するための基礎知識を習得することを目標としたコースです。
パイプライン基礎
本コースは、初級および中級開発者向けに、Jenkinsの宣言型パイプラインの作成・変更方法、パイプラインの構造、実行フローの制御方法などを習得することを目標としたコースです。
講師がデモ用のプロジェクトを使用してやり方を示した後同じ操作を行うことで、ツールの感触をつかむことができます。さらに、ラボプロジェクトを使用して演習を行うことで、パイプラインを実装する実践的な方法を理解することができます。
パイプライン中級
本コースは、中級開発者やビルドおよびリリースエンジニア向けに、共有ライブラリを使ってJenkins宣言型パイプラインを作成および実行する方法を学習することを目標としたコースです。パイプラインコードの共有と再利用が可能になるだけでなく、コードの野放図な拡大を管理したりチームのサイロ化を防止する方法を、講義と演習により理解することができます。
フリースタイルジョブからの移行を依頼したい場合
弊社ではCI/CD環境構築サービスも実施しております。今回の様なフリースタイルジョブからの移行や、新規でのパイプライン作成等、幅広く対応することができますので、お気軽にお問い合わせください。
