序文

近年、Docker、Kubernetes、Helmといったクラウドネイティブ技術が隆盛を極めています。Jenkinsは、オープンソースコミュニティの貢献やCloudBeesなどのチームによるサポートを受け、技術トレンドに追随し、Docker、Kubernetes、Helm、AWSなどに統合されたプラグインやツールを開発しています。Jenkins Xも開発され、設定ページの「ノード管理」セクションはひっそりと「ノードとクラウドの管理」へと生まれ変わりました。一方、自社開発力の高い企業もJenkins APIをベースとしたDevOps CI/CDプラットフォームを開発しており、「おじさん」Jenkinsは若返り、非常に良好な結果をもたらしています。

Jenkinsはオープンソースであること、豊富なプラグインライブラリ、そして容易な学習曲線を備えているため、優れた選択肢となります。少なくともリソースが限られたプロジェクトでは、Jenkinsは少数のパイプラインのみを構築するのに最適です。

新しいテクノロジーのファンであっても、他の新しいCIツールを使用する際には、この「おじさん」を振り返ってみるのも良いでしょう。本書に含まれる一般的な原則とアイデアは、特定のプロジェクト向けに使いやすく、拡張しやすく、メンテナンスしやすいパイプラインを構築する方法を理解するのに役立ちます。

コードの再利用性を向上させる共有ライブラリ

プロジェクト内の複数のコードリポジトリに対して複数のJenkinsfileを作成すると、特に多数のマイクロサービスを提供するプロジェクトでは、異なるパイプライン間で多くのコードが重複する状況に遭遇する可能性があります。多くの場合、利便性のために、類似のロジックコードを異なるJenkinsfileにコピー＆ペーストするだけですが、ある日小さなコマンドを変更する必要が生じた際に、頭を悩ませることになります。

共有ライブラリは、コードの重複を解決する一つの方法です。パイプラインロジックの反復部分や共通部分を、パイプラインセグメントの適切な分割に従って抽象化・カプセル化することで、共有ライブラリ配下のコードはすべてのパイプラインから簡単に参照できるようになります。これにより、Jenkinsファイルのコード行数が大幅に短縮され、可読性と保守性が向上します。

一方、Azure PipelinesやGithub Actionsといった新興ツールは、関数の再利用のメリットを理解しているようで、よく使用されるタスク/アクションを公開マーケットプレイスに公開しています。開発者はそれらを直接利用することも、独自に開発してマーケットプレイスにアップロードすることで、より広範なアクセスを実現できます。また、ユーザーはJenkinsの共有ライブラリのように個別のコードリポジトリを管理する必要がなくなり、複数のメリットが得られます。さらに、クラウドネイティブツールであるTektonも、タスクで同様の手法を採用しています。

共有ライブラリが大きくなり、呼び出し関係が複雑になるにつれて、コードの品質は重要な考慮事項になります。そのため、品質を確保するためにコードをテストする必要があります。共有ライブラリをどのようにテストすればよいでしょうか？ 一つの方法としては、Jenkinsfileを作成し、Jenkinsでジョブを作成して実行し、コードの問題を特定するというものがあります。しかし、この方法は明らかに洗練されていません。JenkinsPipelineUnit（共有ライブラリのユニットテスト用フレームワーク）の使用をお勧めします。

JTEテンプレート

開発フレームワークと同様に、標準化された多数のプロジェクトセットを迅速に構築することが目標です。テンプレートも同様の機能を提供します。同じ種類のパイプラインであれば、ビルドプロセスの大部分は同じで、実行されるコマンドも同一です。当然のことながら、そのようなパイプラインの設定ファイルも非常に類似しています。Jenkinsテンプレートエンジンは、このシナリオに最適なソリューションです。

例えば、大規模なマイクロサービスプロジェクトでは、システムが数十個の小さなマイクロサービスから構成されることがよくあります。これらのマイクロサービスはそれぞれ、パッケージ化とデプロイのプロセスを完了するために独自のCI/CDパイプラインを必要とします。これらはすべて同じ開発フレームワークを共有し、必要なビルド環境、ツール、テストプロセス、リリース戦略などはすべて同じ型から作られています。

名前が示す通り、Jenkins Templating Engine (JTE) はパイプラインのテンプレート化に使用されるツールです。JTE のホームページによると、2019 年 5 月にリリースされたばかりなので、まだ歴史が浅いと言えます。Maven や Gradle など、様々なプロジェクトタイプに対応したテンプレートルールを提供し、内部パイプラインのステージとステップ内のロジックとパラメータを統合します。

上記のコードを完成させ、JTEプラグインをインストールし、Jenkinsを正しく設定したら、デフォルトのファイルであるpipeline_config.groovyを特定のビジネスコードに追加します。新しいパイプラインを作成する際は、ビルド設定オプションでJenkinsテンプレートエンジンを選択するだけで、パイプラインの設定が完了します。必要なのはたった2～3行のコードだけです。

一方、JTEのメリットは以下の3点です。

(出典: https://www.jenkins.io/blog/2019/05/09/templating-engine/)

他の CI/CD ツールで同様のプラクティスを検索すると、Gocd のパイプライン テンプレートや Azure Pipelines のテンプレートなどの例が見つかります。

ジョブDSLの集中管理

多数のコードリポジトリを持つマイクロサービスプロジェクトで、それぞれにパイプラインを定義するためのJenkinsfileが必要な場合、数十、あるいは数百ものリポジトリを分散的に管理・保守するのは面倒な作業になりがちです。Job DSLプラグインを使用すると、DSLを使用してプログラム的にプロジェクトを作成し、ジョブ作成操作をスクリプトで実装することで、Jenkinsの設定を自動化・標準化できます。

このプラグインは、様々な種類のジョブ（Mavenジョブ、Freestyleジョブ、パイプラインジョブなど）を作成できるだけでなく、フォルダ、ダッシュボードビュー、リストビューなどを作成することもできます。下の画像に見られるように、その鮮明な効果は「種を蒔けば、何本もの木が実る」というものです。

コードリポジトリのディレクトリ構造については、まずプロジェクトごとに分割し、各プロジェクトに個別のSeed Jobを定義することをお勧めします。次に、Jobの定義とその他のロジック実装を分離します。これにより、xxx.jenkinsfileの内容の独立性が確保され、Job DSLプラグインを導入した後も、元のjenkinsfileに大きな変更を加える必要がなく、そのまま使用できます。

このツールは、Pipeline as Code のコンセプトを間違いなく一歩進め、パイプライン作成プロセスをコード化します。Jenkins の実践において、よりコードベースの設定が必要な場合は、Jenkins Configuration as Code (JCasC) を検討してください。このツールは、Jenkins のほとんどのリソースと設定を完全にコード化できます。プラグインのインストール、GitHub サーバーの設定、認証情報の管理、新しいタスクの作成など、すべてファイルを通じて実行でき、ユーザーインターフェースを介した操作は不要です。

追記

上記のアイデアはそれぞれ対応する実装方法を提供していますが、他にも多くの方法があります。もちろん、他にも類似の方法がありますが、それらはすべて同じ基本原理を共有しています。将来、新しいCI/CDツールが登場し、いくつかの小さな領域で代替手段が見つかるとしても、全体的なソリューションは依然としてこれらの既存の問題解決のアイデアを中心に展開されるでしょう。例えば、Azure Pipelinesでは、テンプレートは共有ライブラリやJTEと同様の機能を提供しますが、実装は異なります。しかし、コアとなるアイデアは同じです。

具体的な使用方法には、プロジェクトの属性、ブランチ戦略、リリース戦略、権限管理、サーバー環境など、複数の要素を総合的に考慮する必要があります。さらに、Nightly Buildに類似したビルド戦略は数多くあり、参考にする価値があります。「すべての道はローマに通ず」、そして時間効率と労力を節約しながら最終目標を達成する方法、そしてその後のパイプラインを効果的に維持する方法は、いずれも慎重に検討し、設計する価値のある問題です。