Jenkins入門：CI/CD自動化ツールをわかりやすく紹介

By /

Jenkins入門：CI/CD自動化ツールをわかりやすく紹介

ソフトウェア開発の世界では、より速く、より頻繁に、そしてより高品質なソフトウェアをユーザーに届けたいという要求が日々高まっています。この要求に応えるために不可欠なプラクティスが「CI/CD（継続的インテグレーション/継続的デリバリー）」です。そして、そのCI/CDを実現するための強力なツールとして、世界中で広く利用されているのが「Jenkins」です。

しかし、Jenkinsは非常に多機能であるため、「何から手をつければいいのか分からない」「設定が複雑そう」と感じる方も多いかもしれません。

この記事は、そんなJenkinsの入門者に向けて、Jenkinsがなぜ必要とされるのか、CI/CDとは何かといった基礎から、Jenkinsのインストール、基本的な使い方、そしてCI/CDパイプライン構築の考え方までを、分かりやすく、そして詳細に解説することを目的としています。この記事を読み終える頃には、Jenkinsを使ったCI/CD自動化の第一歩を踏み出すイメージが掴めているはずです。

さあ、現代のソフトウェア開発に不可欠なCI/CDと、その中心的な役割を担うJenkinsの世界へ飛び込んでみましょう。

1. なぜCI/CDが必要なのか？ ソフトウェア開発の現場の課題

ソフトウェア開発の現場では、様々な課題に直面しています。これらの課題が、プロダクトの品質低下、リリースの遅延、開発チームの疲弊などを引き起こす原因となります。CI/CDは、これらの課題を解決するためのアプローチです。

CI/CDが必要とされる背景にある、典型的な課題をいくつか挙げてみましょう。

  • 手動でのビルド、テスト、デプロイ作業の負担とヒューマンエラー:
    • コードのコンパイル、テストの実行、サーバーへのデプロイといった一連の作業を手動で行うのは非常に手間がかかります。
    • 手動作業は、設定ミスや手順忘れなどのヒューマンエラーを招きやすく、それが原因で本番環境で問題が発生することがあります。
    • 特定の担当者しかこれらの作業ができない「属人化」が進みやすいです。
  • インテグレーション（結合）の遅延と問題の発見の遅れ:
    • 複数の開発者がそれぞれの機能を並行して開発し、最後にまとめて結合しようとすると、大規模なコンフリクトや互換性の問題が発生しやすくなります。
    • 結合の頻度が低いと、問題が手戻りの大きい後工程で発見され、修正に多大なコストと時間がかかります。
  • 品質保証の課題:
    • コード変更ごとに全てのテストを手動で実行するのは現実的ではありません。
    • テストの実行漏れや、テスト環境と本番環境の差異による問題が発生しやすいです。
  • リリースの遅延とリードタイムの長さ:
    • 開発から本番環境へのリリースまでに多くの手作業や承認プロセスが挟まるため、時間がかかります。
    • 市場の変化や顧客の要求に迅速に対応することが難しくなります。
  • 開発チームと運用チーム間の連携問題 (DevOps):
    • 開発チームが作ったソフトウェアを、運用チームが受け取ってデプロイするというプロセスにおいて、情報共有不足や責任範囲の不明確さから問題が発生することがあります。

これらの課題は、開発規模が大きくなるにつれて、あるいは開発チームの人数が増えるにつれて顕著になります。CI/CDは、これらの課題に対して、自動化と継続的なプロセス改善によってアプローチします。

2. CI/CDとは何か？ 基本概念の詳細解説

CI/CDは、ソフトウェアをより迅速かつ確実にリリースするための文化、プラクティス、そしてツールを組み合わせたアプローチです。CI（継続的インテグレーション）、CD（継続的デリバリー）、そして継続的デプロイメントという3つのフェーズで構成されるパイプラインを形成することが一般的です。

2.1. 継続的インテグレーション (Continuous Integration – CI)

CIは、開発者が自分の書いたコードを、頻繁に（例えば、1日に複数回）共有リポジトリにマージ（統合）し、そのたびに自動的にビルドとテストを実行するプラクティスです。

  • 目的:
    • コードの統合によって発生する問題を早期に発見し、解決する。
    • いつでも主要なブランチ（例: main, master）が安定していて、デプロイ可能な状態を保つ。
    • 開発チーム全体でのコードの整合性を高める。
  • 主要なプラクティス:
    • バージョン管理システムの使用: Gitなどのシステムを利用し、全てのコード変更を一元管理します。
    • 頻繁なコミットとプッシュ: 開発者は小さな変更を頻繁にコミットし、共有リポジトリにプッシュします。
    • 自動ビルド: コードがリポジトリにプッシュされるたびに、自動的にアプリケーションのビルド（コンパイル、ライブラリの依存解決など）を行います。
    • 自動テスト: ビルドが成功したら、単体テスト、結合テストなどの自動テストを実行します。
    • CIサーバー（例: Jenkins）の利用: これらの自動化されたビルドとテストの実行を管理します。
    • 全てのビルドとテストの成功: 問題がなければ緑色のランプ（または同等の表示）が灯り、チーム全体に進捗を共有します。失敗した場合はすぐに修正に取り掛かります。
    • ビルドのアーティファクト生成: ビルドが成功した成果物（実行可能なjarファイル、warファイル、Dockerイメージなど）を生成し、保管します。
  • メリット:
    • 問題の早期発見: 統合の問題やバグを開発サイクルの早い段階で発見できるため、修正コストが削減されます。
    • 手戻りの削減: 大規模なマージコンフリクトや互換性の問題を防ぎます。
    • 品質向上: 自動テストにより、継続的にコードの品質をチェックできます。
    • 開発効率の向上: ビルドやテストの手動作業が不要になり、開発者はコーディングに集中できます。
    • チーム内のコミュニケーション促進: ビルドやテストの失敗はチーム全体に通知され、問題解決に向けて協力する文化が醸成されます。

2.2. 継続的デリバリー (Continuous Delivery – CD)

継続的デリバリーは、CIが成功した後、ビルドされたソフトウェアを常に本番環境にデプロイ可能な状態に保つプラクティスです。CIで生成されたビルド成果物を、自動化されたプロセスを通して、ステージング環境などへデプロイし、さらに品質を確認するためのテスト（例：受け入れテスト、性能テスト、セキュリティテスト）を実行します。

  • 目的:
    • コード変更がいつでも、迅速かつ安全に本番環境にリリースできる状態にする。
    • 手動でのデプロイ作業に伴うリスクと負担を軽減する。
  • 主要なプラクティス:
    • CIの徹底: CIが確立されていることが前提となります。
    • デプロイメントパイプラインの自動化: ビルド成果物を開発環境、ステージング環境、そして本番環境へと昇格させるプロセスを自動化します。
    • 環境の標準化: 開発環境、テスト環境、ステージング環境、本番環境ができるだけ一致するように管理します（ Infrastructure as Code など）。
    • 自動化されたテストの拡充: CIで実行されるテストに加え、より包括的なテスト（E2Eテスト、UIテスト、パフォーマンステスト、セキュリティスキャンなど）を自動化し、ステージング環境などで実行します。
    • ワンクリックデプロイメント: 準備ができたビルドは、手動のトリガー（ボタンクリックなど）一つで本番環境にデプロイできる状態にします。
  • メリット:
    • リリースのリードタイム短縮: 開発からデプロイまでの時間が大幅に短縮されます。
    • デプロイのリスク低減: デプロイプロセスが自動化・標準化されるため、ヒューマンエラーや環境差異による問題が減少します。
    • ビジネスへの迅速な価値提供: 新機能や改善を市場に素早く投入できます。
    • 信頼性の向上: デプロイが簡単かつ安全になることで、頻繁なリリースが可能になり、小さな変更を何度もリリースする方が、一度に大きな変更をリリースするよりもリスクが低くなります。

2.3. 継続的デプロイメント (Continuous Deployment – CD)

継続的デプロイメントは、継続的デリバリーをさらに一歩進めたプラクティスです。継続的デリバリーでは「いつでもデプロイ可能な状態」にしますが、継続的デプロイメントでは、CI/CDパイプラインを通過して問題がないと判断されたコード変更は、自動的に本番環境にデプロイされます。手動の承認プロセスは基本的には存在しません（ただし、ビジネス上の理由などで特定の場合に承認を挟むこともあります）。

  • 目的:
    • 承認や手動操作なしに、全ての変更を可能な限り迅速にユーザーに届ける。
    • デプロイ判断から解放され、価値提供に集中する。
  • 主要なプラクティス:
    • 継続的デリバリーの徹底: 継続的デリバリーが完全に確立されていることが前提となります。
    • 本番デプロイの自動化: パイプラインの最終段階として、ステージング環境でのテスト通過後、自動的に本番環境へのデプロイを実行します。
    • 高度なモニタリングとロールバック機構: 万が一、デプロイした変更に問題があった場合に、すぐに検知し、自動的または迅速に以前のバージョンに戻す（ロールバック）仕組みが必要です。
    • カナリアリリースやブルー/グリーンデプロイメントなどのデプロイ戦略: 全ユーザーに一度にリリースするのではなく、段階的にリリースすることでリスクを最小限に抑えます。
  • メリット:
    • 最速のリリースサイクル: コード変更がマージされてから本番環境に反映されるまでの時間が劇的に短縮されます。
    • 市場への迅速な適応: 顧客のフィードバックや市場の変化に即座に対応できます。
    • デプロイ判断の負荷軽減: 自動化により、リリース判断に関する人間的な介入やプレッシャーが減少します。
  • デメリット/考慮事項:
    • 高いレベルの自動テストとモニタリングが必要: 自動で本番にリリースされるため、問題のある変更がデプロイされないよう、自動テストと本番環境の監視が非常に重要になります。
    • 組織文化: このプラクティスを導入するには、チームの高い信頼性と責任感、そして問題発生時の迅速な対応能力が求められます。

CI/CDは、これらのCI、CD、そして継続的デプロイメントの各フェーズを自動化されたパイプラインとして構築することで実現されます。開発者がコードをプッシュすると、CIによってビルドとテストが行われ、問題がなければCDのプロセスに進み、デプロイ可能な状態が維持され、最終的には（継続的デプロイメントを選択している場合は）自動的に本番環境にデプロイされます。

3. Jenkinsとは何か？ その概要と特徴

Jenkinsは、CI/CDパイプラインを構築するための中核となる、オープンソースの自動化サーバーです。Javaで開発されており、ウェブインターフェースを通じて設定や操作を行います。2004年にHudsonとして開発が始まり、現在はJenkinsとして、世界中の多くの企業で利用されています。

3.1. Jenkinsの役割

Jenkinsの主な役割は、ソフトウェア開発の様々なタスクを自動化することです。具体的には、以下のようなタスクを自動化し、CI/CDプロセスをサポートします。

  • ソースコード管理システムからのコード取得: Git, Subversionなどのリポジトリから最新のコードを取得します。
  • ビルド: プロジェクトのビルドツール（Maven, Gradle, npm, Antなど）を使って、コードをコンパイルし、実行可能な成果物を作成します。
  • テスト実行: 単体テスト、結合テストなどの自動テストを実行します。
  • 静的解析: コードの品質や規約違反をチェックします。
  • デプロイ: ビルドされた成果物を開発環境、ステージング環境、本番環境などのサーバーにデプロイします。
  • ジョブのスケジュール実行: 定期的に特定のタスクを実行します。
  • 外部イベントによるトリガー: ソースコードの変更検知（Webhook）、API呼び出しなどによりジョブを実行します。
  • 実行結果のレポートと通知: ビルドの成功・失敗、テスト結果などを開発チームに通知します（メール、Slackなど）。

3.2. Jenkinsの特徴

Jenkinsが広く利用されている理由として、以下の特徴が挙げられます。

  • オープンソースかつ無料: 誰でも自由に利用・改変・配布できます。コストをかけずに導入できる点が大きなメリットです。
  • 豊富なプラグインエコシステム: Jenkinsの最大の特徴と言っても過言ではありません。数千にも及ぶプラグインが提供されており、様々なツール（SCM、ビルドツール、クラウドサービス、通知ツールなど）との連携や機能拡張が可能です。これにより、ほぼ全ての開発環境やワークフローに対応できます。
  • 簡単なインストールと設定: WARファイル一つで実行できたり、主要なOS向けのパッケージが提供されていたり、Dockerイメージも用意されていたりと、様々な方法で比較的簡単にインストールできます。ウェブUIからの設定も直感的です。
  • 高い拡張性: マスター/エージェント（旧マスター/スレーブ）構成により、複数のビルドを並行して実行したり、異なる環境でビルドやテストを実行したりできます。
  • カスタマイズ性: ジョブの設定、パイプラインの定義、UIの外観など、多くの部分をチームのニーズに合わせてカスタマイズできます。
  • 強力なコミュニティ: 活発なコミュニティがあり、ドキュメントが豊富で、問題解決のためのサポートも得やすいです。

3.3. Jenkinsのアーキテクチャ：マスター/エージェント

Jenkinsは、基本的に「マスター」と「エージェント」という役割に分かれて動作します。

  • Jenkinsマスター:
    • Jenkinsの核となる部分です。
    • ジョブのスケジュール管理、エージェントへのタスク割り当て、ジョブの実行結果の記録、ウェブUIの提供、プラグインの管理などを行います。
    • マスター自体がビルドやテストを実行することも可能ですが、通常は管理機能に特化し、実際のリソースを多く消費する処理はエージェントに任せます。
  • Jenkinsエージェント:
    • マスターからタスク（ビルド、テスト、デプロイなど）を受け取り、実際に実行するノードです。
    • 様々なOS（Linux, Windows, macOSなど）や環境で動作させることができます。
    • これにより、異なる環境（例えば、Java開発用のLinuxサーバーと、iOSアプリ開発用のmacOSマシン）でビルドやテストを実行したり、マスターの負荷を分散させたりすることが可能です。

この構成により、Jenkinsは単一のサーバーで小規模なCI/CDから、複数のエージェントを分散させた大規模なCI/CDシステムまで柔軟に対応できます。

4. Jenkinsのインストールと初期設定

実際にJenkinsを使い始めるためには、まずJenkinsをインストールする必要があります。Jenkinsのインストール方法はいくつかありますが、ここでは一般的な方法をいくつか紹介し、特にDockerを利用する方法とパッケージマネージャーを利用する方法に焦点を当てて説明します。

4.1. インストール方法の選択肢

  • WARファイル: ダウンロードしたjenkins.warファイルをJavaがインストールされた環境で実行します。最もシンプルですが、依存関係の管理やバックグラウンド実行などは別途設定が必要です。
  • ネイティブパッケージ: Debian/Ubuntu (.deb)、Red Hat/CentOS (.rpm)、Windowsインストーラー、macOSパッケージなどが提供されています。OSの標準的な方法でインストールでき、サービスの管理（起動・停止など）も容易です。
  • Docker: Dockerイメージが公式に提供されています。最もモダンで推奨される方法の一つで、環境構築が容易で可搬性が高いです。
  • クラウドプラットフォーム: AWS、Google Cloud Platform、Microsoft Azureなどの主要なクラウドで、Jenkinsのテンプレートやマネージドサービス（Jenkinsではありませんが類似機能を持つもの）が提供されています。

ここでは、手軽に試せるDockerと、一般的なサーバーOSであるLinux（aptを使用するDebian/Ubuntu系を例に）へのパッケージインストールを説明します。

4.2. Dockerを利用したインストール (推奨)

Dockerがインストールされている環境であれば、以下のコマンドでJenkinsを起動できます。

“`bash

Dockerイメージをダウンロード

docker pull jenkins/jenkins:lts

Jenkins用の永続化ディレクトリを作成

docker volume create jenkins_home

Jenkinsコンテナを起動

docker run -d -p 8080:8080 -p 50000:50000 –name jenkins \
-v jenkins_home:/var/jenkins_home \
-v /var/run/docker.sock:/var/run/docker.sock \
jenkins/jenkins:lts
“`

コマンド解説:

  • docker pull jenkins/jenkins:lts: Jenkinsの最新LTS (Long-Term Support) 版イメージを取得します。
  • docker volume create jenkins_home: Jenkinsの設定やジョブデータなどが保存される場所として、Dockerボリュームを作成します。これにより、コンテナを削除してもデータは永続化されます。
  • docker run -d ...: バックグラウンドでコンテナを実行します。
  • -p 8080:8080: ホストマシンの8080ポートをコンテナの8080ポート（Jenkinsのデフォルトポート）にマッピングします。これにより、ブラウザからhttp://localhost:8080でアクセスできます。
  • -p 50000:50000: Jenkinsマスターとエージェント間の通信に使用されるポートです。エージェントを接続する場合に必要です。
  • --name jenkins: コンテナにjenkinsという名前を付けます。
  • -v jenkins_home:/var/jenkins_home: 作成したDockerボリュームjenkins_homeをコンテナ内の/var/jenkins_homeディレクトリにマウントします。Jenkinsはこのディレクトリに全てのデータを保存します。
  • -v /var/run/docker.sock:/var/run/docker.sock: (オプション) JenkinsパイプラインなどからDockerコマンドを実行する場合に、ホストのDockerデーモンにアクセスできるようにします。セキュリティ上の考慮が必要です。
  • jenkins/jenkins:lts: 使用するDockerイメージ名とタグです。

コンテナが起動したら、ブラウザでhttp://localhost:8080にアクセスします。

4.3. Linux (Debian/Ubuntu) へのパッケージインストール

Jenkinsは公式リポジトリを提供しており、aptパッケージマネージャーを使ってインストールできます。

“`bash

Javaのインストール (JenkinsにはJavaが必要です)

sudo apt update
sudo apt install openjdk-11-jdk -y # OpenJDK 11を推奨

Jenkinsリポジトリのキーを追加

curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key | sudo tee \
/usr/share/keyrings/jenkins-keyring.asc > /dev/null

Jenkinsリポジトリをsources.list.dに追加

echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
https://pkg.jenkins.io/debian-stable binary/ | sudo tee \
/etc/apt/sources.list.d/jenkins.list > /dev/null

パッケージ情報を更新し、Jenkinsをインストール

sudo apt update
sudo apt install jenkins
“`

インストールが完了すると、Jenkinsサービスが自動的に起動します。ブラウザでhttp://<サーバーのIPアドレスまたはホスト名>:8080にアクセスします。

4.4. Jenkinsの初期セットアップ

初めてJenkinsにアクセスすると、初期設定画面が表示されます。

  1. Unlock Jenkins:
    • 管理パスワードの入力を求められます。画面の指示に従い、指定されたファイル（例: /var/jenkins_home/secrets/initialAdminPassword や /var/lib/jenkins/secrets/initialAdminPassword）からパスワードを取得し入力します。Dockerの場合は、docker logs jenkins コマンドでコンテナのログを確認するとパスワードが表示されます。
  2. Customize Jenkins:
    • プラグインのインストール方法を選択します。「Install suggested plugins」（推奨プラグインのインストール）を選択するのが最も簡単で一般的です。Jenkinsが必要と判断した基本的なプラグイン群が自動的にインストールされます。
    • 特定のプラグインだけをインストールしたい場合は、「Select plugins to install」を選択し、リストから必要なものを選べます。後からいつでもプラグインは追加・削除できます。
  3. Create First Admin User:
    • Jenkinsの管理者ユーザーを作成します。ユーザー名、パスワード、氏名、メールアドレスを入力します。このユーザーで以降Jenkinsにログインします。
  4. Instance Configuration:
    • JenkinsのURLを設定します。通常は自動検出されたURLで問題ありませんが、必要に応じて変更します。
  5. Finish:
    • 設定完了です。「Start using Jenkins」をクリックすると、Jenkinsのダッシュボードが表示されます。

これでJenkinsの基本的なインストールとセットアップは完了です。次はこのJenkinsを使ってCI/CDの自動化タスクである「ジョブ」を作成する方法を見ていきましょう。

5. Jenkinsジョブの作成と実行

Jenkinsにおける「ジョブ」とは、自動化したい一連のタスク（例えば、ソースコードの取得、ビルド、テスト実行、デプロイなど）を定義したものです。Jenkinsを使う上で、このジョブを作成・設定することが中心的な作業となります。

5.1. ジョブの種類

Jenkinsには、いくつかの主要なジョブタイプがあります。

  • フリースタイルプロジェクト (Freestyle project):
    • 最も基本的で柔軟なジョブタイプです。
    • ソースコード管理、ビルドトリガー、ビルドステップ（コマンド実行など）、ビルド後の処理などを、それぞれ独立した設定項目としてウェブUI上で細かく設定できます。
    • シンプルなタスクの自動化や、Jenkinsに慣れるための第一歩として適しています。ただし、複雑なパイプラインを構築しようとすると設定が煩雑になりがちです。
  • Mavenプロジェクト:
    • Mavenプロジェクトのビルドに特化したジョブタイプです。
    • Mavenのpom.xmlを自動的に解析し、Goalsの指定やレポート表示などをサポートします。Mavenプロジェクトをビルドする際には便利です。
  • パイプライン (Pipeline):
    • CI/CDパイプライン全体をコード（Groovyベースのスクリプト、Jenkinsfile）として定義するジョブタイプです。
    • ビルド、テスト、デプロイといった一連のステージを順序立てて定義できます。
    • 設定をコードとしてバージョン管理できるため、可搬性、再現性、変更履歴の追跡に優れています。複雑なCI/CDワークフローや大規模なプロジェクトに適しています。最も推奨されるジョブタイプです。
  • Multibranch Pipeline:
    • 単一のリポジトリ内の複数のブランチやプルリクエスト（マージリクエスト）に対して、自動的にパイプラインジョブを作成・実行するジョブタイプです。
    • ブランチごとに異なるパイプラインを実行したり、新しいブランチが作成されたら自動的にCIを開始したりといったことが可能です。

入門としては、まずはフリースタイルプロジェクトで基本的な自動化を体験し、慣れてきたらパイプラインに進むのが良いでしょう。ここでは、フリースタイルプロジェクトを中心にジョブ作成の基本的な流れを説明します。

5.2. フリースタイルジョブの作成例

簡単なJavaアプリケーションをビルド・テストするジョブを作成する例を考えます。このアプリケーションはGitリポジトリに置かれており、Mavenでビルドできると仮定します。

  1. 新しいジョブの作成:

    • Jenkinsダッシュボードにログインします。
    • 左側のメニューから「New Item」（新しいアイテム）をクリックします。
    • アイテム名（ジョブ名）を入力します。例: my-java-app-ci
    • ジョブタイプとして「Freestyle project」（フリースタイルプロジェクト）を選択します。
    • 「OK」をクリックします。

  2. 設定画面:

    • 作成したジョブの設定画面が開きます。ここで様々な設定を行います。

  3. 一般設定:

    • 「Description」（説明）: ジョブの目的などを記述します。
    • 他のオプション（ビルドの破棄、パラメータ化ビルドなど）は必要に応じて設定します。

  4. ソースコード管理 (Source Code Management – SCM):

    • ビルド対象のソースコードがどこにあるかを指定します。
    • 「Git」を選択します（他のSCMツールを使っている場合はそれを選択）。
    • Repository URL: GitリポジトリのURLを入力します。例: https://github.com/your-org/my-java-app.git
    • Credentials: プライベートリポジトリの場合は、アクセスするための認証情報を設定します。「Add」ボタンからJenkinsに認証情報を登録し、ドロップダウンから選択します。
    • Branches to build: ビルドしたいブランチを指定します。デフォルトは*/masterや*/mainですが、特定のブランチ（例: */develop）を指定することもできます。

  5. ビルドトリガー (Build Triggers):

    • いつジョブを実行するかを指定します。
    • Build periodically: 定期的に実行します。Cron形式でスケジュールを指定します。例: H/15 * * * * （15分おきに実行）
    • Poll SCM: ソースコードリポジトリの変更を定期的にチェックし、変更があればビルドします。こちらもCron形式でチェック間隔を指定します。頻繁なチェックはリポジトリサーバーに負荷をかけるため、Webhookの方が推奨されます。
    • Generic Webhook Trigger / GitHub hook trigger for GITScm polling / GitLab triggers: 外部サービス（GitHub, GitLabなど）からのWebhookを受け取ってビルドをトリガーします。コードがプッシュされたら即座にビルドを開始できるため、CIにおいて最も一般的で推奨される方法です。Webhookの設定は、リポジトリ側の設定も必要になります。
    • Build after other projects are built: 他のジョブのビルドが成功した後にこのジョブを実行します。パイプラインの一部として使用できます。

  6. ビルド環境 (Build Environment):

    • ビルド実行時の環境に関する設定です。
    • 「Add Timestamp to the Console Output」（コンソール出力にタイムスタンプを追加）などはONにしておくと便利です。

  7. ビルド (Build):

    • ここで実際のビルドコマンドなどを指定します。
    • Java+Mavenプロジェクトなので、「Add build step」から「Invoke top-level Maven targets」を選択します。
    • Maven Version: Jenkinsに設定済みのMavenバージョンを選択します（「Global Tool Configuration」で設定できます）。
    • Goals: MavenのGoalを指定します。CIの典型的にはclean packageやclean verifyなどを指定します。テストも同時に実行されます。
    • シェルスクリプトやWindowsバッチコマンドを実行したい場合は、「Execute shell」や「Execute Windows batch command」を選択します。

  8. ビルド後の処理 (Post-build Actions):

    • ビルドが完了した後に実行する処理を指定します。
    • Archive the artifacts: ビルド生成物（JARファイル、WARファイルなど）をJenkins上に保存します。
    • Publish JUnit test result report: JUnit形式のテスト結果XMLファイルを読み込み、Jenkins上でテスト結果をグラフなどで表示します。テストの合否判定にも利用されます。
    • Email Notification: ビルドの成功・失敗に応じてメール通知を行います。
    • Slack Notification: Slackチャンネルに通知を送信します（Slackプラグインが必要）。

  9. 保存:

    • 全ての設定が終わったら画面下部の「Save」をクリックします。

5.3. ジョブの実行と結果確認

ジョブの設定後、以下の方法で実行できます。

  • 手動実行: ジョブのページ左側のメニューから「Build Now」（今すぐビルド）をクリックします。
  • 自動実行: 設定したトリガー（SCM変更、スケジュール、Webhookなど）によって自動的に実行されます。

ジョブが実行されると、ビルド履歴に新しいビルド番号が表示されます。実行中のビルドをクリックすると、詳細画面に進めます。

  • Console Output: ビルドプロセスの標準出力と標準エラー出力が表示されます。エラーが発生した場合の原因調査に不可欠です。
  • Test Result: 「Publish JUnit test result report」を設定している場合、テストの合計数、成功数、失敗数、スキップ数、実行時間などが分かりやすく表示されます。失敗したテストの詳細も確認できます。
  • Changes: 前回のビルドからのコード変更履歴が表示されます。
  • Artifacts: 「Archive the artifacts」を設定している場合、保存されたビルド成果物をダウンロードできます。

これらの情報を確認することで、ビルドが成功したか、テストは全てパスしたかなどを容易に把握できます。問題が発生した場合は、コンソール出力を確認して原因を特定し、コードを修正して再度ビルドを実行します。

6. JenkinsとSCMの連携

CIの出発点は、ソースコードの変更を検知することです。Jenkinsは様々なSCMツールと連携できますが、特にGitとの連携が一般的です。

6.1. Git連携の詳細

フリースタイルジョブの設定で「Source Code Management」に「Git」を選択した場合の主な設定項目です。

  • Repository URL: https://github.com/user/repo.git または [email protected]:user/repo.git の形式で指定します。SSHプロトコルの場合は、JenkinsサーバーにSSHキーを設定する必要があります。
  • Credentials: プライベートリポジトリにアクセスするための認証情報を設定します。
    • Username with password: ユーザー名とパスワード。GitHubなどの場合は、Personal Access Token (PAT) をパスワードとして利用するのが推奨されます。
    • SSH Username with private key: SSHキーペアを使用する場合。公開鍵をGitホスティングサービスに登録し、秘密鍵をJenkinsに登録します。
    • Jenkinsの「Credentials」ストアに認証情報を登録・管理できます。これは後述するPipelineでも重要になります。
  • Branches to build: ビルド対象のブランチを指定します。*/main は全てのremoteにあるmainブランチを意味します。特定のブランチだけをビルドしたい場合はorigin/developのように指定します。複数のブランチを指定したり、ワイルドカードを使ったりすることも可能です。
  • Additional Behaviours: クローン時の詳細設定（浅いクローン、サブモジュール更新など）を行えます。

6.2. Webhookによる自動トリガー設定 (推奨)

Poll SCMはリポジトリサーバーに負荷をかけるため、コード変更時にリポジトリ側からJenkinsに通知を送るWebhookを利用するのが一般的です。

設定手順（例: GitHubの場合）：

  1. Jenkins側の設定:
    • ジョブ設定の「Build Triggers」で「GitHub hook trigger for GITScm polling」にチェックを入れます。
    • （または、Generic Webhook Triggerプラグインなどを使用する場合、プラグインの設定に従います。）
    • Jenkinsの「Jenkinsの管理」→「System」で、JenkinsのURLが正しく設定されていることを確認します（GitHubなどがアクセス可能なURLである必要があります）。
  2. GitHub側の設定:
    • GitHubリポジトリの「Settings」タブを開きます。
    • 左側メニューの「Webhooks」を選択し、「Add webhook」をクリックします。
    • Payload URL: JenkinsのURLに/github-webhook/（GitHubプラグインの場合）を付けたURLを入力します。例: http://your-jenkins-url:8080/github-webhook/
    • Content type: application/json を選択します。
    • Secret: （オプション）設定することで、Webhookのセキュリティを強化できます。Jenkins側のGitHubプラグイン設定でも同じSecretを設定します。
    • Which events would you like to trigger this webhook?: トリガーしたいイベントを選択します。「Just the push event」（コードプッシュ時のみ）を選択するのが一般的です。プルリクエストに対するCIを行う場合は「Pull requests」も選択します。
    • 「Add webhook」をクリックして保存します。

これで、GitHubリポジトリにコードがプッシュされるたびに、GitHubからJenkinsに通知が送られ、Jenkinsはその通知を受けて自動的にジョブを実行するようになります。

7. Jenkinsプラグイン

Jenkinsの強力な拡張性は、豊富なプラグインエコシステムによって支えられています。プラグインをインストールすることで、Jenkinsは様々なツールやサービスと連携し、機能を大幅に拡張できます。

7.1. プラグインの重要性

  • 機能拡張: 標準機能にはないビルドツール、SCM、レポート形式、通知方法などに対応できます。
  • ツール連携: GitHub, GitLab, Slack, Docker, Kubernetes, JUnit, Checkstyle, FindBugs, SonarQubeなど、開発・運用で使われる多くのツールと連携できます。
  • UIのカスタマイズ: ダッシュボードの外観や機能を追加できます。

7.2. 主要なプラグインカテゴリとよく使われるプラグイン

プラグインは非常に多岐にわたりますが、主要なカテゴリと代表的なプラグインをいくつか紹介します。

  • SCM (Source Code Management):
    • Git: Gitリポジトリとの連携に必須。
    • Subversion: Subversionリポジトリとの連携に。
  • ビルドツール:
    • Maven Integration: Mavenプロジェクトのビルドに特化。
    • Gradle: Gradleプロジェクトのビルドに。
    • Ant: Antプロジェクトのビルドに。
  • テストおよびレポート:
    • JUnit: JUnit形式のテスト結果を表示・集計。
    • TestNG Results: TestNG形式のテスト結果を表示・集計。
    • Cobertura Plugin / JaCoCo Plugin: コードカバレッジ（テストでどれだけコードが実行されたか）を計測・表示。
  • 静的解析:
    • Warnings Next Generation: コンパイラの警告や静的解析ツールの結果（Checkstyle, FindBugs, PMDなど）を集約・表示。
  • 通知:
    • Email Extension Plugin: 高度なメール通知設定。
    • Slack Notification: Slackへの通知。
    • Microsoft Teams Notification: Microsoft Teamsへの通知。
  • デプロイ:
    • Deploy to container Plugin: アプリケーションサーバー（Tomcat, JBossなど）へのWAR/EARファイルのデプロイ。
    • SSH Steps: SSH経由でのコマンド実行（リモートサーバーへのデプロイなど）。
    • Docker Pipeline / Docker: Dockerイメージのビルド、実行。
    • Kubernetes Pipeline / Kubernetes: Kubernetesクラスターとの連携。
  • ユーティリティ:
    • Workspace Cleanup: ビルド開始前または後にワークスペースをクリーンアップ。
    • Timestamper: コンソール出力にタイムスタンプを追加。
  • 認証・認可:
    • LDAP Plugin: LDAP/Active Directory連携。
    • Role-based Access Control (RBAC): より詳細な権限設定。
  • パイプライン:
    • Pipeline: パイプラインジョブタイプ自体を提供。
    • Pipeline: Stage View: パイプラインの実行状況を視覚的に表示。

7.3. プラグインのインストール・管理方法

  1. Jenkinsの管理: ダッシュボードの左側メニューから「Jenkinsの管理」をクリックします。
  2. プラグインの管理: 「システムの設定」セクションにある「プラグインの管理」をクリックします。
  3. インストール可能なプラグイン:
    • 「Available」（インストール可能）タブを選択します。
    • 検索ボックスにプラグイン名を入力して絞り込めます。
    • インストールしたいプラグインにチェックを入れます。
    • 画面下部にある「Download now and install after restart」または「Install without restart」（推奨されない場合あり）をクリックします。通常は「Download now and install after restart」を選び、画面の指示に従ってJenkinsを再起動します。
  4. インストール済みプラグイン:
    • 「Installed」（インストール済み）タブで、現在Jenkinsにインストールされているプラグインを確認できます。
    • ここでプラグインの無効化やアンインストールも行えます。
  5. アップデート:
    • 「Updates」（アップデート）タブで、利用可能なプラグインのアップデートを確認・実行できます。セキュリティFixなどが含まれている場合があるので、定期的にチェックしアップデートを適用することが推奨されます。

プラグインはJenkinsの機能を劇的に拡張しますが、入れすぎると起動が遅くなったり、プラグイン間の競合で問題が発生したりすることもあります。必要なものだけを選んでインストールするようにしましょう。

8. Jenkinsパイプライン (Pipeline as Code)

フリースタイルジョブは設定がUIに分散し、複雑なワークフローを表現するのが難しいという課題があります。これを解決するのが、パイプラインです。Jenkinsパイプラインは、CI/CDパイプライン全体をコード（通常はJenkinsfileというファイル）として定義し、バージョン管理システムでソースコードと一緒に管理するアプローチです（Pipeline as Code）。

8.1. なぜパイプラインが必要か？

  • 設定の一元管理とバージョン管理: ビルドプロセス全体がJenkinsfileという単一のファイルに記述されるため、設定が分散せず管理が容易になります。また、ソースコードと同じリポジトリで管理することで、コードの変更とビルドプロセスの変更を一緒に追跡できます。
  • 可搬性と再現性: Jenkinsfileがあれば、別のJenkins環境でも同じパイプラインを簡単にセットアップ・実行できます。
  • 複雑なワークフローの表現: ステージ、ステップ、条件分岐、並列実行、手動承認などをコードで柔軟に記述できます。
  • 変更履歴の追跡と監査: Jenkinsfileの変更もGitなどの履歴として残り、誰がいつパイプラインをどのように変更したかを追跡できます。
  • チーム間の共有: パイプラインの定義がコードとして共有されるため、チームメンバーがビルドプロセスを理解しやすくなります。

8.2. Scripted Pipeline vs Declarative Pipeline

Jenkinsパイプラインには、主に2つの構文があります。

  • Scripted Pipeline:
    • Groovyスクリプトを直接記述します。
    • 非常に柔軟性が高く、複雑なロジックや独自の処理を記述しやすいです。
    • ただし、Groovyの知識が必要で、記述がやや複雑になることがあります。
  • Declarative Pipeline:
    • より構造化された、宣言的な構文を使用します。
    • pipeline, agent, stages, stage, stepsなどのディレクティブ（予約語）を使って、パイプラインの構造を分かりやすく記述します。
    • 構文がシンプルで分かりやすく、初心者にも扱いやすいです。多くの一般的なCI/CDシナリオをカバーできます。
    • 現在はDeclarative Pipelineが推奨されています。

この記事では、推奨されているDeclarative Pipelineを中心に解説します。

8.3. Jenkinsfileの書き方 (Declarative Pipeline)

Jenkinsfileは、プロジェクトのルートディレクトリに配置するのが一般的です。内容は以下の基本的な構造を持ちます。

“`groovy
// Jenkinsfile (Declarative Pipeline)

pipeline {
// どこでパイプラインを実行するか (Jenkinsエージェントなど)
agent any 

// 環境変数
environment {
    // 例: JAVA_HOME = "/usr/lib/jvm/java-11-openjdk-amd64"
}

// パイプラインの各ステージ
stages {
    // チェックアウトステージ
    stage('Checkout') {
        steps {
            // Gitリポジトリからコードをクローン
            git url: 'https://github.com/your-org/my-app.git', branch: 'main'
        }
    }

    // ビルドステージ
    stage('Build') {
        steps {
            // Mavenビルドを実行
            // shコマンドでシェルスクリプトを実行
            sh 'mvn clean package'
        }
    }

    // テストステージ
    stage('Test') {
        steps {
            // テストを実行 (前のmvn packageに含まれる場合もある)
            // sh 'mvn test' // mvn packageに含まれるなら不要

            // JUnitテスト結果を収集・表示
            junit '**/target/surefire-reports/*.xml' 
        }
    }

    // デプロイステージ (例: ステージング環境へ)
    stage('Deploy to Staging') {
        // 直前のステージが成功した場合のみ実行などの条件を付けられる
        when {
            // 例: mainブランチへのプッシュ時のみ実行
            branch 'main'
        }
        steps {
            // リモートサーバーへのファイル転送、デプロイコマンド実行など
            // sh 'ssh [email protected] "deploy-script.sh"'
        }
    }
}

// ビルド後の処理
post {
    // 常に実行
    always {
        // ワークスペースのクリーンアップ
        cleanWs()
    }
    // ビルド成功時に実行
    success {
        // Slack通知など
        // slackSend channel: '#ci-notifications', message: "Build ${env.JOB_NAME} #${env.BUILD_NUMBER} succeeded."
    }
    // ビルド失敗時に実行
    failure {
        // メール通知など
        // mail to: '[email protected]', subject: "Build Failed: ${env.JOB_NAME}", body: "Build #${env.BUILD_NUMBER} failed. See ${env.BUILD_URL}"
    }
}

}
“`

主要なディレクティブ:

  • pipeline { ... }: パイプライン定義のルートブロックです。
  • agent { ... }: パイプライン全体または特定のステージを実行する場所（Jenkinsエージェント）を指定します。agent anyは利用可能な任意のエージェントで実行、agent { node { label 'my-agent' } }は指定したラベルを持つエージェントで実行、agent noneはステージレベルでagentを指定する必要があることを示します。
  • stages { ... }: 複数のstageブロックを含むセクションです。
  • stage('ステージ名') { ... }: パイプラインの個々のステップ（ステージ）を定義します。通常、Checkout, Build, Test, Deployといった論理的なフェーズに分割します。
  • steps { ... }: stageブロック内で実行される具体的なコマンドやアクション（ステップ）を記述します。sh, bat, git, mvn, junitなどのステップが利用できます。これらはJenkinsにインストールされているプラグインによって提供されます。
  • environment { ... }: パイプライン全体または特定のステージで使用する環境変数を定義します。
  • when { ... }: ステージを実行するかどうかの条件を定義します（例: ブランチ名、環境変数、変更されたファイルなど）。
  • post { ... }: パイプラインまたは特定のステージの完了後に実行される処理を定義します。always, success, failure, unstable, changed, fixedなどの条件ブロックを指定できます。

8.4. Pipelineジョブの作成

  1. 新しいジョブの作成: フリースタイルプロジェクトと同様に「New Item」から新しいジョブを作成します。
  2. ジョブタイプ: 「Pipeline」を選択します。
  3. 設定:
    • 「Definition」で「Pipeline script from SCM」を選択します。
    • SCM: 「Git」などを選択し、リポジトリURL、認証情報などを設定します。
    • Script Path: リポジトリ内のJenkinsfileのパスを指定します。デフォルトはJenkinsfileです。
    • これで、Jenkinsは指定されたリポジトリからJenkinsfileを取得し、その内容に従ってパイプラインを実行するようになります。

8.5. パイプラインの実行と可視化 (Stage View)

パイプラインジョブを実行すると、通常のビルド履歴に加えて「Stage View」が表示されます（Pipeline: Stage Viewプラグインが必要です）。

Stage Viewは、パイプラインの各ステージの実行状況、実行時間、成功・失敗などを視覚的に表示してくれます。これにより、パイプラインのどのステージで時間がかかっているか、あるいは失敗しているかを一目で把握できます。

8.6. パラメータ付きビルド

手動でジョブを実行する際に、デプロイ先の環境やビルドオプションなどを指定したい場合があります。これを実現するのがパラメータ付きビルドです。

ジョブ設定の「General」セクションで「This project is parameterized」（このプロジェクトはパラメータ化されています）にチェックを入れ、「Add Parameter」からパラメータタイプ（String Parameter, Choice Parameter, Boolean Parameterなど）を選んで追加します。

パイプラインでパラメータを利用するには、params.<パラメータ名>のようにアクセスします。

“`groovy
// Jenkinsfile
pipeline {
agent any
parameters {
string(name: ‘DEPLOY_TARGET’, defaultValue: ‘staging’, description: ‘Deployment target environment’)
booleanParam(name: ‘RUN_E2E_TESTS’, defaultValue: true, description: ‘Run E2E tests?’)
}
stages {
// … Checkout, Build, Test …

    stage('Deploy') {
        steps {
            sh "deploy_script.sh --target ${params.DEPLOY_TARGET}"
        }
    }

    stage('E2E Tests') {
        when { expression { return params.RUN_E2E_TESTS } } // RUN_E2E_TESTSがtrueの場合のみ実行
        steps {
            sh "run_e2e_tests.sh"
        }
    }
}

}
“`

この設定を行うと、手動でジョブを実行する際にパラメータの入力を求められるようになります。

8.7. 認証情報 (Credentials) の管理と利用

データベースのパスワード、SSH秘密鍵、APIトークンなどの機密情報は、Jenkinsfileやジョブ設定に直接書き込むべきではありません。Jenkinsには「Credentials」ストアがあり、これらの機密情報を安全に一元管理できます。

  1. Credentialsの登録:
    • 「Jenkinsの管理」→「Manage Credentials」を選択します。
    • 「Stores scoped to Jenkins」や特定のドメインで、「Add Credentials」をクリックします。
    • Credentialのタイプ（Username with password, SSH Username with private key, Secret text, Secret fileなど）を選択し、必要な情報を入力します。
    • IDはパイプラインなどからこのCredentialを参照するために使用する名前です。分かりやすい名前をつけましょう。

  2. パイプラインでの利用:

    • Declarative Pipelineでは、credentialsヘルパーを使って、environmentブロック内でCredentialを環境変数として公開できます。

    “`groovy
    pipeline {
    agent any
    environment {
    // ‘my-docker-hub-credentials’というIDのUsername with passwordCredentialを環境変数DOCKER_USRとDOCKER_PSWに公開
    // withCredentials([usernamePassword(credentialsId: ‘my-docker-hub-credentials’, usernameVariable: ‘DOCKER_USR’, passwordVariable: ‘DOCKER_PSW’)]) {
    // sh ‘docker login -u $DOCKER_USR -p $DOCKER_PSW’
    // }

        // 'my-ssh-key'というIDのSSH Username with private keyCredentialを環境変数SSH_KEYに公開し、ユーザー名をSSH_USERに
    // withCredentials([sshUserPrivateKey(credentialsId: 'my-ssh-key', keyFileVariable: 'SSH_KEY', usernameVariable: 'SSH_USER')]) {
    //     sh 'ssh -i $SSH_KEY $SSH_USER@remote-server "ls -l"'
    // }

     // Secret textCredentialを環境変数API_TOKENに公開
    withCredentials([string(credentialsId: 'my-api-token', variable: 'API_TOKEN')]) {
         // このブロック内でのみ環境変数API_TOKENが利用可能
         stages {
             stage('Call API') {
                 steps {
                     sh 'curl -H "Authorization: Bearer $API_TOKEN" https://api.example.com/'
                 }
             }
         }
    }
}
// ... 他のステージ ...

    }
    ``
    *    withCredentials`ブロック内で定義された環境変数は、そのブロック内でのみ有効になり、コンソール出力などにも表示されにくくなるため安全です。

Credentialsを適切に管理することは、CI/CDシステムのセキュリティを確保する上で非常に重要です。

9. 高度なトピック（簡易説明）

Jenkinsは非常に多機能であり、様々な高度な設定が可能です。入門としては全てを理解する必要はありませんが、どのようなことができるのかを知っておくと、将来的に役に立ちます。

9.1. マスター/エージェント構成の詳細

小規模なプロジェクトや試用段階ではマスター単体でも十分ですが、CI/CDの規模が大きくなったり、異なるビルド環境が必要になったりすると、エージェント（旧スレーブ）の導入が不可欠になります。

  • エージェントの追加: Jenkins管理画面の「ノードの管理」から新しいノードを追加できます。エージェントマシンへの接続方法（SSH、Launch agent via execution of command on the master、Launch agent by connecting it to the masterなど）を設定します。
  • エージェントの活用:
    • 負荷分散: ビルド負荷を複数のエージェントに分散させ、ビルドキューの滞留を防ぎます。
    • 環境分離: 特定のOSバージョン、インストールされたソフトウェア、ハードウェアリソースなど、特定の環境要件を持つビルドを、その要件を満たすエージェントで実行できます。例えば、WindowsアプリのビルドはWindowsエージェントで、DockerイメージのビルドはDockerがインストールされたエージェントで、といった使い分けが可能です。
    • セキュリティ: マスターからビルド処理を分離することで、ビルドスクリプトの潜在的なリスクをマスターから隔離できます。
  • ラベル: エージェントにはラベルを付けることができ、パイプラインのagentディレクティブでそのラベルを指定することで、特定のタイプのエージェントでステージを実行するように制御できます。

9.2. セキュリティ設定

Jenkinsは多くのシステムと連携するため、適切なセキュリティ設定が非常に重要です。

  • 認証 (Authentication): 誰がJenkinsにアクセスできるかを制御します。デフォルトのJenkins独自のユーザーデータベースだけでなく、LDAP/Active Directory、GitHubアカウント、Googleアカウントなど、様々な認証方法がプラグインで提供されています。
  • 認可 (Authorization): ログインしたユーザーがどの操作（ジョブの表示、設定変更、ビルド実行など）を実行できるかを制御します。
    • Matrix Authorization Strategy: ユーザーやグループに対して、グローバルな権限とプロジェクトごとの権限を細かく設定できます。
    • Role-based Access Control (RBAC): より高度なロールベースの権限管理が可能です（プラグイン）。
  • Credential管理: 上述のCredentialsストアを利用し、機密情報を安全に管理します。
  • セキュリティアドバイザリ: Jenkins本体やプラグインの脆弱性情報が定期的に公開されます。常に最新版を利用し、アドバイザリに注意を払うことが重要です。

9.3. バックアップとリカバリ

Jenkinsの設定やビルド履歴、プラグイン情報は、JENKINS_HOMEディレクトリ（Dockerの場合は/var/jenkins_home、Linuxパッケージの場合は/var/lib/jenkinsなど）に保存されています。このディレクトリを定期的にバックアップしておくことが、障害発生時の迅速なリカバリに不可欠です。

  • 手動バックアップ: JENKINS_HOMEディレクトリを丸ごとコピーします。
  • Backup plugin: プラグインを利用して、設定情報などのバックアップを自動化できます。
  • Configuration as Code (CasC): 設定をコードとして管理するプラグインです。これにより、Jenkinsインスタンス自体は使い捨て（Ephemeral）に近くすることが可能になり、リカバリが容易になります。現代的なJenkins運用では推奨されるアプローチです。

9.4. モニタリングとロギング

Jenkinsサーバーの状態（CPU使用率、メモリ使用率、ディスク使用量など）や、ジョブの実行状況（キューの長さ、実行時間、失敗率など）を監視することは、安定したCI/CD環境を維持するために重要です。

  • Jenkinsの標準機能: ダッシュボードやビルド履歴から基本的な状態を確認できます。
  • Monitoring Plugin: パフォーマンス情報などを収集・表示するプラグイン。
  • 外部モニタリングツール連携: Prometheus, Grafana, Datadogなどの外部ツールと連携するためのプラグインもあります。
  • ログ: Jenkinsシステムログやジョブのコンソール出力を確認することで、問題の原因を特定できます。

10. Jenkinsを活用したCI/CD実践

これまでに説明したJenkinsの機能を使って、どのように典型的なCI/CDパイプラインを構築するのか、その全体像と実践のヒントを紹介します。

10.1. 典型的なCIパイプラインの例

開発者がコードをGitリポジトリにプッシュした際に起動する、典型的なCIパイプラインは以下のステージで構成されます。

  1. Checkout: Gitリポジトリから最新のソースコードを取得します。
  2. Build: MavenやGradleなどのビルドツールを使ってコードをコンパイルし、依存ライブラリを解決し、実行可能な成果物（JAR, WAR, Dockerイメージなど）を作成します。
  3. Unit Tests: 単体テストを実行します。これはビルドプロセスの一部として行われることも多いです。テスト結果はJUnitプラグインなどでレポート化します。
  4. Static Analysis: コード品質ツール（Checkstyle, FindBugs, SonarQubeなど）を使ってコードの静的解析を行います。
  5. Integration Tests: 結合テストを実行します。データベースや外部サービスなど、他のコンポーネントとの連携を確認します。
  6. Security Scan: セキュリティスキャンツールを使って、コードや依存ライブラリに脆弱性がないかをチェックします。
  7. Archive Artifacts: ビルドで生成された成果物やテストレポートなどをJenkins上に保存します。
  8. Notify: ビルドの成功または失敗を開発チームに通知します（Slack, メールなど）。

Jenkinsでの実装:

  • ジョブタイプ: Pipeline (Jenkinsfile) または Freestyle project (複数のビルドステップとビルド後の処理を組み合わせる)。
  • トリガー: Webhook (GitHub, GitLabなど)。
  • 各ステージ/ステップ: git, sh/bat (ビルドツールの実行), junit, プラグイン提供のステップ (SonarQubeなど)。
  • ビルド後の処理 (postブロックまたはFreestyleのPost-build Actions): archiveArtifacts, junit, slackSend/mail.

10.2. 典型的なCDパイプラインの例

CIパイプラインが成功した後に続く、典型的なCDパイプラインは以下のステージで構成されます。

  1. Promote / Trigger CD: CIパイプラインの成功をトリガーとして、CDパイプラインを開始します。
  2. Deploy to Staging: CIでビルドされた成果物をステージング環境にデプロイします。
  3. Automated E2E Tests: ステージング環境上で、ユーザーの操作をシミュレートするようなEnd-to-Endテストを自動実行します（Selenium, Cypressなど）。
  4. (Optional) Manual Approval: 必要に応じて、本番環境へのデプロイ前に手動での承認ステップを設けます。Pipelineではinputステップで実現できます。
  5. Deploy to Production: 本番環境にデプロイします。デプロイ戦略（ローリングアップデート、ブルー/グリーンデプロイメント、カナリアリリースなど）に応じて、複数のステップに分かれる場合があります。
  6. Post-Deployment Verification: デプロイが成功したか、アプリケーションが正常に動作しているかを確認します（Smokeテスト、ヘルスチェックなど）。
  7. Notify: デプロイの成功または失敗を関連チームに通知します。

Jenkinsでの実装:

  • ジョブタイプ: Pipeline (Jenkinsfile)。
  • トリガー: 前のCIジョブの成功 (Freestyleの「Build after other projects are built」またはPipelineのbuildステップ)、または手動トリガー、スケジュール。
  • 各ステージ/ステップ: デプロイ先に応じたステップ（SSH、Docker、Kubernetesプラグイン、クラウドプロバイダーのCLI実行など）、テストツールの実行、inputステップ、通知ステップ。
  • Credentials: デプロイ先のサーバーやクラウドにアクセスするための認証情報を安全に管理・使用。

CI/CDパイプラインは、これらのステージを組み合わせることで、コードの変更から本番環境へのリリースまでを自動化された一連の流れとして定義します。

10.3. Jenkins以外に必要なツール

JenkinsはCI/CDパイプラインの「オーケストレーター（指揮者）」ですが、それ単体で全てが完結するわけではありません。CI/CDを実現するには、以下のようなツール群と連携する必要があります。

  • ソースコード管理 (SCM): Git (GitHub, GitLab, Bitbucketなど), Subversion
  • ビルドツール: Maven, Gradle, npm, Yarn, Ant, makeなど
  • テストフレームワーク: JUnit, TestNG, NUnit, Pytest, RSpec, Mocha, Jestなど
  • 静的解析ツール: SonarQube, Checkstyle, FindBugs, PMD, ESLint, RuboCopなど
  • セキュリティスキャンツール: OWASP ZAP, SAST/DASTツールなど
  • アーティファクトリポジトリ: Nexus, Artifactoryなど（ビルド成果物やライブラリを管理・共有）
  • コンテナ技術: Docker (Docker Registry含む)
  • オーケストレーション: Kubernetes, Docker Swarm
  • クラウドプラットフォーム: AWS, GCP, Azureなど
  • 通知ツール: Slack, Microsoft Teams, メール
  • 監視ツール: Prometheus, Grafana, Datadogなど

Jenkinsはこれらのツールとプラグインを介して連携し、一連の自動化されたパイプラインを構築します。

10.4. 成功のためのヒント

Jenkinsを使ったCI/CDの導入を成功させるためには、ツールの使い方だけでなく、チームのプラクティスや文化も重要になります。

  • 小さなステップで始める: 全てのCI/CDパイプラインを一気に構築しようとするのではなく、まずはコードのビルドと単体テストの自動化といったCIの基本的な部分から始めましょう。
  • パイプラインを可視化する: Stage Viewなどを活用し、パイプラインのボトルネックや問題箇所をチーム全員で共有し、改善に取り組みましょう。
  • 失敗を恐れない、失敗から学ぶ: 自動化されたパイプラインは失敗することもあります。失敗をネガティブに捉えず、なぜ失敗したのかを分析し、再発防止策（テストの追加、パイプラインの改善など）に繋げましょう。
  • フィードバックループを確立する: ビルドやテストの結果をチームメンバーに素早く（理想的には数分以内に）フィードバックする仕組みを作りましょう。失敗が早く分かれば、修正も容易です。
  • チームで責任を持つ: 特定の担当者だけでなく、開発チーム全体でCI/CDパイプラインの状態に責任を持ち、必要に応じて改善を行います。
  • 自動化できるものは全て自動化する: 手動作業が残っている箇所は、ボトルネックになったりエラーの原因になったりします。可能な限り自動化を進めましょう。
  • Infrastructure as Code (IaC) の検討: サーバーや環境の構築もコード化することで、環境の再現性を高め、デプロイ関連の問題を減らせます。
  • 定期的な見直しと改善: CI/CDのプロセスは一度作って終わりではありません。チームの状況や技術の変化に合わせて、定期的にパイプラインを見直し、改善を続けましょう。

11. Jenkinsの現状と将来

Jenkinsは長年CI/CDの分野でデファクトスタンダードの一つとして君臨してきました。しかし、近年はよりモダンなクラウドネイティブなCI/CDサービスも登場しています。

11.1. Jenkinsの強みと弱み

  • 強み:
    • 圧倒的なプラグイン数: どんな環境やツールにも対応できる可能性が高い。
    • 高い柔軟性: 非常に複雑でニッチなワークフローも構築可能。
    • オープンソース: 自由に利用・改変・ホストできる。カスタマイズ性が高い。
    • 成熟したコミュニティ: 情報が多く、困ったときに解決策を見つけやすい。
  • 弱み:
    • 運用・管理コスト: サーバーのメンテナンス、プラグインの管理、セキュリティ対策など、自前で運用するにはそれなりの手間がかかります。特に大規模になるほど複雑になりがちです。
    • Pipeline as Code以外の設定のGUI依存: フリースタイルジョブなどの設定がUIに依存するため、設定の変更履歴追跡や再現性が課題になることがあります（CasCプラグインで改善可能）。
    • マスターのパフォーマンス問題: ビルド数が多くなると、マスターがボトルネックになることがあります（エージェントや分散ビルドで緩和）。

11.2. 類似ツールとの比較 (簡単な触れ込み)

近年、Jenkinsの代替となりうる様々なCI/CDツールが登場しています。

  • GitLab CI/CD, GitHub Actions: SCMホスティングサービスに統合されたCI/CD機能。リポジトリとパイプライン定義（YAMLファイル）が一緒に管理され、設定がシンプルです。SaaS型のため運用負荷が低いですが、カスタマイズ性や対応ツールの幅はJenkinsに劣る場合があります。
  • CircleCI, Travis CI: 人気のSaaS型CI/CDサービス。簡単な設定で迅速にCI/CDを開始できます。
  • TeamCity, Bamboo: CommercialなCI/CDツール。手厚いサポートや特定機能に強みを持つことがあります。

これらのツールはそれぞれ特徴があり、プロジェクトの規模、チームのスキル、必要な機能、運用方針（SaaSか自前運用か）などによって最適なツールは異なります。Jenkinsは自前運用で最大限の柔軟性を求める場合に、いまだに強力な選択肢です。特に、オンプレミス環境でのCI/CDや、レガシーシステムを含む複雑な連携が必要な場合にはJenkinsが有利なことが多いです。

11.3. コミュニティ活動、LTS vs Weekly

Jenkinsは活発なオープンソースプロジェクトであり、継続的に開発が進められています。

  • LTS (Long-Term Support): リリース頻度は少ないですが、安定性を重視したバージョンです。本番環境での利用に適しています。約3ヶ月ごとに新しいLTSバージョンがリリースされます。
  • Weekly: 毎週リリースされる開発版です。最新の機能やバグフィックスが含まれますが、安定性はLTSに劣る可能性があります。新しい機能を試したい場合などに利用されます。

通常、プロダクション環境ではLTS版を利用し、定期的に新しいLTS版へアップグレードすることが推奨されます。

コミュニティでは、メーリングリスト、フォーラム、Slackなどを通じて活発な議論や情報交換が行われています。また、世界各地でJenkinsに関するイベントやMeetupも開催されています。

12. まとめ

この記事では、Jenkins入門として、CI/CDがなぜ必要なのかという背景から始め、CI/CDの基本概念、Jenkinsの概要と特徴、インストールと初期設定、フリースタイルジョブの作成、SCM連携、プラグイン、そしてJenkinsパイプライン（Pipeline as Code）について詳細に解説しました。さらに、高度なトピックやJenkinsを活用したCI/CD実践の考え方、Jenkinsの現状についても触れました。

CI/CDは現代のソフトウェア開発において競争力を維持するために不可欠なプラクティスであり、Jenkinsはその実現を強力にサポートするツールです。Jenkinsを導入することで、以下のメリットを享受できます。

  • ビルド、テスト、デプロイといった反復的な作業の自動化
  • 問題の早期発見と修正コストの削減
  • コード品質の継続的な向上
  • リリースの迅速化とリードタイムの短縮
  • 開発チーム全体の生産性向上とコラボレーション促進
  • デプロイ作業に伴うリスクの低減

約5000語にわたる詳細な解説でしたが、Jenkinsの世界は非常に奥深く、ここで紹介できたのはそのほんの一部に過ぎません。しかし、この記事を通じて、JenkinsがCI/CDにおいてどのような役割を果たし、どのように基本的な設定を行うのか、そしてなぜPipeline as Codeが重要なのかといった核となる部分を理解していただけたかと思います。

次のステップ:

  • 実際にJenkinsをインストールしてみる: Dockerを使うのが最も手軽でおすすめです。
  • 簡単なジョブを作成してみる: GitHubなどの公開リポジトリにあるサンプルプロジェクトを使って、ビルドとテストを自動化するフリースタイルジョブやPipelineジョブを作成してみてください。
  • Jenkins公式ドキュメントを読む: Jenkinsの公式サイトには詳細なドキュメントやチュートリアルが豊富に用意されています。
  • 必要なプラグインを探す: 自分のプロジェクトやチームが必要とする機能を持つプラグインを探し、インストールして試してみましょう。
  • Pipeline as Codeに挑戦する: Jenkinsfileを書いて、CI/CDパイプラインをコードとして定義してみましょう。

Jenkinsは多機能ゆえに学習コストがかかる側面もありますが、一度習得すれば、ソフトウェア開発の自動化レベルを飛躍的に向上させることができます。ぜひ、この記事を参考に、Jenkinsを使ったCI/CDの自動化に挑戦してみてください。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール