デバッグ・サイクルを高速に回してコード品質を改善する（1） ―― 「繰り返しビルド＆テスト」に必要な環境とは
●ウォータ・フォール開発でも「インテグレーション」は繰り返し行う
さて次に，継続的インテグレーションで扱う「インテグレーション」の定義について考えてみましょう．ソフトウェア製品を開発する際のコーディング以降のプロセスとしては，以下が考えられます．
- ビルド（コンパイル，リンク）
- テスト（単体テスト，結合テスト）
- デプロイ（パッケージ作成，配布）
このビルド～デプロイのサイクルは，アジャイルではもちろんですが，ウォータ・フォール・プロセスにおいても頻繁に繰り返されます．特に，テスト段階でのバグ修正で必ず実行されます（図4）．
図4 ウォータ・フォール開発でもインテグレーションは繰り返される
狭義のインテグレーションはビルドのみを指しますが，テストが自動化でき，ビルドからデプロイまでを「インテグレーション」として継続的に行えれば，開発効率は大きく上がることでしょう．ここでは，ビルドからデプロイまでを含めて「インテグレーション」として捉えることにします．
●インテグレーションの中身を検討する
次に，インテグレーションに含まれる各プロセスについて，順に見ていきましょう．
（1）ビルド
ビルドの作業は大きく，以下の三つに分けられます．通常，この一連の作業は，バッチ・ファイルを作成することによりひとまとめに行われています．
- 構成管理（バージョン管理）からのソース・コード取得
- コンパイル
- リンク
（2）テスト
ビルドが成功したら，引き続きテストを実行します．さらに，ビルドやテストと並行して静的解析ツールによるコード・チェックを実行すれば，品質の強化につながります．また，デグレードを見つけるための回帰（リグレッション）テストを行うことで，出力物の品質を守ることができます．テストのレベルは，単体テスト，結合テストなど，どのレベルでも，自動化してプロセスに組み込めることが望ましいでしょう．
（3）デプロイ
デプロイは，Webアプリケーション・プログラムの場合，本番用サーバへのインストール作業などにあたりますが，組み込みソフトウェアの場合は，実機への書き込み（フラッシュ）や外部提供用のファイルのパッケージングなどが，それに当てはまります．この工程についても，自動化できるものは自動化して，継続的インテグレーションに取り込むとよいでしょう．
●継続的インテグレーションに必要な機能
継続的インテグレーションを実現するために必要な機能を挙げてみます．
（1）ビルド時間の短縮
継続的インテグレーションを実施する場合にネックとなりやすいのが，インテグレーションの処理時間です．処理時間を短くすることにより，開発とインテグレーションのギャップを少なくすることができます．
例えば，1回のビルドで2時間かかっているシステムでは，最新のソース・コードとバイナリの一致のために，少なくとも2時間かかることになります．もしその間にテストが行われたとしても，意味を持たない場合があります．テストを効率的に行うためには，ソース・コードとバイナリの一致しない時間をできるだけ少なくする必要があります．
ビルドで行われる処理をステップやプロシージャのような単位で分割し，それらをできる限り（矛盾が起きないように）並列実行することが可能であれば，それだけで処理時間を短縮することができます．例えば，ビルド作業中に，静的解析を実行することが可能な場合があります．しかし，一つのまとまった処理単位を，さらに分割することはできません．処理時間のかかるものについては，複数の計算リソース（マルチコアやマルチPC）に処理を分散させることができます．
ビルド時間の短縮の具体的な方法については，次回で解説します．
（2）並列処理実行時のフロー制御，リソース管理
通常のビルド・システムでも，コンパイルやリンクの処理結果によって，後に続く処理をそのまま実行するのか，中断するのかを制御できます．しかし，処理がシリアルに実行される場合は単純に処理結果で判断すればよいのですが，複数の処理を並列に行う場合には，並列に動作している処理の中断/継続を処理する必要があります．また，例えば「この処理は必ずこのサーバで行う必要がある」という処理にも対応できる必要があります．
（3）インテグレーションの結果の通知
ビルドを実施すると，膨大な量のビルド・ログが生成されます．その中から，必要な部分だけ抜き出してサマリを作成し，メールなどで通知したり，ログやスクリプトのバックアップをとる機能があることが望まれます．
例えば，ビルドやテストの結果（OK/NG）を記録しておけば，プロジェクトの品質指標として使えます（図5）．また，ビルド回数が極端に多い開発者や極端に少ない開発者を見つけることができます．ビルド回数が多くても成功が多ければよいのですが，失敗が多い場合，作業内容に問題があるかもしれません．逆にビルド回数が少ない開発者は，いくつかの変更をまとめてチェックしている可能性があり，確認，改善することができます．開発者としては嬉しくない機能かもしれませんが，管理者としては有用な機能となります．
図5 ビルド回数や結果をプロジェクトの品質指標として使う
継続的インテグレーションを簡単に実現するためには，以上の（1）～（3）の機能は必須であると考えます．さらに，複数プロジェクトでの利用では，次の二つの機能が必要です．
（4）部品化（テンプレート）
あるプロジェクトで継続的インテグレーションを導入した際に，次のプロジェクト，あるいは並行している別のプロジェクトへの展開を検討されると思います．その際，既に運用されている機能を，コピーして使用するのではなく，テンプレートや部品として使用し，保守にかかる工数を減らし，プロジェクト間での共有ができることは，複数プロジェクトを管理する際に必要です（図6）．
図6 機能は部品として流用したい
（5）スクリプトのアクセス制御
スクリプトに対するアクセス制御を分けられると安心です．スクリプトを変更できるのはスクリプト提供者のみで，使用者は参照と実行のみ可能なようにしておけば，スクリプト提供者以外が不正にスクリプトを書き換えてしまうことがなくなります．なお，大人数で運用する場合，Active DirectoryやLDAPと連携してユーザのグループごとに権限を設定できると効率の良い管理を行うことができます．そのほか，参照権限をプロジェクトごとに設定したり，マネージャはプロジェクトを超えて全体を見渡せる機能があると便利です（図7）．
図7 大人数で運用する場合は参照権限の制御も必要
まきた・ひろふみ
（株）エーアイコーポレーション
◆筆者プロフィール◆
牧田 宏史（まきた・ひろふみ）．エーアイコーポレーション 組込みテスト事業部に所属．通信機器ソフトウェア開発，携帯電話端末ソフトウェア開発，Symbian OS/ARMプロセッサの技術トレーニング講師を経て，現職．Electric Cloud社製品のサポートを主に，各種品質向上ソリューションの技術サポートを担当．鳥取県倉吉市出身．趣味はCDの収集．珍しいCDを見つけるとハッピー．四半世紀間のベスト・アーティストはBARBEE BOYS．メンバ5人にやられっぱなしです．
