SonarQubeとCircleCIで技術的負債を駆逐せよ！

これは[DMM.com #2 Advent Calendar 2017](https://qiita.com/advent-calendar/2017/dmm2)の24日目の記事です。
昨日は@Ecouffesさんの[超マイナーなCSSヲタク知識を晒してみる：CSS displayプロパティ値の自動変換](https://qiita.com/Ecouffes/items/a4eb810bb89955c4e7c2)でした。

弊社のアドベントカレンダーのURLはこちら
[DMM.com #1 Advent Calendar 2017](https://qiita.com/advent-calendar/2017/dmm)
[DMM.com #2 Advent Calendar 2017](https://qiita.com/advent-calendar/2017/dmm2)

# 追記: v7.2から無料でPR解析ができなくなったらしい
[Release notes](https://docs.sonarqube.org/latest/setup/upgrade-notes/)によると、Developer、Enterprise、Data Center Editionでしか使えなくなったらしいです。大変つらい。
まだどうするか考え中です・・・。


# まえがき
どーも、@tinojiです。DMM.comラボの動画配信なチームでピチピチ新卒エンジニア(26)をやっとります。配属から5ヶ月ぐらい経ったような気がします。業務では色々やらせてもらってますが、DevOps・開発効率化な基盤をつくる、みたいなことをわりとメインでやっています。

その中で、SonarQubeというツールを使うためにサーバ構築したりドキュメントをしこしこ書いたりしました。実際に運用し始められるかな〜程度の知見が貯まってきたような気がするので、その辺のことを書きたいと思います。昔からある格式高きツールなので今更感は否めませんがご容赦を。


## SonarQube is 何
SonarQubeとは簡単に言うと静的コード解析ツール、そしてそれをいい感じに閲覧するWebビューアーです。ひと目でコードの品質(Bug, Code smell, Vulnerability, Coverage, Duplication, Technical Deptなどなど)が分かり、あれ？弊社のコード臭すぎ？と気づくことができます。
[公式](https://www.sonarqube.org)いわく、
> Continuous Code Quality

今流行りのContinuous兄弟のひとりですかね。Continuous弟のCircleCIとタッグを組むことでとってもContinuousになります。SonarQubeのUIを見てみると大体何ができそうかわかると思います。

<img width="1000" alt="スクリーンショット 2017-12-23 12.59.20.png" src="https://qiita-image-store.s3.amazonaws.com/0/130232/af57830a-92dc-cde5-d76f-783cc08c0290.png">


<img width="1000" alt="スクリーンショット 2017-12-23 13.02.14.png" src="https://qiita-image-store.s3.amazonaws.com/0/130232/7d7027c6-f898-f1b1-1cd4-16c8dd9d27de.png">



こんな感じで、コードの品質に関するいろいろなメトリクスを閲覧することができます。また問題のあるコードはインラインで指摘してくれます。

<img width="1076" alt="スクリーンショット 2017-12-23 13.10.54.png" src="https://qiita-image-store.s3.amazonaws.com/0/130232/d3501dc5-eb70-859a-cd31-1fe48e4be877.png">

この機能は、プラグインでGithubと連携することによりなんと**自動コードレビュー**ができます。すごい。WebUIによるメトリクス・issues閲覧と自動コードレビュー。この2つがメインの機能になるかと思います。

![pr_demo.png](https://qiita-image-store.s3.amazonaws.com/0/130232/65c17712-166a-c5c9-66a4-79c227050d26.png)


## このクソ長い記事を読むと何が分かるってんだ
- SonarQubeとCircleCIを連携させることが出来るようになるぜ
- コードの品質を視覚的に捉えることが出来るようになるぜ
- 自動コードレビューが出来るようになるぜ。レビューアーがちょっと楽できるぜ
- C#で使うときはちょっと特殊だ。それもフォローするぜ
- IDEで使いたいって？あぁ任せとけ
- SonarQube自体の細かい機能や使い方はあまり分からないぜ


## 目指す構成
![スクリーンショット 2017-12-23 16.03.33.png](https://qiita-image-store.s3.amazonaws.com/0/130232/6c65a89d-38c7-fbcf-9c36-de8431838b15.png)

master/stagingブランチが更新されたときの解析結果はSonarQubeサーバーに保存されます。それ以外のブランチの解析結果はサーバーには保存されず、プルリク時に自動コードレビューが行われます。

動作確認環境は以下。

- SonarQube 6.7 (on CentOS 7)
- CircleCI Enterprise 2.0
- Github Enterprise 2.10


# インストール
私はインストール版を使用しましたが、クラウド版の[SonarCloud](https://about.sonarcloud.io)もあります。インストールはそこまで大変ではありませんが、クラウド版だとサクッと試せるのでまずそれで使ってみるのもいいかもしれません。インストール版にも[いくつかエディションがあります](https://docs.sonarqube.org/display/PLUG/SonarSource+Editions)。私は今のところ無料のCommunity Editionを使っています。無料版だと使えないプラグインがあったりします。例えば今のところSwiftを解析するためのプラグインが使えません、、、5.6では使えたのですが、、、

また、[dockerイメージ](https://hub.docker.com/_/sonarqube/)もあります。ラクそうです。

インストールは基本的には[公式通り](https://docs.sonarqube.org/display/SONAR/Installing+the+Server)でおkです。DBはMySQL5.7にしました。私は最初SonarQube5.6をインストールしたのですが、そのときはDBのインストールが必須でした。今はH2DBがビルトインで使えて動作確認程度ならそれでいけるようです。

## サービス化
サービス化の方法は[公式だとinitd](https://docs.sonarqube.org/display/SONAR/Running+SonarQube+as+a+Service+on+Linux)の場合しか記載がないので、systemdの場合は適当に書き換える必要があります。以下のようなファイルを`/etc/system/systemd/`に配置すればおkです。

```sonar.service
[Unit]
Description=SonarQube service
After=syslog.target network.target

[Service]
Type=forking

ExecStart=/usr/local/sonarqube/sonar/bin/linux-x86-64/sonar.sh start
ExecStop=/usr/local/sonarqube/sonar/bin/linux-x86-64/sonar.sh stop

User=sonarqube
Group=sonarqube
Restart=always

[Install]
WantedBy=multi-user.target
```

ちなみに`/usr/local/sonarqube/sonar`は`/usr/local/sonarqube/sonarqube-6.7`にシンボリックリンクしてあります。アップグレードするとき便利なので。

## 実行ユーザーに注意
Elasticsearchが使われている関係でサービスの実行ユーザーは[rootでは動きません](docs.sonarqube.org/display/SONAR/Release+6.6+Upgrade+Notes)。`sonar`や`sonarqube`のようなユーザーとグループを作成し、インストールディレクトリの所有者にし、↑の`sonar.sevice`でも`User`と`Group`をそれに合わせます。SonarQube5.6をインストールしたときはrootで動かしていたのでアップグレードの際にハマりました、、、


## プラグインのインストール
adminユーザーでログインして、`Administration > Marketplace`から以下のプラグインをインストールします。

- Github
- Github Authentication for SonarQube

その他、使用したい言語のプラグインを入れておきましょう。

## HTTPS化
私は[リバースプロキシ](https://docs.sonarqube.org/display/SONARQUBE52/Running+SonarQube+behind+a+Proxy)でHTTPS化しました。オレオレ証明書では動かなかったので注意です。


# アカウント等の準備
## 各種アカウントとアクセストークンの用意
- CircleCIのアカウント
    - Githubと連携させておきます。
    - 弊社の場合、Organizationに対応したアカウントを1つ作成してbot用として使うことになっています。
- SonarQubeのアカウント
    - adminでログインしてアカウントを作成します。ひとまずそのままadminを使ってもおkです。
- Githubアクセストークン
    - `ユーザーアイコン > Settings > Personal access token`から発行します。パーミッションは`repo`だけでおkです。
- SonarQubeアクセストークン
    - `ユーザーアイコン > My account > Security`から発行します。

注)SonarQubeアクセストークンは理想的には、各コミッターがそれぞれ使い分けるべきかもしれませんが、面倒なのでリポジトリの作成者などで統一しておけばいいかなーと思ってます。


## GithubのCollaboratorsにCircleCIアカウントを追加
リポジトリのSettingsからCollaboratorsにCircleCIアカウントが入ったチームをjoinさせ、Admin権限を与えます。

<img width="700" alt="スクリーンショット 2017-12-23 13.59.08.png" src="https://qiita-image-store.s3.amazonaws.com/0/130232/e8feaf54-f6b6-d2d0-0eac-1360e5977a51.png">



## CircleCIに環境変数を設定
アクセストークンをハードコーディングしないようにするため、環境変数に設定します。以下2つに取得したアクセストークンをコピペして下さい。`歯車マーク > Environmental variables`からできます。

- GITHUB_TOKEN
- SONAR_TOKEN

<img width="1000" alt="access_token.png" src="https://qiita-image-store.s3.amazonaws.com/0/130232/ed002b54-db85-ad51-b48a-b9c7430e25e4.png">



## CCIのビルドトリガー
CCIでは何をトリガーにしてビルドするかを設定することができます。`Settings` > `Advanced Settings`らへんです。主に以下の2つの方法がありますが、SonarQubeを使うに当たってはどちらも一長一短あるので、少し運用でカバーする必要があります。
※このへんぶっちゃけ検証不足です。もっといい方法があるに違いない、、、



### PRにだけビルド
- `Only build pull requests`をON
- PRが作成されたとき及びそのPR中のブランチのコミットがトリガー
- SonarQubeのGithub Pluginを使用している場合、PRを作成したときに自動コメントがつくのでgood
- マージされたときにはビルドされないので、SonarQubeサーバーにmasterブランチの解析結果を反映したいときは、CCIから手動でビルドを実行する必要がある
  - つらい
  - `NOT RUN`になっているのでRebuildをポチる



### すべてのコミットに対してビルド
- `Only build pull requests`をOFF
- すべてのコミットに対して発火
  - `circle.yml`でブランチを制限したりはできる
  - [コミットメッセージで無視させることもできる](http://circleci.com/docs/1.0/skip-a-build/)
- PRを作成したタイミングでは発火しないので、自動コメントつけてほしいときはCCIから手動でビルドする必要あり
  - つらい
  - 該当ブランチの直前のビルドをRebuildすればよい



# 設定ファイルとシェルスクリプトを書く
次に、リポジトリに置くファイルを用意します。

## ディレクトリ構成
`src`以下に解析したいコードが入る想定です。解析対象にするディレクトリは次で説明する`sonar-project.properties`で設定できます。

```
.
├── .circleci
│   ├── analyze-sonarqube.sh
│   └── config.yml
├── sonar-project.properties
└── src
     └── ...

```


## sonar-project.properties
SonarQubeを実行するときは[sonr-scanner](https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner)というコマンドをインストールして実行します。sonar-scannerは実行したディレクトリに`sonar-project.properties`があるとその設定を読み込みます(詳しくは後述)。


```sonar-project.properties
##################################################################
# Properties file for sonar-scanner
# See https://docs.sonarqube.org/display/SONAR/Analysis+Parameters
##################################################################

# Server
sonar.host.url=http://your.host.name

# Project identification (LOCAL ANALYSIS ONLY)
#sonar.projectName=test-repo
#sonar.projectKey=com.dmm:test-repo:feature/hoge
#sonar.projectVersion=1.0

# Comma-separated paths to directories with sources (required)
sonar.sources=src
#sonar.exclusions=

# Language (If not set, a multi-language analysis will be triggered)
sonar.language=

# Default source code encoding
sonar.sourceEncoding=UTF-8
```

## .circleci/config.yml
次で説明する`analyze-sonarqube.sh`を実行するだけです。`image`は適当なものを。

```config.yml
version: 2
jobs:
  code_analyze:
    docker:
      - image: circleci/openjdk:8
    steps:
      - checkout
      - run:
          name: analyze by SonarQube
          command: bash ./.circleci/analyze-sonarqube.sh

workflows:
  version: 2
  test:
    jobs:
      - code_analyze
```




## .circleci/analyze-sonarqube.sh
`sonar-scanner`をコンテナにインストールして実行する感じです。[こちら](https://github.com/Sagacify/ci-tools)を参考に、より単純にしました。

```analyze-sonarqube.sh
#!/bin/bash
#################################################
# based on https://github.com/Sagacify/ci-tools
#################################################

SONAR_VERSION="sonar-scanner-cli-3.0.3.778"
SONAR_DIR="sonar-scanner-3.0.3.778"

wget -P $HOME -N "https://sonarsource.bintray.com/Distribution/sonar-scanner-cli/${SONAR_VERSION}.zip"
unzip -d $HOME $HOME/$SONAR_VERSION.zip

DEFAULT_SONAR_PARAMS="-Dsonar.login=$SONAR_TOKEN \
                      -Dsonar.projectName=$CIRCLE_PROJECT_REPONAME \
                      -Dsonar.projectVersion=$CIRCLE_BUILD_NUM"

if [ -n "$CI_PULL_REQUEST" ]; then
  if [ "$CIRCLE_BRANCH" != "staging" ] & [ "$STAGING_EXISTS" ]; then
    SONAR_PROJECT_KEY=$CIRCLE_PROJECT_USERNAME:$CIRCLE_PROJECT_REPONAME:staging
  else
    SONAR_PROJECT_KEY=$CIRCLE_PROJECT_USERNAME:$CIRCLE_PROJECT_REPONAME
  fi

  echo "Preview analyzing ${CI_PULL_REQUEST} by SonarQube Github Plugin"
  $HOME/$SONAR_DIR/bin/sonar-scanner $DEFAULT_SONAR_PARAMS \
    -Dsonar.projectKey=$SONAR_PROJECT_KEY \
    -Dsonar.github.repository=$CIRCLE_PROJECT_USERNAME/$CIRCLE_PROJECT_REPONAME \
    -Dsonar.github.pullRequest=${CI_PULL_REQUEST##*/} \
    -Dsonar.github.oauth=$GITHUB_TOKEN \
    -Dsonar.github.endpoint="https://git.your.domain/api/v3" \
    -Dsonar.analysis.mode=preview;
fi

if [ "$CIRCLE_BRANCH" == "master" ]; then
    echo "Analyzing ${CIRCLE_BRANCH} branch to push issues to SonarQube server"
    $HOME/$SONAR_DIR/bin/sonar-scanner $DEFAULT_SONAR_PARAMS \
    -Dsonar.projectKey=$CIRCLE_PROJECT_USERNAME:$CIRCLE_PROJECT_REPONAME;
elif [ "$CIRCLE_BRANCH" == "staging" ]; then
    echo "Analyzing ${CIRCLE_BRANCH} branch to push issues to SonarQube server"
    $HOME/$SONAR_DIR/bin/sonar-scanner $DEFAULT_SONAR_PARAMS \
    -Dsonar.projectKey=$CIRCLE_PROJECT_USERNAME:$CIRCLE_PROJECT_REPONAME:staging;
fi
```

- masterブランチ
  - masterにpushされたときはサーバへ反映。
- stagingブランチ
  - stagingにpushされたときもサーバへ反映。
  - `projectKey`には`:staging`が付与されるので、プロジェクト名はmasterと同じだがWebUIでは異なるメトリクスが閲覧できる。
- それ以外のブランチ
  - pushしても解析は走らない。
  - PRの場合のみGithub Pluginが実行され、PRにコメントがつく。


![image.png](https://qiita-image-store.s3.amazonaws.com/0/130232/8565627d-3dfa-9793-90ac-a67e06a92bfe.png)
↑同じ名前のプロジェクトが2つ出来ていますが、片方はprojectKeyに:stagingが付与されています。この辺は運用フローによって適宜変える感じになるかと思います。


# 実行
あとはpushするなりPR出すなりすれば動くはずです。


## master/staging以外のブランチでもサーバに反映する方法
作業中のブランチのコード量が多いのでPRを出す前にも解析したい、ということもあるかもしれません。ローカルにsonar-scannerをインストールすれば、ローカルから任意のタイミングでサーバに反映することができます。

`sonar-project.properties`でコメントアウトしてあるプロジェクト名などをコメントインし、それぞれ入力してください。`projectName`は同一でも`projectKey`が異なれば違うプロジェクトと認識されるので、master/stagingとは違う`projectKey`を入力すればおkです。

例えば`sonar-project.properties`を以下のように編集して、

```
# Project identification (LOCAL ANALYSIS ONLY)
sonar.projectName=test-repo
sonar.projectKey=com.dmm:test-repo:feature/hoge
sonar.projectVersion=1.0
```

ローカルにインストールした`sonar-scanner`をプロジェクトのルートディレクトリで実行します。このとき、SonarQubeのアクセストークンはオプションで渡してやる必要があります。

```
$ sonar-scanner -Dsonar.login=[your token]
```

PRがマージされたタイミングで該当ブランチのプロジェクトは使用しなくなると思うので削除推奨です。


## Issueの解決
SonarQubeによってレポートされたissue(`Bug`, `Code Smell`, `Vulnerability`)はissue viewerによって閲覧することができ、担当者をアサインしたりタグを付けたり、まぁなんか色々できます。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/130232/409ddfd2-1dfb-6170-e88c-d17677de31ab.png)


例えばこのissueはコーディング規約に反していないから無視する、とかだったらステータスを`Resoleved as won't fix`にする〜みたいな感じですかね？まぁこの辺はGithubとの使い分けが難しいのであれですが、、、

自動コードレビューされた点についてはそのPR中にできるだけ直し、直さなくていいものはSonarQubeから適宜ステータスを変更する、とかですかね、、、？

詳しい使い方は[ドキュメント](https://docs.sonarqube.org/display/SONAR/Issues)を参照のこと。


ここから下は補足的な感じです。

# SonarQubeのプロパティについて
sonar-scannerは、実行したディレクトリのルートにある[sonar-project.properties](https://git.dmm.com/dig-cdp/sonarqube-circleci-integration/blob/master/sonar-project.properties)というファイルからプロパティを読み込みます。
また、sonar-scannerのオプションで`-Dsonar.hoge=foo`のようにプロパティを指定することもできます。つまり、`sonar-project.properties`に

```
sonar.host.url=http:sonar.host:9000
```

と書いて実行するのと

```
$ sonar-scanner -Dsonar.host.url=http:sonar.host:9000
```

とオプションをつけて実行するのは同じ意味になります。

各パラメータの説明はこちらを見ればおk。
https://docs.sonarqube.org/display/SONAR/Analysis+Parameters

基本的な項目は以下のとおり。

| プロパティ                  | 説明 |
|:-----------              |:------------|
| sonar.host.url           | SonarQubeサーバのURL |
| sonar.projectName        | SonarQubeのUIに表示されるプロジェクト名 |
| sonar.projectKey         | SonarQubeにおけるプロジェクトの識別子。 `projectName`が同一でもこれが異なれば違うプロジェクトと判断される|
| sonar.projectVersion     | プロジェクトのバージョン |
| sonar.sources            | 解析を行いたいソースのファイルorディレクトリを指定(カンマ区切り) |
| sonar.exclusions         | `sources`から省きたいファイルorディレクトリを指定 |
| sonar.language           | 解析したい言語。指定しないと`multi-language analysis`になるのでそれでおk |
| sonar.sourceEncoding     | UTF-8でいいと思いますが、[ver6.4から勝手にやってくれるようです](https://docs.sonarqube.org/display/SONAR/Release+6.4+Upgrade+Notes)|
| sonar.login              | SonarQubeのアクセストークン |

<br>

Github Pluginで使用するプロパティ。これらをセットすると勝手にプラグインが走るという仕様ぽいです。

| プロパティ                  | 説明 |
|:-----------              |:------------|
| sonar.github.repository  | リポジトリ。`organization/repository` |
| sonar.github.pullRequest | PR名 |
| sonar.github.oauth       | Githubのアクセストークン |
| sonar.github.endpoint    | Github APIエンドポイント。[Enterpriseではgithub.comの場合とは違う](https://developer.github.com/v3/enterprise/)ので注意 |
| sonar.analysis.mode      | `preview`にするとサーバにpushされない([ver6.6.から非推奨](https://docs.sonarqube.org/display/PLUG/GitHub+Plugin))。 |



# Maven&Gradleのプラグイン
JavaなプロジェクトでMavenやGradleを使用している場合は、それらのSonarQubeパッケージを使うことができます。Antもあるぽいです。

- Maven
  - https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Maven
- Gradle
  - https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Gradle

例えばGradleの設定はこんな感じ。  
https://github.com/SonarSource/sonar-scanner-gradle

gradleスクリプトを書きたい、とかでもない限りsonar-scannerに比べてとくに有用性はないですし、バージョンが結構ややこしいので使う必要はないような気がします、、、ぶっちゃけよくわかりません。


# VSTSを利用してC#を解析する
(※注意:自分がC#の解析をやっていたときはCircleCIが1.0だったため、Ubuntuコンテナでのビルドが前提でした。~~CircleCI2.0ではdockerを利用してWindowsコンテナが使用できると思いますので、それでサクッとできる気がします。~~以下はCircleCI1.0を前提にした説明となっています。あしからず、、、)

C#の場合、解析の際にMSBuildでビルドすることが必須になるので他の言語とは少し異なる手順になります。
https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+MSBuild

基本的にはWindows環境が必要(exeファイルを実行する必要がある)なので、CircleCIのUbuntuコンテナでビルドすることは多分困難です。ということでC#のCI環境はVSTS(Visual Studio Team Services)で構築してみました。SonarQube公式のプラグインがあります。また、VSTSでバージョン管理も出来るのですがGHEを使いたかったのでそこらへんもゴニョってみました。


## アカウント作成
まずVSTSのアカウントを作成。
https://www.visualstudio.com/ja/team-services/?rr=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fvsts%2F

Visual Studio Pro with MSDNのアカウントを持っていれば基本的には無料で無制限に利用可能だったと思います。そうでなくても、現在1チーム5人まで無料で使用可能です。


## プラグインのインストール
SonarQubeを利用するにはプラグインが必要なので、マーケットプレイスからインストールします。

<img width="1265" alt="スクリーンショット 2017-12-23 14.15.38.png" src="https://qiita-image-store.s3.amazonaws.com/0/130232/d6baa0d7-4226-67af-c37f-3b2804bcbeaf.png">


## Build definitionを作成
あらかじめ適当なprojectも作成してください。その後Build definitionを作成。Hosted(クラウドな)agentを使用しています。


### get sourceの設定
Github Enterpriseを使用するので、普通のGithubモジュールは使用できません([そのうちGHEに対応するかもしれません](https://github.com/Microsoft/vsts-agent/issues/1281))。`External Git`を選択して、認証情報を入力してください。

![スクリーンショット 2017-12-23 14.23.33.png](https://qiita-image-store.s3.amazonaws.com/0/130232/f584a54d-36de-2aa8-dc6d-e56b89b166ff.png)

バージョン管理もVSTSにするとこの辺はラクになるかと思います。


### gitでプロキシを設定
※この手順はオンプレ(VTF)なagentを使用する場合には不要です。
弊社のGithub Enterpriseは社内ネットワークからしかアクセスできないので、リポジトリをcloneするために、プロキシを経由する必要がありました。

CIコンテナのgit configでプロキシの設定を行おうと思ったのですが、Get sourceのタスクの前にbuild taskを入れることはデフォルトでは不可能(謎仕様)なので、build taskを自分で作る必要がありました。てきとーにつくりました。
https://github.com/tinoji/vsts-task-gitProxy

![image.png](https://qiita-image-store.s3.amazonaws.com/0/130232/0ce43bc6-07cd-7e1c-3b0a-c1b0e7f0e9a9.png)
※設定時、アカウント名に含まれる記号は適宜エスケープする必要があります。


### SonarQubeの設定
以下を参照のこと。
https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Extension+for+VSTS-TFS


## 実行
Save&queueをすると実行されます。SonarQubeのUIに該当のリポジトリが出現したら成功です。Build definitionの`trigger`タブから設定すると、どのブランチのpushで発火させるかなどが設定できます。


# IDEでSonarQubeを使う
## SonarLint
IntelliJやVSCode、AtomなどのIDEでは[SonarLint](https://www.sonarlint.org)というLintプラグインが使えます。ただし、言語のサポートが少なかったりします。たとえばAndroidStudioでは2017/12時点でKotlinに対応していません。
が、非公式のプラグインではできたりします。例えばSonarQube Community Plugin というのが使えます。その例を紹介しておきます。

## SonarQube Community Plugin@AndroidStudio
### Pluginのインストール
`preferences > plugins`から検索して、SonarQube Community Pluginをインストール。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/130232/7056bbac-07fb-49a7-cfdb-97223e464b3d.png)

### サーバの設定
`preferences > other settings > SonarQube`でまずサーバを登録。ユーザーはanonymousだと動かないので、各々のユーザー情報を入力。

次に`SonarQube resources`で`+`ボタンをクリック。`Download resources`をクリックすると、SonarQubeサーバにアップされているプロジェクト一覧が出るので該当のプロジェクトを選択。

ここまでの設定で、サーバにあるプロジェクトのissuesが取得できます。


### ローカルで実行するための設定
ローカルでpreviewモードで実行しレポートを出力することにより、サーバに上がっている情報との差分をとってくれます。ローカルで実行するのは以下のどれでもおkです。

- sonar-scanner(予めローカルにインストールする必要あり)
  - https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner
- mavenのパッケージ
- gradleのパッケージ

まぁsonar-scannarでいいと思います。
`設定画面 > Local analysis script > Add`で実行スクリプトを書きます。sonar-scannerにはパスが通っていてもフルパスで書く必要があります。`sonar.report.export.path`は.scannerworkディレクトリをルートとするので注意です。

![android_local_config.png](https://qiita-image-store.s3.amazonaws.com/0/130232/355d0716-425a-a4dc-e81d-343ecc14959b.png)


### 実行
`Analyze > Inspect code`で、他の解析と一緒に実行されます。ちゃんとローカルで実行されていれば、new issueというセクションが出現します。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/130232/4a4bfa2b-7976-6b4a-a2da-88f680d58c05.png)

イベントログにも吐かれます。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/130232/b441b9d9-71ae-191f-6a2f-45cf191a15c5.png)


# 参考リンク
- [SonarQube と CircleCI を使って Github でのコードレビューを自動化する](https://qiita.com/yo1000/items/d968031ff0411516940a)
    - CircleCIとの連携とかはこちらを参考にしました。
- [SonarQubeでプログラムの品質管理をはじめる（概要）](https://qiita.com/sh-ogawa/items/fac0eca110c3558dfae9)
- [SonarQubeでソースコードの品質チェック](https://qiita.com/teradonburi/items/776e4735395af872320a)
- [SonarQubeで始める静的コード解析](http://blog.applibot.co.jp/blog/2017/09/14/static-code-analysis-with-sonarqube/)
    - dockerでSonarQubeを立てる&CIにJenkinsを使用する&Gitlabを使う。


# まとめ
SonarQubeたそ、使い始めるまでがわりと面倒でしたが、これからいい仕事をしてくれるんじゃないかと期待しています。実際に使っていくうちにまた何か知見があればどこかに書こうと思っています。

以上です〜。明日のアドベントカレンダーは@huatoさんです！

<br>