膨大なビルド・テストで泣かないための継続的統合／CI実践ノウハウ：DevOps時代の開発者のための構成管理入門（4）（1/3 ページ）

「DevOps」という言葉にもあるように、ソフトウェア構成管理は、インフラ運用に取り入れられるなど、変わりつつある時代だ。本連載では、そのトレンドにフォーカスして、現在のソフトウェア開発に有効な構成管理のノウハウをお伝えする。今回は、Jenkinsをはじめ、ツールが格段に使いやすくなってきた継続的インテグレーションについて、概要やメリットに加え、実践ノウハウを事例とともに紹介。

[中村知成，ヌーラボ]

　今回は、継続的な統合（Continuous Integration、CI、継続的インテグレーション）について紹介します。

CIとは、継続的な統合とは

　皆さんは、CIという言葉を聞いたことがあるでしょうか？ CIとは、1度限りもしくは数回限りではなく、継続的に小まめにビルドを実行していくプラクティスです。

　ビルドが指すものは扱っているプロジェクトや言語／フレームワークによっても異なりますが、コンパイルやテスト・パッケージングやインスペクションなどを思い浮かべてもらうといいでしょう。CIでは、リリース直前に1度実行するのではなく、コミットのたびにコンパイルやテストなどを行います。

　デイリービルド／ナイトリービルドなど、継続的にビルドを行うと概念は昔からありました。ただ、Jenkinsをはじめ、CIを実現するツールが格段に使いやすくなってきたことや、CIに割くハードウェアリソースが用意しやすくなってきたこと、CIの概念や有用性が一般に認められてきたことなどから、CI環境を整えやすくなってきました。

　そして、いまやCIは近年のソフトウェア開発に欠かせないものになってきています。

CIの3つの利点

　CIのメリットを、下記にいくつか取り上げます。

1. 想定外の状況が起こったときに、素早く検知できる
2. 開発者の環境依存の問題を検知しやすくなる
3. ビルドが属人化せずに画一的になりやすい

　1は、最初に理解できるCIのメリットでしょう。CIでは、とにかく頻繁に小まめにビルドを行うので、想定外の状況（例えばバグを仕込んだ場合）も即座に検知できるようになります。バグを仕込んでから時間が経てば経つほど、その修正に時間を要するようになるのはIT技術者の皆さんなら感覚的に理解できるでしょうから、CIを導入して早め早めにバグを検知することは重要なことです。

　2については、いわゆる「私の環境では動くのですが……」というやつですね。開発者の環境では正しく動作していても、その他の環境では動かないのはよくあることです。CIを導入していると、開発者以外の環境では動かないという問題を早期に検知できるようになります。

　3は、間接的なメリットとなりますが、大事なことです。本連載で、たびたび紹介しているように、最近のソフトウェア開発では素早くリリースしてフィードバックを得ることが求められています。その際、属人化されている作業があると、効率化を進めるときに属人化された点がボトルネックになりやすいです。

　CIを導入していると、CIツールがビルドできるように整備されていくため、自然と属人化された作業を排除していくことができます。

DevOps時代のCIツールの用途―― cronの代替としてのJenkins

　CIツールは、上記で説明してきたようにソフトウェアのビルドを行うこともできますが、それ以外の用途にも用いることができます。

　例えば、Jenkinsをcronの代替として使用している方もいます。

　多くのCIツールでは、シェルスクリプトやWindowsバッチスクリプトを定期的に実行できる機能や、実行結果のログをWebブラウザ上で確認できる機能、エラーが発生した場合に特定の宛先にメール通知する機能など、日々の定期タスクを処理するための機能が備わっています。

　cronをはじめとした各種コマンドの方が手軽に実現できる方もいるでしょうが、定期タスクの実行結果を確認する必要がある人全てがコマンドの扱いに慣れているかというと、そうではないこともあるでしょう。また、Windows環境だと、そもそも定期タスクを実行する環境を整えるのが面倒なのもあるでしょう。シェルの実行も要求されるDevOps時代の開発者にとっては、cronよりJenkinsの方が重宝するかもしれません。

　携わっているプロジェクトがCIツールに載せるまでの環境が整っていないためにCIツールの導入をためらっている方も、こういった用途から使用を始めるのもいいのではないでしょうか。

コラム：CIツールと他のツールとの違い

　CIツールは、本連載で取り上げた他のツール（ITS／BTSやSCM）と性質的に違うところがあります。他のツールでは、プロジェクトに携わる全ての人のプロセスに影響するのに対して、CIツールは他の人のプロセスに影響しないというものです。

　ITS／BTSでは、基本的にプロジェクトメンバーが全員一緒に使わないと意味がないものですし、SCMについても同様のことがいえます。おのずと、トップダウン的に使用を強制するものとなりがちです。いくら良いものでも、トップダウン的にこれを使ってくださいといわれるのは、心理的に従いづらいという方もいるでしょう。

　ところが、CIツールは「思い立った人がまず入れてみる」ことが可能です。個人でCIツールを入れても、他の人は特にやらなければいけないというものはありません。人知れずCIツールを導入して、簡単なところ（例えば、ビルドエラーが起きた場合はコミット者にメールを通知するなど）から運用を始めて、だんだんとその存在価値を認めさせるというやり方を取ることができます。

ヌーラボにおけるCIツールの運用事例

　ここまでの話は、CIに関する一般的な話として各所で取り上げられていますので、ある程度は把握されている方もいるでしょう。そこで、ここからはヌーラボでの運用事例についてお話します。

　なお、ヌーラボではCIツールとしてJenkinsを利用していますが、Jenkins固有の話はそこまで多くはなく、他のツールに置き換えても大枠の考えは参考にできると思います。