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

[中村知成，ヌーラボ]

CI運用の方針

　CI運用の方針としては、CIを利用するハードルを下げて極力手間なしで使えることを念頭に置いています。具体的には、以下のようなことを取り入れています。

1. CIツールでは権限管理せずに、全員に参照／変更を許可する
2. CIツールのユーザーー認証をITSと連動させる

　1については、厳密に権限管理することより誰でも利用できることを重視しているため、このような方針を採っています。ビルド結果の参照などのread系の操作は、ログインなしでできます。設定変更やビルドの手動実行などのwrite系の操作についてはログインを強制していますが、ログインすれば誰でも変更可能にしています。

　これも、設定変更できる人を制限するというよりは、変更が行われたときに誰が行ったかを追跡できるようにするためです。

　上記のように、CIツール上のアクセス制御を緩めにしている代わりに、社内イントラからのみアクセスできるようにしています。CIツール上にはバージョン管理システムからcheckoutしてくるソースコードも展開されますし、CIツールを基点として継続的デリバリーを取り入れている場合は、CIツールから提供しているサービスも制御することができるようになります。

　この辺のアクセス制御については、CIツールで扱っている情報と利便性とのトレードオフを、各プロジェクトごとに考慮する必要があります。

CIツールのアクセス権限

　2は、利用しているサービスの認証を統一するための設定です。ユーザー認証が各サービスごとに異なると、利用のハードルが上がってしまいます。

　私たちは自社サービスのBacklog（バージョン管理システムも同梱）を利用していますが、CIツールのユーザー認証もBacklogと連動させたいと考え、そのためのJenkinsのプラグインを作成しました。このことによって、ITS／バージョン管理／CIツール、全てのツールで同じユーザーでログイン可能となっています。

　なお、BacklogではLDAP認証など外部の認証システムと連携できないために、CIツールをBacklogと連携させる手段を取りました。外部の認証システムが利用できる環境であれば、そちらにユーザー認証を任せる方が都合が良い場面もあるでしょう。

CIツールのユーザー認証

CIの対象

　ヌーラボでは、さまざまなものをCIの対象としています。各種アプリケーションのコンパイルや単体テストはもちろんのこと、テスト用DBの初期化など、アプリケーションのビルドに必要な処理も併せて行っています。その他、SphinxやMarkdown記法で記載されたドキュメントをHTML形式に変換するなど、ソフトウェア以外にも活用しています。

　一部、「継続的な配布」の領域となりますが、ドキュメントや成果物は、ITSに転送して管理しているものもあります。前述した通り、CIツールはイントラ内からでしか参照できないようにしていることと、IT技術者以外のメンバーはCIツールの扱いに慣れていない人も多いため、プロジェクトメンバーにとってよりアクセスしやすいITS上で扱えるようにするためです。

CIツールからITSへ転送

　ヌーラボでは、各自の好みのエディタ／IDEを使っても構いません。ただし、CIツール上でビルドできるように、エディタやIDEの特別な機能に依存してはならず、コマンドで実行できるようにしておく必要があります。

CIで行うテスト

　ここで、CIで行っているテストについて紹介します。

　全ての条件・パスを網羅してカバレッジ率100％を維持できれば理想ですが、実プロジェクトでは、それほどの費用・時間を取れないことが多いでしょう。限りあるリソースから、取捨選択をしていく必要があります。

　そこで、例えばBacklogチームでは以下の点を中心にテストを作成するよう心掛けています。

• DAO層のテスト
• 外部公開しているAPIのテスト
• メール送信／メール文言のテスト（多言語化されたメール含む）

　データベースのアクセスは、アプリケーションにとって最も重要な部分の1つです。Backlogチームでは、自動生成されるSQLを除いて、全てのSQLに対してテストを用意するようにしています。

　残り2つの機能に関しては、普段は使用しませんが、網羅的にテストを用意しやすい部分に対してのテストです。Backlogを開発している私たち自身も通常業務でBacklogを利用しているため、通常の利用範囲ですと不具合には割と早く気付くことができます。

　ただし、APIや（日本語以外の）メールについては、普段から利用しているわけではありません。こういった部分については、他の機能より念入りにテストを記述しておき、不具合をテストで検知できるようにしています。

　また、上記で取り上げたテストは主にWebアプリケーションのサーバサイド側の話でしたが、最近では下記の領域のテストも積極的に取り入れています。

• クライアントサイド側のJavaScriptのテスト
• Webブラウザを使用したテスト
• サーバ構成のテスト

　最近では、使いやすいアプリケーション／サービスを実現するためにJavaScriptの重要性が増しており、それに伴ってBacklog内で使用しているJavaScriptの比率も高くなってきています。

　Backlogチームでは「Grunt」＋「Jasmine」＋「PhantomJS」を用いて、JavaScriptのファイルが変更された際に自動でJavaScriptのテストを実行するようにしています。ここでのテストは、Webブラウザに依存しない部分を中心にテストします。

• 関連記事「フレームワークで実践！ JavaScriptテスト入門（2）：PhantomJSとJasmineで振る舞い駆動開発なJavaScriptテスト」

　併せて、Webブラウザを使用したテストも整備を進めています。単体テストが通っていても、実際にブラウザを使用した操作が正しく行えなかった場合、ユーザーから見たら正常に動作していないと見なされるからです。この類のテストは、テストの作成やメンテナンスコストが大きくなりがちなので、テストすべき範囲をよく検討しておく必要があるでしょう。

　Backlogチームでは、主に正常シナリオをテストするようにしており、「Selenium WebDriver」のGroovyラッパーである「Geb」を使用しています。Javaに慣れたIT技術者でも理解しやすく、なおかつJavaの冗長性を排除して記述できるGroovyをテスト作成に用いることによって、テストの作成コストを減らすようにしています。

　最後は、サーバ構成のテストについてです。最近はサービスの実現にクラウドを利用することも多くなってきています。クラウドでは比較的自由にサーバ構成を変更できますが、変更した内容が正しいことの確認も併せて必要となります。

　ヌーラボでは、「serverspec」を利用してサーバ構成に対するテストの整備も進めています。

　もちろん、どのテストに対してもCIツール上でテスト実行しており、何か不具合があれば即座に検知して通知されます。