ビルドやテストを自動化してCI（継続的インテグレーション）を実現するJenkins。バージョンや製品ごとの開発環境の切り分けが難しいという課題があったが、コンテナー管理ツール「Docker」を併用することで解決できる。
Jenkinsによる自動ビルド・テストの動作環境として、「Docker」で作成したコンテナーを利用する――。ワークスアプリケーションズの遠藤博樹氏（Advanced Technology and Engineering Division 技術基盤開発グループ）は2014年6月、Jenkinsを使ったそんな新しいCI（継続的インテグレーション）の環境を稼働させた。
同社はERPパッケージソフト「COMPANY」の開発会社。ユーザー企業がそれぞれ導入時のバージョンをそのまま長年使いたいというニーズに応えるため、いくつものバージョンを保守し続けている。
ただし過去バージョンの保守は、容易でない。バージョンごとに依存するライブラリや、ビルドに必要なバイナリーファイルが異なるからだ。例えば同一の開発用サーバーで、あるバージョンのソースコードのビルドを実行した後に、それより古いバージョンのビルドを実行すると、ライブラリのバージョンが異なりエラーとなる。
解決策はいくつかあったが、どれも決め手に欠けた。バージョンごとに、専用のビルド・テスト環境をセットアップした開発用サーバーを用意しておくのは、コスト面の負担が大きい。ライブラリ管理ツールを使い、バージョンに合わせて切り替えるには、構成が複雑すぎる。メインのプログラミング言語はJavaだが、一部のモジュールはNode.js、Python、Rubyなどで書かれている。バイナリーファイルが必要なバージョンもある。
Dockerで専用ビルド環境を作成
そこで遠藤氏が目を付けたのが、コンテナー管理ツールのDockerだ（図1）。開発用サーバーにDockerを導入。ビルド・テストの実行時に、JenkinsがDockerに指示して各バージョンのビルド・テスト環境用コンテナーを作成する形態にした。
同社における具体的な流れは以下の通りだ。開発者がバージョン管理ツール（GitLab）の共有リポジトリーにソースコードをチェックインすると、GitLabはそのことをJenkinsに通知する。JenkinsはGitLabから、ソースコードとDockerの設定ファイル（Dockerfile）をチェックアウトする。JenkinsはDockerfileをDockerに読み込ませて、各バージョンに対応したビルド・テスト環境用コンテナーを作成する。
そのコンテナーの上でソースコードの自動ビルド・テストを実行する。ビルドツールにはMaven、単体テストツールにはJUnit、画面テストツールにはSeleniumを使う。一連の作業が完了したら、Jenkinsはビルド・テスト結果のレポートを作成し、コンテナーを消去する。自動ビルド・テストのたびに、コンテナーを作り、使い捨てる格好だ。
遠藤氏は「Dockerに起因する技術的な問題は生じていない。最も苦労したのは、既存環境の設定を読み解いてDockerfileを作成する作業だった。開発者が管理者に断らずJenkinsサーバーに手を入れてしまい、ドキュメントに記録されない、勝手な設定変更をすることが多々あった。今後はDockerfileで環境を定義することにより、勝手な設定変更を心配する必要がなくなる」と語る。
現在は、製品ごとにJenkinsサーバーを立てて運用している。しかしJenkinsとDockerを組み合わせた使い方なら、異なる製品を同一のJenkinsサーバーで自動ビルド・テストすることも可能だ。そのため「今後はJenkinsサーバーを一本化していきたい」（遠藤氏）という。