概要
前提
- SonarQubeを使ってPHPプロジェクトの解析をやっていこう
- 概念的な部分の整理を兼ねてこの資料を書いた
- 個人の見解を含みます
- 詳しい情報については最新のドキュメントを読んでください
構成概念
SonarQubeの静的解析は、以下2つの概念で構成されている。
- Rule
- Quality Profile
また、Ruleと密接に関連する概念として、Issueがある。RuleとIssueを理解すると、SonarQubeの画面の操作などの理解がスムーズになるので、本稿では前述2つの概念に加えて、Issueについても取り扱う。
要約
RuleとQualityProfileの関係について
- 「認知的複雑度が15以上のメソッド禁止」等、具体的なコード解析内容を定義したものがRuleである。
- Quality ProfileはこれらRuleを複数束ねた集合であるとともに、Ruleごとの設定値を管理するためにも利用される。
- 一例として、「認知的複雑度のしきい値を15から10に変更したい」という場合、しきい値「10」は、Quality Profileに紐づける形で管理される。
Issueについて
- コード解析は、Quality Profileで定義された内容に従って行われる。
- Quality Profileに紐付けられた各Ruleは、Ruleの条件に該当する場合にIssueを発行する。
- 開発チームは、発行されたIssueを1つのタスクとして解決することで、コード品質を改善することができる。
各概念の詳細
Quality Profile
Quality profiles are a key part of your SonarQube configuration. They define the set of rules to be applied during code analysis.
- デフォルト状態ではSonar wayというQualtyProfileが適用された状態となっているため、何かカスタマイズを行いたい場合は新たにQuality Profile を作成する必要がある。
- Quality Profileを作成する場合、複製と継承を選ぶことができる。
- とりあえずいじりながら様子を見たいのであれば継承の方が楽。
Rule
- Ruleは、SonarQubeにおけるコード解析設定の最も小さい単位である（たぶん）
- コード解析実行時、コードをRuleが検査し、結果に従ってIssueが作成される。
- Ruleにはいくつかの属性がある。主なものを以下に挙げる。
- Language: どの言語に適用されるルールか。
- Type: このルールが発行するIssueの種類。
- Default Severity: このルールが発行するIssueのデフォルトの重大度。
- SonarQubeの解析設定周りの概念は、オブジェクト指向的な設計になっている。
- 初期状態では、管理画面上の「Rules」から入っても、Ruleそのものを変更することはできない。
- プロジェクトごとにRule設定を微調整したい場合は、以下の手順を取る。
- 「Quality Profiles」の画面へ遷移する
- 各言語用に用意されているデフォルトのQuality Profile（Sonar way）を継承して、自分専用のQuality Profileを作成する
- Quality Profile作成後、「Rules」の画面から設定を調整したいRuleの画面へ遷移
- Ruleのパラメータ、スレッショルド、属性をプロジェクトに合わせて調整し、保存する。
※この例は「CustomPhp」というQualityProfileを作成してからRuleの詳細画面を表示したところ。CustomPhpの右に「Change」ボタンが表示されるので、ここを押すとルールの詳細を変更することができる。
- 独自にRuleを作成したい場合、プラグインを開発する必要がある。プラグインはJAVAで書く。（他にも方法があるようだが詳しく読んでない）
- Ruleを追加する方法について https://docs.sonarqube.org/latest/extension-guide/adding-coding-rules/
- PHPのソースコード解析について（PHP解析用のプラグインを開発する人向けドキュメント） https://docs.sonarqube.org/latest/analyzing-source-code/languages/php/
Issue
Issue Types
Issueの種類。4種類ある。
- Code smell (保守性)
- Bug (信頼性)
- Vulnerability (脆弱性)
- Security hotspot (脆弱性)
※ドキュメント上では3種類記載されている箇所と4種類記載されている箇所がある。管理画面上のレイアウトにおいてSecurity hotspotだけちょっと扱いが異なるようだが、概念としては4種類と考えて差し支えなさそう。
Issue severity
重大度。5段階存在する。
- BLOCKER: Bug with a high probability to impact the behavior of the application in production. For example, a memory leak, or an unclosed JDBC connection are BLOCKERs that must be fixed immediately.
- CRITICAL: Either a bug with a low probability to impact the behavior of the application in production or an issue that represents a security flaw. An empty catch block or SQL injection would be a CRITICAL issue. The code must be reviewed immediately.
- MAJOR: A quality flaw that can highly impact the developer's productivity. An uncovered piece of code, duplicated blocks, or unused parameters are examples of MAJOR issues.
- MINOR: A quality flaw that can slightly impact the developer's productivity. For example, lines should not be too long, and "switch" statements should have at least 3 cases, are both be considered MINOR issues.
- INFO: Neither a bug nor a quality flaw, just a finding.
最後に
- 開発担当としては、IssueとRuleについて読んでおけばSonarQubeの画面を見るのにそんなに困らないはず。
- 品質管理担当としては、この資料の内容だけだとやや不十分かも。（他に、QualityGateの概念と、ProjectSettingsでできることを把握しておく必要があるが本稿では割愛）