Ruby版 CIツール導入ガイド
リポジトリへのプログラムコードの登録と同時に決められたジョブを実行し、その結果を開発者にフィードバックするのが CI の基本的な動作だ。では実際にどのようなジョブを実行するべきだろうか。今回は CI で実行されるジョブについて、その概要を紹介しよう。（前回、第1回 CI の概要:CI の概要と、どのようなツールが存在するのかについて紹介する）
- 静的コード解析
- コーディングスタイルチェック、および修正
- ドキュメント自動生成
- ユニットテスト
- カバレッジ解析
- UIテスト
- ビルド
静的コード解析
プログラムの構造に関する事柄を、実行する事なく解析するのが静的コード解析である。例えば以下のような事を指摘してくれる。
不要変数、不要関数調査
プログラムの中で利用されていない不要な変数や関数を指摘する。特に変数宣言の不要な PHP や Ruby のようなスクリプト言語で有効であり、スペルミス等により評価されない変数を抽出できるため、バグの可能性をつぶす事ができる。PHP用の実装として、PHPMD がある。
循環的複雑度解析
プログラムの分岐が複雑な関数を指摘する。関数の中にひとつの if 文がある場合、コードの流れは2通りになる。if 文が2つあれば4通り、3つあれば8通りとなり、分岐の数が増えると指数的にプログラムの経路は増えていく。あまりに経路が増えすぎた関数はテストが困難になり、一度も実行されない経路を残したままリリースされる事につながるだろう。このような問題を指摘してくれるのが循環的複雑度解析である。PHP用の実装として、PHPMD がある。
重複コード検出
ソースファイル内に似た部分が存在しないかどうかをチェックする。開発者はしばしば、似た機能を作成する時にソースファイルをコピーし、新しい機能に必要な部分を修正したりする。これは元の機能に影響を与える事なく作成できるというメリットがあるが、保守性が著しく低下するデメリットが上回る事の方が多い。これらを指摘するPHP用の実装として、PHPCPDがある。
以上のように、単に実行するだけでは分からないさまざまな問題を指摘してくれるため、潜在的なバグや将来バグが発生しやすい箇所を修正するのに役立てる事ができる。また、プログラムの構造ではなく変数名やインデントの適切さ等について分析するツールもある。これも静的コード解析の一種であるが、次の「コーディングスタイルチェック、および修正」で紹介しよう。
コーディングスタイルチェック、および修正
多人数で長年保守されるようなコードの場合、コーディングスタイルを統一する事は重要だ。コーディングスタイルが統一されていないと、思わぬ不便を強いられる事もある。例えばあるプログラマは改行コードとして LF を利用し、別のプログラマは CR+LF を利用していたとする。この2人が交互にリポジトリへの登録を行うと、差分抽出プログラムが全行に変更が発生したと認識する場合もあるだろう。こうなってしまうと、どのような変更が行われたのかを追跡するのが困難になる。また変数やクラスの命名規則が統一されていなければ全体としては読みにくいコードになり、やはり不便だ。こういった不便さ、メンテナンス性の悪さを取り除いていくために、プロジェクトごと、あるいは部署ごと、会社ごとにコーディングスタイルは統一していきたい。
しかし、コーディングスタイルの統一は分かってはいてもおざなりにしてしまう事も少なくない。間違っていてもプログラムの動作には支障が無いため、見つけにくいという問題もあるだろう。PHPCS や php-cs-fixer と言ったツールでは、コーディングスタイルをチェックしたり、コーディング規約に沿うように変換を行ってくれる。
ドキュメント自動生成
プログラム内に記述されたコメントからリファレンスマニュアルを自動生成するツールである。PHP 用の実装として、phpDocumentor や phpDox がある。また、多くの言語で利用可能な Doxygen は PHP にも対応している。色々な実装があるが、複数の言語を利用しているなら Doxygen がお勧めかも知れない。
リファレンスマニュアルが自動的に生成される事のメリットについては、改めて語るまでも無いだろう。特に多人数で開発しているプロジェクトならなおさらである。ただし、ドキュメント自動生成ツールを利用する場合、規約に従ったコメントを記載する事が必要であり、これもまた開発中におざなりになりがちな要素だ。コーディングスタイルをチェックするツールの中には、ドキュメント生成ツールが認識可能なコメントが存在しているかどうかをチェックしてくれる物もあるので活用していきたい。
ユニットテスト
プログラムを関数やクラスの単位（ユニット）に分割し、個々のユニットのテストを自動的に行うツールである。PHP用の実装としては PHPUnit がある。
個々のユニットのテストをしっかり行う事でユニット単位での品質を担保し、全体の品質を上げる事が可能になる。ただし、ユニットテストツールを効率良く活用するためにはテストしやすいユニットで構成されている必要があり、既存のプロジェクトに後から導入するのは難しい。また、自動実行させるための、テストスクリプトを作成しなければならない。
ユニットテストはコードの品質を高めるために極めて有効な手法だと言える。CIを活用していくなら是非ユニットテストは導入していきたい所だが、初期導入時には困難を伴う事も多い。今までユニットテストを行ってきていないなら、CI に慣れてきてからの導入でも良いだろう。
カバレッジ解析
ユニットテストを行う際、プログラムの経路の何パーセントを網羅したかの統計情報を解析する事をカバレッジ解析と言い、その網羅率をカバレッジ率と言う。カバレッジ解析を行う事により、テスト中に一度も通過しなかったコードがあるかどうかを確認できるので、テストが十分であるかどうかを確認できる。PHP 用の実装としては PHPUnit がある。ただし XDEBUG を有効にする必要がある。
UIテスト
アプリケーションを自動操作し、特定の入力に対し期待した結果が得られるかどうかをテストする。WEBアプリケーション用の Selenium が代表的な実装である。
ユニットテストが各クラスや関数等小さな単位でテストするのに対し、UIテストは結合テストの自動化である。またユニットテストにおいてはユニットの詳細仕様を把握している者にしかテストコードを記述できないのに対し、UIテストは外部仕様を理解している者なら記述できるというメリットがある。さらにプログラムコードにアクセスする事なくテストが可能になるのでアウトソースしやすい部分でもある。
ユニットテスト程粒度の細かいテストを行う事はできないが、既存プロジェクトに組み込むならば、ユニットテストよりはるかに導入しやすい。
ビルド
昨今のWEBアプリケーションでは CSS や JavaScript を最小化したり圧縮したりして最適化する事も増えてきた。これらは専用のツールで行う事になるが、CIの一環として行う事もできる。JavaScript を最小化する場合、それに伴い期待した動作が行われなくなるケースもある。CI により最小化と同時にテストが行われるようになれば、そう言った問題にも気づきやすくなるだろう。
また、C や Java 等のコンパイル型言語の場合、正常にビルドできるプログラムコードが登録されたかどうかは、まず最初に確認しなければならない事だ。コンパイル型言語においては、実際にコンパイラを走らせてビルドの結果を確認する事も良く行われている。
まとめ
今回は CI で実行する各ツールの概要を紹介した。次回は実際にいくつかのツールをインストールし、実行した結果を紹介していきたい。
次回
第3回 さまざまなジョブ(1):CIのジョブとして利用可能なRuby用のツールのインストール方法等
本ブログは、Git / Subversionのクラウド型ホスティングサービス「tracpath(トラックパス)」を提供している株式会社オープングルーヴが運営しています。
エンタープライズ向け Git / Subversion 導入や DevOps による開発の効率化を検討している法人様必見！
「tracpath(トラックパス)」は、企業内の情報システム部門や、ソフトウェア開発・アプリケーション開発チームに対して、開発の効率化を支援し、品質向上を実現します。
さらに、システム運用の効率化・自動化支援サービスも提供しています。
”つくる情熱を支えるサービス”を提供し、まるで専属のインフラエンジニアのように、あなたのチームを支えていきます。
No Comments