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

[中村知成，ヌーラボ]

CIのフィードバック

　CIの結果のフィードバックは重要です。自動的にビルドが実行されて、その結果何か予期せぬことが起きたときに即座に通知されるのがCIの利点ですが、適切なタイミング・適切な方法で通知されないと、異変に気づけないこともあり得ます。

　CIのフィードバックには、以下の宛先が考えられます。

1. メール
2. IRCや（グループ型の）チャットツール
3. ITS／BTS

　メールでの通知は、最も手軽にできます。メールアドレスは、ほぼ全ての皆さんが持っているでしょうし、利用しているでしょう。

　ただし、メールの問題点として、大量のメールに紛れてしまう可能性があることと、共有しにくいことが挙げられます。メールでの通知は手軽なことから、その他の情報の通知先となっていることが多いためです。

　また、メールは基本的に複数人で共有できるパーマネントリンクがないため、共有しにくいという欠点もあります。

　IRCやチャットツールは、プロジェクトメンバー間で容易に共有できます。ただし、プロジェクトによっては導入されていないこともあるため、CIのフィードバック先のためだけに用意することは、コストに見合わないかもしれません。

　ITS／BTSを宛先にすることも考えられます。CIツール上で発生したことをより厳密に管理したい場合、ITS上にチケットとして登録して管理することもあります。

　ただし、プロジェクトの初期フェイズでビルドエラーなどが相応に発生するなど、CIツールからフィードバックを受けることが一定以上多い場合は、都度ITSのチケットとして管理するのは、やり過ぎな場面もあるでしょう。

　保守運用のフェイズでビルドエラーは基本的には起こり得ない場合などでは、ITSで管理することが望ましい場面もあるかと思います。

CIのフィードバック

　ヌーラボでは、当初はメールで各開発者に対して通知していました。ただし、メールでのフィードバックには上述したように問題点があったこと、特にヌーラボでは福岡・東京・京都・シンガポールとオフィスが分散していることから共有のやりやすさという点を重要視しており、メールに代わる通知先を模索していました。

　現在では、自社で開発中の「Typetalk」というチャットツールに対して、フィードバックを投げるようにしています。また、プロジェクトによっては、厳密に管理することを目的として、Backlogに課題（チケット）として登録するようなプロジェクトもありました。

CI時のビルド時間

　CIにかかるビルド時間は、短ければ短いほど望ましいです。コミットした後にCIツールからのフィードバック（例えば、テスト失敗通知など）が即座に届くと、開発者の脳内キャッシュにも残っていて、すぐに問題へ対応できる場合も多いでしょう。

　ですが、30分以上経過してフィードバックが届いても、すでに次の作業に移っている可能性も高く、せっかく次の作業に集中していた状態が妨げられかねない恐れがあります。経験的には、可能ならば5分以内、できれば30分以内にビルド時間を抑えておきたいものです。

　ビルド時間を短くするには、いくつかの方法があります。

• 分割する
• 並行実行する
• ハードウェアをより高性能なものに変える

　ビルドを分割しただけでは全体のビルド時間は変わりませんが（むしろ、分割されたビルドの連携の手間を考えると、ビルド時間が長くなることもある）、体感的には短くできる可能性があります。

　例えば、ビルドに30分かかったとして30分後に結果が通知されるより、10分のビルド3つに分割して実行するようにしていると、30分待たずとも10分後もしくは20分後にビルド結果が通知されることもあります。

　また、ビルドを並列で実行するには、分割されていることが前提となっています。

　その他にも、定期的にリポジトリをポーリングして変更があった場合にビルドする方式より、コミット／プッシュ駆動で即座にビルドする方式の方が、より迅速にフィードバックを得やすいでしょう。

　Backlogチームでも、当初は20分ぐらいとそれなりの早さでフィードバックできていましたが、テスト数の増加に伴って最近は倍の40分かそれ以上かかるようになってきました。そこで、私たち自身でも活用しているBacklogにWebフック機能を実装してより迅速にフィードバックを得やすくし、さらに時間がかかっているテストを分割して並行実行できるよう見直しを進めています。

次回は、継続的な配布（Continuous Delivery）

　今回は継続的な統合（Continuous Integration、CI）の簡単な説明とヌーラボでの運用例を紹介しました。次回は、いよいよ本連載の集大成として「継続的な配布（Continuous Delivery）」を紹介します。お楽しみに。

CIをより深く学習するための参考書籍3選

　最後に、CIについてより深く学習するための参考書籍を紹介します。書籍の発行時期としては、さほど新しくないものもありますが、裏を返せば、それだけ昔から重要性が伝えられていたということです。これらの書籍は、CIについて学習する際にきっと役立つことでしょう。

• 「達人プログラマー」

　CIという言葉は出てきませんが、プロジェクトの自動化について取り上げられており、今回述べた話と通じることが説明されています。

• 「継続的インテグレーション入門」

　CIの概念や構成要素など、CIに関する基礎的な話が取り上げられています。

• 「継続的デリバリー」

　次回の話にも絡みますが、CIを含めた継続的にアプリケーション／サービスをユーザーへ届ける際に考慮することが紹介されています。

「次回」へ

著者プロフィール

中村知成

株式会社ヌーラボ所属。前職で課題管理・構成管理といった開発環境の整備に面白さを感じ、「Backlog」というBTSを提供しているヌーラボに転職。プライベートな活動では、日本Jenkinsユーザ会のスタッフとしてイベントの運営面を主に担当。横浜在住。