メインコンテンツまでスキップ

SonarQube

· 約11分
tanzhuo

はじめに​

コードが書き終わって動いたとしても、それが良いコードだとは限りません。この記事では、SonarQube について自分なりに整理した内容を記録しておきます。どんな問題を検出できるのか、裏側でどう動いているのか、そして CI/CD の中でどう使うのか、という観点です。

なぜこのテーマを 1 本の記事として書く価値があるのでしょうか。コード品質の問題には、「書いているときには見えず、問題が起きたときには高くつく」という特徴があるからです。人手による Code Review である程度は食い止められますが、レビュアーの労力と経験に依存しますし、多くの繰り返し作業(null チェック、リソースのクローズ忘れ、ハードコードされたパスワードの確認など)は完全にツールに任せられます。チームの規模が大きくなると、統一された自動化済みの品質基準がなければ、コードベースはあっという間にバラバラの書き方になってしまいます。

SonarQube はコード品質管理のためのオープンソースプラットフォームで、開発プロセスの中でコードに潜む問題を継続的に検出する手助けをしてくれます。
静的コード解析、コードカバレッジの集計、多角的な品質指標を通じて、SonarQube はコードが本番環境に入る前に欠陥、セキュリティ脆弱性、パフォーマンス上の懸念を発見し、システム全体の安定性を高め、後々のメンテナンスコストを下げることができます。

チーム開発や継続的インテグレーション環境において、SonarQube は通常**コード品質のゲートキーパー(Quality Gate)**として使われ、コード品質チェックの自動化と標準化を実現します。

動作の仕組み​

まずは SonarQube がどう動くのかを簡単に説明します。仕組みを理解すれば、後の設定は難しくありません。

SonarQube の解析は静的解析に分類されます。コードを実行せず、ソースコードを構文木に解析し、ルールエンジンで既知の問題パターンとマッチングします。全体のアーキテクチャは 2 つの役割に分かれています。

  1. Scanner(スキャナー側):ビルドマシン上で動作し、ソースコードの解析、ルールの実行、カバレッジレポートの収集を担当し、解析結果をサーバー側に送信します。Maven、Gradle、コマンドラインそれぞれに対応する Scanner があります。
  2. Server(サーバー側):履歴データの保存、Web レポートのレンダリング、Quality Gate の判定を担当します。各スキャン結果は過去のバージョンと比較されるため、品質のトレンドを追うことができます。

Quality Gate は本質的にしきい値アサーションの集合です。たとえば「新規コードの Bug 数が 0」「新規コードのカバレッジが一定割合以上」などです。スキャン完了後、サーバー側が 1 条件ずつ判定し、1 つでも満たされなければ全体のステータスは失敗になります。CI パイプラインはこのステータスをもとにリリースを中断するかどうかを判断できます。これこそが「実行後にレポートを眺めるだけ」のツールとの決定的な違いです。結果がプロセスをブロックできるのです。

もうひとつ触れておきたいのが「新規コード(New Code)」という概念です。既存の古いプロジェクトでは、すべての過去の問題を一度に修正するのは現実的ではありません。SonarQube のデフォルト戦略は、新規追加・変更されたコードにのみ厳しく要求し、既存の問題は徐々に消化していくというものです。これによって古いプロジェクトでもスムーズに導入できます。

コード品質の向上​

SonarQube はコード内の潜在的な問題を自動検出できます。たとえば:

  • コード欠陥(Bug)
  • セキュリティ脆弱性(Security Vulnerabilities)
  • コードスメル(Code Smell)
  • 潜在的なパフォーマンス問題

これらの問題の深刻度は順に下がっていきます。Bug は高い確率でエラーを起こすロジックで、たとえば条件が常に真になる、null ポインタ参照の可能性があるといったものです。セキュリティ脆弱性はインジェクションやハードコードされた認証情報のようなリスクに対応します。コードスメルは正しさには影響しないものの、コードをどんどん変更しづらくしていくもので、たとえば長すぎるメソッドや深すぎるネストなどです。SonarQube は各問題に深刻度レベルと修正の見積もり時間を付与するので、優先順位付けがしやすくなります。

コード保守性の向上​

SonarQube はコードを多角的に分析します。たとえば:

  • 複雑度
  • 重複コード
  • テストカバレッジ
  • 技術的負債(Technical Debt)

これらの指標を通じて、開発者はシステムの健康状態をより直感的に把握し、的を絞ったリファクタリングや最適化を行えます。

ここでいう技術的負債はとても直感的な指標です。修正待ちのすべての問題の見積もり工数を合計すると、「借金を完済する」のに必要な時間が得られます。必ずしも正確ではありませんが、トレンドには意味があります。技術的負債が増え続けているなら、チームは未来の開発効率を前借りしているということです。

開発者はコードのリリース前にこれらの問題を発見・修正でき、本番環境での障害を減らすことができます。

検出能力そのもの以外にも、SonarQube にはエンジニアリング実践上いくつかの利点があります。

  1. 豊富なプラグインエコシステム:SonarQube は多くのプログラミング言語とフレームワークをサポートし、豊富なプラグインエコシステムを提供しています。プロジェクトの要件に応じて適切なプラグインを選び、機能を拡張できます。
  2. 継続的インテグレーション・継続的デプロイ:SonarQube は継続的インテグレーション(CI)や継続的デプロイ(CD)ツールと統合でき、コードチェックと品質測定を自動化することで、すべてのビルドが良好なコード品質を持つことを保証します。
  3. チームコラボレーション効率の向上:SonarQube は集中管理型のプラットフォームを提供し、チームメンバーが統一された場所でコード品質と各種指標を確認できるため、チームコラボレーションの効率向上に役立ちます。
  4. より良いコードメンテナンス:コード品質指標の分析を通じて、開発者はコードの健康状態をより深く理解でき、より的を絞ったメンテナンスと最適化を行えます。

導入例​

サンプルコード:
Java プロジェクトがあると仮定します。まずプロジェクトに SonarQube の Maven プラグインを導入し、次のコマンドを実行して静的コード解析を行います。

<!-- Maven プラグイン設定 -->
<build>
    <plugins>
        <plugin>
            <!-- SonarQube 公式提供の Maven Scanner プラグイン -->
            <groupId>org.sonarsource.scanner.maven</groupId>
            <artifactId>sonar-maven-plugin</artifactId>
            <version>3.9.1.2184</version>
            <executions>
                <execution>
                    <!-- verify フェーズにバインド:ユニットテスト完了後、インストール・デプロイ前にスキャンを実行 -->
                    <phase>verify</phase>
                    <goals>
                        <goal>sonar-check</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

プラグインそのもの以外に、Scanner は結果の送信先も知る必要があります。サーバーのアドレス(sonar.host.url)と認証トークン(sonar.login または token)は、通常 Maven の settings.xml や CI の環境変数に設定します。pom.xml にハードコードしてリポジトリにコミットするのはおすすめしません。

mvn clean verify コマンドを実行すると、SonarQube は自動的にプロジェクトのソースコードを解析し、SonarQube サーバー上に対応するレポートを生成します。開発者は SonarQube サーバーの Web インターフェースにアクセスしてレポートを確認し、その情報をもとにコードを最適化できます。

DevOps における組み合わせ方​

単体でスキャンを回すのは出発点にすぎず、SonarQube が本当に価値を発揮するのはパイプラインの中です。実際の DevOps フローでは、SonarQube は通常 CI/CD ツールチェーンと連携して使われます。たとえば:

  1. 開発者がコードを Git リポジトリにコミットする
  2. CI システム(Jenkins など)がビルドタスクをトリガーする
  3. ビルド過程で SonarQube のコードスキャンを実行する
  4. Quality Gate に基づいてリリースを続行するかどうかを判断する
  5. スキャン結果を DingTalk / WeChat Work / メールでチームに通知する

ステップ 4 がこのチェーン全体の核心です。Quality Gate を通過しなければパイプラインを中断し、品質問題をマージやリリースの前で食い止めます。事後にレポートを見返すのではありません。プラットフォームの Pull Request 分析機能と組み合わせれば、問題をレビュー画面に直接アノテーションすることもでき、Code Review は設計レベルに集中し、機械的なチェックはツールに任せられます。

ハマりどころと注意点​

実際のデプロイと運用では、いくつかハマりやすいポイントがあります。

  1. サーバー側のリソース要件は低くない。SonarQube はインデックス用に Elasticsearch を内蔵しており、メモリに一定の要件があります。Linux にデプロイする場合、通常は vm.max_map_count などのカーネルパラメータを引き上げる必要があり、そうしないとサービスが起動しません。小規模チームならまず Docker で単一ノード運用してもよいですが、リソースがギリギリのマシンには置かないようにしましょう。
  2. カバレッジは SonarQube が計算しているのではない。SonarQube はカバレッジレポートを読み取るだけです(Java エコシステムでは JaCoCo が生成するものが一般的)。ビルドの中で先にレポートを生成していなければ、画面上のカバレッジはずっと 0 のままです。これは導入初期に最もよくある疑問です。
  3. ルールはチームの実情に合わせて調整する。デフォルトのルールセットはかなり網羅的で、そのまま全部有効にすると大量の警告が出て、チームはすぐに結果に「免疫」ができてしまいます。デフォルトの Quality Profile から始めて、明らかに適用外のルールを無効化し、すべての警告が対処に値する状態にすることをおすすめします。
  4. 古いプロジェクトは「新規コード」から手をつける。既存の問題を一気にゼロにしようとせず、Quality Gate の制約は新規コードにかけ、既存の負債は長期計画に組み込んで少しずつ返済していきましょう。
ヒント

スキャンをパイプラインのどこに置くかにもコツがあります。早すぎる(push のたびにフルスキャン)とフィードバックが遅くなり、遅すぎる(リリース前だけスキャン)と問題が積み上がって修正しづらくなります。よくあるやり方は、マージリクエスト時とメインブランチのビルド時にそれぞれ 1 回ずつスキャンすることです。

まとめ​

SonarQube が解決する核心的な問題は、コード品質を「人が見張る」から「プロセスで保証する」に変えることです。静的解析で Bug、脆弱性、コードスメルを見つけ、多角的な指標で保守性を定量化し、Quality Gate でこれらの基準を CI/CD に組み込み、基準未達なら通しません。導入コストは高くありません。Maven プラグイン 1 つとコマンド 1 行で動き始めます。難しいのはその後、ルールとしきい値をチームに合ったレベルに調整し、無視される赤い警告ではなく、本当に信頼されるゲートキーパーに育てていくことです。

COMMENTS