NewsInsight

JJUG CCC 2011 Spring基調講演レポート

Jenkinsの生みの親が語る、継続的インテグレーションの未来

2011/06/06

　5月24日、日本Javaユーザグループ（以下、JJUG）の主催による「JJUG Cross Community Conference（以下、JJUG CCC） 2011 Spring」が行われた。JJUG CCCはJJUGが年2回開催している定例イベントであり、Javaに関する最新の動向や活用事例などが紹介される。

　本稿では、オープンソースのCIサーバ「Jenkins」の生みの親である川口耕介氏による基調講演の様子をお伝えする。

Jenkinsが目指すのは、コンピュータの“執事”

　「Jenkins」はソフトウェアプロジェクトのビルドやテストを自動化する継続的インテグレーション（CI：Continuous Integration）サーバの一種である。もともとは「Hudson」という名称で開発・公開されていたが、商標上の問題によってJenkinsに改名された。

　JJUG CCCの基調講演は、その生みの親であり現在もプロジェクトのクリエータを務める川口耕介氏を招いて行われた。同氏は、ソフトウェア産業を取り巻く仮想化やクラウドコンピューティングといった流れがCIに与える影響や、今後の開発ツールやコード品質検査の展望などについて語った。

　川口氏がまず取り上げたのは、「計算機の能力の向上がCIに、どのような影響を与えるのか」という観点である。CPUのマルチコア化や計算機の水平並列化によって、計算機の能力は今後ますます向上し、相対的に費用対効果も上がっていくことになるだろう。一方で、人件費の費用対効果はそうそう変わるものではない。

　このことから、今後は「コンピュータの計算能力をどう活用するか」がますます重要になっていくだろうと同氏は指摘する。そのための鍵となるのがサーバ側の自動化技術である。人間が対話的に使える計算機の数は限られているため、増えていく計算機の能力を生かすにはサーバ側で活用するしかないからだ。

　では、実際にどのように活用していくのか。現在IT業界を取り巻く1つの大きな流れとしてはクラウドおよび仮想計算機の普及がある。これをCIの観点から考えると、いくつかの新しい試みが可能になるという。

　例えばクラウド環境では、計算機のリアルタイムなプロビジョニングを自動で行える。これを利用すれば、テストごとに独立した計算機クローンを用意したり、QA（品質保証）テストからプロダクションまでを再配備なしに行ったりすることが可能になる。その他にも、ユーザーからはさまざまな場面で自動化による負担の軽減を望む声が上がっているという。

　開発ツールでも自動化が進展している。統合開発環境では非対話的なビルドが当たり前になりつつあるし、実行結果を機械処理できる形式で出力することによって、テストのレポートを自動で生成できるツールも増えている。

　「今後も、この傾向は続き、インストールの自動化や、実行経過の機械可読化などにも発展していくだろう」と川口氏は指摘する。その上で、「このように多くのサービスと潤沢な計算機を活用していくためには“執事”となる存在が必要になる」と続ける。Jenkinsが目指すのは、この“執事”のような存在というわけだ。

Jenkinsによる分散並列ビルド／テスト環境の活用

　Jenkins自体は、分散ビルドに対応して5年ほどが経過しており、すでに技術としては成熟している。数百台規模の計算機と、その利用状況を把握する基盤を持っており、それに加えて多数の計算機にまたがってプラグインを実行する仕組みを備えている。

　この分散環境を活用することによって、複数のマシンにまたがるジョブを作ったり、Jenkinsから一時的に計算機リソースを借りる分散スクリプティング基盤として利用したりすることが可能になった。

　これをさらに一歩進めれば、「リソースをある程度の長い期間借りられるようにしたり、借りたリソースの解放を自動化したりといった機能も実現できる」という。その他、「並列化を、もっといろいろな形態で活用できるようにすることも考えている」とのこと。例えば、並列処理をAntやGroovyのタスクとして使い慣れた形で定義・実行することが考えられる。

　また川口氏は、「ソフトウェアのテストの分野でも並列化の活用は大きなポイントになる」と語っている。同氏自身、複数のスレッドや複数のプロセスでのテストの並列実行に取り組んだ経験を持っているが、「今後は、それをさらに進めて、複数のマシンでの並列実行なども重要になってくる」という。

　これはJenkinsの基盤が活用できる分野である。またテストに関しては、「Jenkinsの持つ情報を利用することで、テストの実行順序を制御したり、失敗時により多くの情報を自動で集めて分析するなどの活用方法も考えられる」としている。

「こういったことは人間がやらなくてもCIサーバ側で可能なので、ビルドツールなどと連携しながら実現できたらと思います。とにかく人間の時間が貴重なので、その貴重な時間をどう温存するかという路線で進めていきたい」（川口氏）

分散バージョン管理システムにおける“関数としてのCI”

　続いて、川口氏は「CIを関数としてとらえる」というコンセプトを紹介した。具体的には、ビルド・テストを「ソースツリーから品質指標を得る関数（f:ソースツリー→品質指標）」ととらえる。この関数は、副作用はないが、計算には時間がかかるものである。そこで、「この関数の評価を非同期的に行うことで、効率的な品質検査を行えないか」という考え方だという。

　ただし、コンセプトとしては「f:ソースツリー→品質」だが、実際には「f:コミット→品質」とする方が現実的だという。ソースコードの識別や追跡が可能であり、マシン間の移動も容易だからである。そこで、このようなコンセプトと相性がいいのが、GitやMercurial、Bazaarなど「分散VCS（バージョン管理システム）」だと川口氏は言う。

　SubversionやCVSなど通常のVSCの場合、コミットされたソースコードは全員で共有される。品質検査の観点からすれば、「f:コミット→品質」の関数を実行するためにコミットをしたいわけだが、これだと品質検査が済んでいないものを共有することになってしまう。

　その点、分散VCSであれば、コミットは「VCSへの登録」を意味し、中央サーバにプッシュするまでは共有されない。この仕組みを活用することで、「f:コミット→品質」をサーバ側で非同期に行うことが可能になる。

「テストをローカルで実行する時代は終わりにしたい。人間の負担を減らすためには、サーバ側で行えることはサーバ側に任せたいわけです。サーバ側の遅延時間は増えますが、人間の時間さえ無駄にしなければ、それは問題にはならないはず。実装には試行錯誤の余地はありますが、“関数としてのCI”は有用な部品になるはずです」（川口氏）

クラウドや仮想計算機、分散VCS、自動化と連携

　最後に川口氏は、システム間に散在する情報の機械追跡について、開発業界（「Dev世界」）、品質保証業界（「QA世界」）、運用管理業界（「Op世界」）それぞれの傾向と、その中でのCIサーバの役割について説明した。

　まずDev世界では、ソースコードのコミットIDでの管理や、コードブラウザ、バグ管理などが発達し、機械による追跡性は高まっている。一方でQA世界では、ログに必要な情報が記録されていないケースが多く、機械追跡性は依然として低い。Op世界では自動化が進展しており、それに伴って機械追跡性が高まっている。これが三界の現状だという。

　川口氏は、「CIサーバは、この三界の架け橋になれる」と指摘している。例えば、ソースコードを識別するコミットIDと、バイナリを識別するチェックサム（Jenkinsの場合は「fingerprint」と呼ぶ）を、ひも付けるようにすれば、Dev／QA／Opの3つの業界をまたいでの追跡可能性が確保できる。

　さらに「この三界では、それぞれの局面で自動化が進められているので、この自動化を連携させていくことで、より複雑な作業の自動化が可能になってゆくだろう」と同氏は付け加える。そして「自動化が進んでいけば、追跡だけではなく集めた情報を使って積極的な働き掛けもできるようになる」と続ける。

「理想的には必要な情報をサーバが自動で集めてくれて、人間は決断を下すだけ、ということまでできれば、ソフトウェアエンジニアとしての人類に対する貢献になるかなと。とにかく、計算能力が増え続けていて、ソフトウェア開発者には、その新しい活用の仕方が求められていることは事実なわけです。幸いなことにクラウドや仮想計算機、分散VCS、自動化など、いろいろな要素技術が出そろってきています。これからのCIサーバは、そういうニーズを取り込んでいくべきではないかと考えています」（川口氏）