JenkinsとGitHubを使ったCI実践ガイド
2018年4月12日 // 11 min read
継続的インテグレーション(CI)を導入することで、「コードエラーの減少」「開発サイクルの短縮」「より短期間でのソフトウェアリリース」を実現できます。この記事では、CI導入の方法を紹介し、GitHubとJenkinsとのインテグレーションについて詳しく見ていきます。
CIが重要な理由
企業はこれまで以上に短期間でソフトウェアをリリースする必要に迫られており、CIはそのニーズに対応するための重要な要素となっています。CIを導入すると、チームは数分でコードをビルド、テスト、アップデートできるようになり、品質の向上および本稼働までの時間の短縮を実現できます。
日々テクノロジーが変化する環境では、チームは多種多様なツールを組み合わせて使用します。私達がGitHubをチームに最適なツールと自由に統合できるようにして、できるだけ多くの開発者の仕事をしやすくすることに注力しているのはそのためです。現在、GitHubは何百ものサードパーティー製ツールと統合できます。その中でも人気の高いものやインテグレーションに定評のあるものは、MarketplaceやWorks with GitHubディレクトリから入手可能です。
Jenkinsとは
Jenkinsは、市場で最もよく使われているCIツールの1つで、世界中で15万件以上インストールされています。GitHubとの連携が優れており、JenkinsにはGitHub.comとGitHub Enterpriseのプラグインがデフォルトでビルトインされています。また、 Pipeline-as-Codeなどのコンセプトに基づき、ビルドプロセス全体をGitHubにチェックインし、チームのコードのようにバージョンを付けることによって、監査やトレーサビリティに対応することも可能です。
GitHubとの連係

Jenkinsでは、GitHubのOrganization全体がスキャンされ、Jenkinsfileが含まれているリポジトリごとにPipelineジョブが作成されます。Jenkinsfileとは、Jenkinsを使ったプロジェクトのビルド、テスト、デプロイのプロセスを定義するテキストファイルのことです。また、コードがチェックインされた直後、または新しいpull requestが作成された直後にはPipelineジョブが実行され、成功したか失敗したかを示すステータスがGitHubに返されます。このプロセスにより、チェックインのたびにビルドとその後の自動テストを実行できるため、最良なコードのみがマージされます。バグを早期に自動検出することにより、本番環境で生じる不具合の数が減少するため、チームはより優れた、より効率の良いソフトウェアを開発できます。
また、Jenkins内で行われたデプロイメントをGitHubに返し、ライフサイクル全体を監査することも可能です。
JenkinsとGitHubのインテグレーション
Jenkinsの新しいUIであるBlue Oceanを使うと、これまでにないほど簡単にCIをGitHubワークフローに統合できます。開始するには、以下の手順に従います。
- 最新のBlue OceanプラグインとGitHub Pipeline for Blue Oceanを利用してください。GitHub Pipeline for Blue Oceanは一緒に自動インストールされる仕様になっています。Blue Oceanのインストールの詳細については、こちらをご覧ください。
- 新しいPipelineを作成し、リポジトリとしてGitHubを選択します。
- GitHubのPersonal API Access Tokenを入力し、Jenkinsからプライベートリポジトリにアクセスしてスキャンできるようにします。過去にこの操作を行っている場合、Jenkinsはこの手順をスキップする場合があります。
- ここにある手順に沿って組織を選択し、Jenkinsfileを自動検出するオプションを有効にします。組織内のリポジトリにJenkinsfileが含まれている場合は、Pipelineを追加できるようにします。
ステータスチェック
Pipelineの実行後、Jenkinsは自動的にビルドステータスをGitHubに返します。このステータスはPull Requestから直接確認できます。また、Pull Requestをマージする前に、ステータスチェックに合格する必要があります。ステータスチェックを必須にすることによって、ブランチの保護を特別に強化でき、適切にビルドおよびテストされたコードのみがマージされます。
デプロイメントAPI
Pull Requestは、コードに関する情報交換だけではありません。「その変更が行われた理由」「変更が展開した経緯」「変更をリリースするために行ったプロセス」の追跡記録としても機能します。Pull Requestにデプロイメントを記録し、開発から本稼働まで、デプロイメントAPIでプロセスを追跡します。
Jenkins PipelineからデプロイメントAPIにポストバックするには、以下の手順に従います。
- HTTP RequestプラグインとPipeline Utility StepsをJenkinsにインストールします。HTTP Requestプラグインは、PipelineでREST APIからデプロイメントAPIを簡単に呼び出せるようにします。一方、Pipeline Utility Stepsは、JSONレスポンスの解析を容易にします。
- 実際にデプロイする前に、デプロイメントAPIを使ってデプロイメントを作成します。
- 自社で決めているプロセスに従って、Jenkinsでデプロイメントを実行します。
- デプロイメントAPIを使って、デプロイメントのステータスを記録します。
- デプロイメントの詳細を、対応するPull Requestから直接確認します。
デプロイメントAPIを使用するPipelineの例をご覧ください。
その他のインテグレーション
Blue OceanではなくJerkins Pipelineが搭載された従来のUIを使用する場合、GitHub Branch Sourceプラグインが搭載されたGitHubのOrganizationでは、上述の機能をすべて作成できます。詳細については、こちらのドキュメントをご覧ください。
Blue OceanまたはJenkins Pipelineを使用しない場合は、GitHubプラグインをお試しください。webhookを自動管理し、Freestyle Projectのステータスを返すことができます。
従来のバージョン管理システム(VCS)では、指定した間隔でCIからVCSをポーリングして変更を確認する必要がありました。これによって、特定のポーリング間隔で変更を検出するだけでもVCSに大きな負荷がかかっていました。このような場合はコミットなどのイベントに応じてCIをトリガーする webhookを使用し、変更が行われた直後にチームに通知されるようにして、GitHubの負荷を減らすことをお勧めします。
詳細情報
リソースライブラリGitHub用に構築された、その他多数の優れたインテグレーションについては、MarketplaceやWorks with GitHubディレクトリをご覧ください。
具体的な質問やGitHub for Businessの詳細については、下記のフォームに入力して送信してください。
Tags