サイトリポジトリの品質モニタリング | マスタリングビルド職人

サイトリポジトリ内での品質モニタリング

サイトリポジトリの数はチームの数と同じとなるため、それぞれのサイトリポジトリについて、品質をモニタリングしないといけません。ここで云う品質とは、プログラムソースコードの品質です。プログラムソースコードの品質チェックは、静的解析チェックを行うためのCheckstyle、Findbugs、PMDが、動的チェックを行うためのJUnit、QunitなどのxUnitが有名です。

上記のチェック結果は、リポジトリごとにローカル環境へチェックアウトして検査を実施し、 CovertureやJacocoでレポーティングして、最後に全リポジトリを取りまとめていたのではないでしょうか。

これは、はっきり言って手間もかかりますし、マシンパワーのないローカルＰＣで実施することで時間もかかりストレスが溜まります。これを解消するためにSonarQubeというOSSの統合品質管理ツールを使用します。

SonarQubeは先ほど挙げた静的解析チェックと動的チェックの実行結果をＷｅｂで閲覧できるだけでなく、コードのステップ数、複雑度、重複率なども算出して総合的な品質のモニタリングを行えます。

また、MavenやJenkinsのプラグインも提供されているためビルドしたときに一緒に品質を測って保存しておく、といったことも行えます。

次は個々の品質チェックを見ていきましょう。

ソースコードの静的解析レポート： Issues

SonarQubeの場合、デフォルトではJavaのチェックが可能です。他の言語をチェックしたい場合は、プラグインを入れる必要があります。プラグインは以下から入手可能です。

http://docs.sonarqube.org/display/SONAR/Plugin+Library

デフォルトで入っているJavaの場合であっても、SonarQube独自のルールとFindBugsで大方のチェックが可能です。特別にプロジェクトで取り決めたルールが必要な場合は、CheckStyleなどを足すとよいでしょう。

SonarQubeで定義されている違反のレベルは以下の5つです。

Blocker: 致命的なバグを生むものです。ビルドにも影響があるので即時修正した方がよいものです。
Critical: バグ扱いのものです。なるはやで修正します。FIXMEはここで扱います。
Major: テストまでに修正した方がよいものです。TODOはここで扱います。
Minor: 修正の義務がない負債です。
Info: ただのインフォメーションです。対応の必要はありません。

Blocker～Majorは、単体テスト完了の条件としてAll 0になるように目標を定め、修正計画を立てます。 Minorを含めたルールの遵守率は80%を超えるようにコントロールします。

ソースコードの動的解析レポート：コード網羅率、単体テストの成功率

SonarQubeにJacocoプラグインを入れることで、Junitなどで実施した自動テストのカバレッジレポートをDBに保存し、 Web上で閲覧することができます。

SonarQubeで閲覧可能なカバレッジレポートは以下の3つです。

行網羅率：全ソースコードのステップ数のうち、どれだけのコードを通ったかレポーティングします。コード上通ったことのない箇所まで特定が可能です。
分岐網羅率： ifなど、すべての分岐パターンに対して、どれだけ網羅したかをレポーティングします。通るべき分岐数と実際に通った分岐数まで特定が可能です。
単体テストの成功率：自動テストの成功率です。この数値は常に100%となるようにしましょう。

カバレッジレポートを出すとなると、必ずC0（命令網羅率）を目指そうとする人たちが出てきます。これは大抵の場合、テストを通すためだけのテストとなってしまい、テストの意味がなくなるため辞めましょう。機能の重要度や難易度に合わせて、どこの機能を重点的に試験するのか、どの機能に対して自動テストを実施するのかなどをしっかり計画を立てましょう。

その他、品質チェック時に見ておくと良いもの

SonarQubeにはたくさんの品質チェック機能が付いています。いままでに挙げた以外でも、以下のものも見ておくと品質が上がります。

複雑度：ソースコードの複雑度を数値化したものです。ソースコードの保守のしやすさに直結するため、この値が小さくなるようにプログラムを書きましょう。
重複度：ソースコード中の同じ行数の比率を表したものです。該当箇所に不具合があって修正した場合に、同一の修正が入る箇所を示唆しているので、この値も小さくなるようにプログラムを書きましょう。
パッケージの絡み具合：パッケージの循環参照を表します。循環参照することでGCされるべきものがされない、といったことがあるため必ず修正するようにしましょう。

SonarQubeの位置づけ

プロジェクトの状況が数値化されると、特にオフショア開発などの委託開発においては、受け入れの条件としてその数値を使いたくなることでしょう。これは是非そうして構わないのですが、この数値目標達成が一番にならないように、相互に認識を高める必要があります。

特にオフショア開発に、数値目標の取り扱いが伝わっていないと、これを何としても達成するためにプロダクトコード側をいじってテストしたり、警告を消すためにコメントアウトしてみたりと、笑えない事例がたくさん報告されています。あくまでも数値は、普段と何か違ったことが起きてるサインだ、という位置づけで運用するようにしましょう。

運用させる

ビルド職人のしごとは、環境を作ることにあらず、全開発拠点の全開発者に運用してもらい、継続的に品質をモニタリングしてもらうことにあります。毎日Jenkinsのインテグレーションの結果を見て、Sonarのレポートに目を通し、各開発チームの品質タイムラインにの異変に気を配りましょう。