SonarQubeを使ったコード解析

SonarQubeを使用したコード分析

1. 概要

この記事では、コードの品質を確保するためのオープンソースプラットフォームであるSonarQubeを使用した静的ソースコード分析について説明します。

コアな質問から始めましょう–そもそもなぜソースコードを分析するのですか? 非常に簡単に言えば、プロジェクトの寿命にわたって品質、信頼性、および保守性を確保するためです。不完全に記述されたコードベースは、常に維持費が高くなります。

では、download pageからSonarQubeの最新のLTSバージョンをダウンロードし、このquick start guideで概説されているようにローカルサーバーをセットアップすることから始めましょう。

2. ソースコードの分析

Now that we’re logged in, we’re required to create a token by specifying a name – which can be our username or any other name of choice and click on the generate button

後でプロジェクトを分析する時点でトークンを使用します。 また、プライマリ言語(Java)とプロジェクトのビルドテクノロジ(Maven)を選択する必要があります。

pom.xmlでプラグインを定義しましょう:


    
        
            
                org.sonarsource.scanner.maven
                sonar-maven-plugin
                3.4.0.905
            
        
    

プラグインの最新バージョンはhereで利用できます。 次に、プロジェクトディレクトリのルートからこのコマンドを実行してスキャンする必要があります。

mvn sonar:sonar -Dsonar.host.url=http://localhost:9000
  -Dsonar.login=the-generated-token

the-generated-tokenを上記のトークンに置き換える必要があります。

この記事で使用したプロジェクトは、hereで利用できます。

SonarQubeサーバーのホストURLとログイン(生成されたトークン)をMavenプラグインのパラメーターとして指定しました。

コマンドを実行すると、結果はプロジェクトダッシュボードのhttp://localhost:9000に表示されます。

Mavenプラグインに渡すことができる、またはWebインターフェースから設定することもできる他のパラメーターがあります。 sonar.host.url、sonar.projectKey、およびsonar.sourcesは必須ですが、その他はオプションです。

その他の分析パラメータとそのデフォルト値はhereです。 また、各言語プラグインには、互換性のあるソースコードを分析するためのルールがあります。

3. 分析結果

最初のプロジェクトを分析したので、http://localhost:9000のWebインターフェイスに移動して、ページを更新できます。

レポートの概要が表示されます。

image

発見された問題は、バグ、脆弱性、コード臭、カバレッジ、または複製のいずれかです。 各カテゴリには、対応する問題の数または割合の値があります。

さらに、問題には5つの異なる重大度レベルのいずれかがあります。blocker, critical, major, minorinfo.プロジェクト名のすぐ前に、品質ゲートのステータス(合格(緑)または不合格(赤))を示すアイコンがあります。

プロジェクト名をクリックすると、専用のダッシュボードが表示され、プロジェクト固有の問題を詳細に調べることができます。

プロジェクトダッシュボードからプロジェクトコード、アクティビティを確認し、管理タスクを実行できます。それぞれが個別のタブで利用できます。

グローバルなIssuesタブがありますが、プロジェクトダッシュボードのIssuesタブには、関連するプロジェクトのみに固有の問題が表示されます。

image

[問題]タブには、カテゴリ、重大度レベル、タグ、および問題を修正するために必要な計算時間(時間に関する)が常に表示されます。

[問題]タブから、問題を別のユーザーに割り当てたり、コメントしたり、重大度レベルを変更したりできます。 問題自体をクリックすると、問題の詳細が表示されます。

課題タブには、左側に洗練されたフィルターがあります。 これらは問題を特定するのに適しています。 では、コードベースが実稼働環境に展開するのに十分なほど健全であるかどうかをどのようにして知ることができますか? それがQualityGateの目的です。

4. SonarQubeクオリティゲート

このセクションでは、SonarQubeの重要な機能であるQualityGateについて説明します。 次に、カスタムを設定する方法の例を示します。

4.1. クオリティゲートとは何ですか?

品質ゲートとは、本番リリースの対象となる前にプロジェクトが満たさなければならない一連の条件です。 It answers one question: can I push my code to production in its current state or not?

既存のコードを修正しながら「新しい」コードのコード品質を保証することは、長期にわたって適切なコードベースを維持するための1つの良い方法です。 The Quality Gate facilitates setting up rules for validating every new code added to the codebase on subsequent [.hardreadability]#analysis#。

Quality Gateで設定された条件は、変更されていないコードセグメントに引き続き影響します。 新しい問題の発生を防ぐことができれば、時間の経過とともに、すべての問題がeliminateになります。

このアプローチは、ソースからのfixing the water leakageに相当します。 This brings us to a particular term – Leakage Period. This is the period between two analyses/versions of the project

同じプロジェクトで分析を再実行すると、プロジェクトダッシュボードの概要タブにリーク期間の結果が表示されます。

image

Webインターフェースの[品質ゲート]タブでは、定義されているすべての品質ゲートにアクセスできます。 デフォルトでは、SonarQube wayはサーバーにプリインストールされています。

SonarQube wayのデフォルト構成は、次の場合にコードに失敗のフラグを立てます。

  • 新しいコードのカバレッジは80%未満です

  • 新しいコードで重複する行の割合が3より大きい

  • 保守性、信頼性、またはセキュリティ評価がAより悪い

この理解により、カスタムクオリティゲートを作成できます。

4.2. カスタム品質ゲートの追加

まず、ページの左側にあるclick on the Quality Gates tab and then click on the Create buttonを実行する必要があります。 名前を付ける必要があります–example

これで、必要な条件を設定できます。

image

From the Add Condition drop-down, let’s choose*Blocker Issues*;は、条件のリストにすぐに表示されます。

Operator,Error列にゼロ(0)を設定するように、is greater thanを指定し、Over Leak Period列を確認します。

image

Then we’ll click on the Add button to effect the changes。 上記と同じ手順に従って、別の条件を追加しましょう。

Add Conditionドロップダウン_ and check _Over Leak Period列からissuesを選択します。

Operator列の値は「is less than”」に設定され、Error列の値として1を追加します。 これはif the number of issues in the new code added is less than 1, mark the Quality Gate as failedを意味します。

これは技術的に意味がないことは知っていますが、学習のために使用しましょう。 ルールを保存するには、Addボタンをクリックすることを忘れないでください。

最後のステップとして、プロジェクトをカスタムQualityGateにアタッチする必要があります。 これを行うには、ページを下にスクロールして[プロジェクト]セクションに移動します。

そこで、「すべて」をクリックしてから、選択したプロジェクトをマークする必要があります。 ページの右上隅からデフォルトの品質ゲートとして設定することもできます。

以前にMavenコマンドで行ったように、プロジェクトのソースコードを再度スキャンします。 それが完了したら、[プロジェクト]タブに移動して更新します。

今回は、プロジェクトはQuality Gate基準を満たさず、失敗します。 Why? ルールの1つでそれを指定しているため、新しい問題がなければ失敗するはずです。

[品質ゲート]タブに戻り、issuesの条件をis greater thanに変更しましょう。 この変更を有効にするには、更新ボタンをクリックする必要があります。

今回はソースコードの新しいスキャンが行われます。

5. SonarQubeをCIに統合する

SonarQubeを継続的インテグレーションプロセスの一部にすることは可能です。 コード分​​析がQuality Gateの条件を満たさなかった場合、これは自動的にビルドに失敗します。

これを実現するために、SonaQubeサーバーのクラウドホストバージョンであるSonarCloudを使用します。 アカウントhereを作成できます。

[マイアカウント]> [組織]から、組織キーを確認できます。通常、xxxx-githubまたはxxxx-bitbucketの形式になります。

また、My Account > Securityから、サーバーのローカルインスタンスで行ったようにトークンを生成できます。 後で使用するために、トークンと組織キーの両方に注意してください。

この記事では、Travis CIを使用し、既存のGithubプロファイルを使用してアカウントhereを作成します。 すべてのプロジェクトがロードされ、スイッチをオンにしてTravis CIを有効化できます。

SonarCloudで生成したトークンをTravis環境変数に追加する必要があります。 これを行うには、CI用にアクティブ化したプロジェクトをクリックします。

次に、[その他のオプション]> [設定]をクリックし、[環境変数]まで下にスクロールします。

image

SONAR_TOKENという名前の新しいエントリを追加し、SonarCloudで生成されたトークンを値として使用します。 Travis CIは暗号化して公開ビューから隠します:

image

最後に、次の内容の.travis.ymlファイルをプロジェクトのルートに追加する必要があります。

language: java
sudo: false
install: true
addons:
  sonarcloud:
    organization: "your_organization_key"
    token:
      secure: "$SONAR_TOKEN"
jdk:
  - oraclejdk8
script:
  - mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent package sonar:sonar
cache:
  directories:
    - '$HOME/.m2/repository'
    - '$HOME/.sonar/cache'

組織キーを上記の組織キーに置き換えてください。 新しいコードをコミットしてGithubリポジトリにプッシュすると、Travis CIビルドがトリガーされ、ソナースキャンも有効になります。

6. 結論

このチュートリアルでは、SonarQubeサーバーをローカルにセットアップする方法と、QualityGateを使用してプロジェクトの本番リリースへの適合性の基準を定義する方法について説明しました。

SonarQubedocumentationには、プラットフォームの他の側面に関する詳細情報があります。