こんにちは。キャスレーコンサルティング LS(リーディング・サービス)部の佐藤です。

今回は、CI/CD環境構築シリーズの2回目として、静的解析ツールSonarQubeの導入を行ってみます。

アジャイル開発などをしていると、どうしてもコードレビューが都度発生します。
やることは山積み、レビュー対象も山積み、問題点も山積み、となると些かげんなりします。

そこで出てくるのが、CI/CDです。
省ける手間は極力省き、その分のリソースをより重点的に取り組むべきところに回しましょう。

今回紹介させていただくSonarQubeを使用すると、明らかに間違った構文や冗長な箇所など、
誰が見ても指摘できるようなことを、自動でチェックしてくれるようになります。

当然、業務的な問題点をチェックしてくれたりはしませんが、
レビュー開始時点で一定の品質を担保してくれるようになるだけでも、
とてもありがたいことではないでしょうか。

導入の構成

今回、SonarQubeを導入するにあたり、以下のような構成にします。

SonarQubeは、サーバー起動する必要があるので、Apacheが必要になります。
また、ソースコードの解析結果をDB保存しますので、何かしらDBが必要になります。

今回は、MySQLになります。

導入手順は、こちらです。

  1. GCP上に、SonarQubeサーバーを立てる
  2. ローカル環境に、SonarQube scannerを用意する
  3. スキャンした結果を、確認する

それでは、はじめていきたいと思います。

1.GCP上に、SonarQubeサーバーを立てる

今回は、Google Cloud Platform上にSonarQubeを構築するにあたり、
Bitnamiで予め用意されているパックを、使用することとします。

Bitnamiのパックでは、環境を構築するにあたり必要なものをすべて揃えてくれています。
今回だと、SonarQubeのモジュールの外にApacheやMySQLなどですね。
これらを、仮想サーバ上にボタン一つですべて配置してくれます。
とても便利なので、ありがたく使わせていただきます。

まずは、GCPのマーケットプレイスでSonarQubeを検索します。
マーケットプレイスは、画像の以下の箇所から移動できます。

SonarQubeのページを開いたら、「COMPUTE ENGINE上で起動」を選択します。

構成設定をします。
GCP上でSonarQube環境を構築するにあたり、使用するVMの構成等を決めることができます。

ただし、マシンタイプを小さくすると、サーバーとしては問題なくとも、
裏でSonarQubeの起動に失敗するようになるので、注意してください。

以上を終えると、SonarQubeを乗せたサーバーが起動します。
ためしに、「Log into the admin panel」を押下して、アクセスしてみましょう。
ログインに使用するユーザーIDとパスワードは、adminユーザーのものになります。

初回アクセス時は、adminユーザーのアクセス用トークンの払い出しと、
登録するプロジェクトの言語タイプを選択します。

アクセス用トークンは、払い出したタイミングでしか確認できないので、
コピーして手元に保存してください。
言語タイプは、後からでも変更可能です。

以上で、SonarQubeの初期設定が完了しました。

2.ローカル環境にSonarQube Scannerを用意する

まずは、以下からScannerをダウンロードします。
https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner
解凍し、パスを通しておいてください。

まず、Scannerの設定をします。
ダウンロードしたファイルの以下のパスに、「Sonar-scanner.properties」がありますので、
そちらを編集します。

#Configure here general information about the environment, such as SonarQube server connection details for example
#No information about specific project should appear here

#----- Default SonarQube server
sonar.host.url=http://<GCP上に立てたSonarQubeのアドレス>:80

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

sonar.login=<アクセス用トークン>

Bitnamiで作成したSonarQubeは、初期状態で80と443のポートが開いています。
ここでは、80を使用しています。
アクセス用トークンは、SonarQube初回アクセス時に生成したものになります。
万が一控えていなかった場合は、SonarQube上で新しいアクセス用トークンを払い出してください。

次に、SonarQubeで管理したいプロジェクトの直下に「sonar-project.properties」を作成します。

sonar.projectKey=demo:iris
sonar.projectName=demo
sonar.projectVersion=1.0

sonar.sources=./demo/src
sonar.java.binaries=./demo/target

それぞれ以下のような内容です。

sonar.projectKey SonarQube上での一意になるキーです。解析結果をDBに保存する際に使用されます。
sonar.projectName プロジェクト名です。SonarQube上で表示する際に使用されます。
sonar.projectVersion プロジェクトのバージョンです。
sonar.sources 解析するソースの配置場所です。
sonar.java.binaries ソースのビルドファイルの配置場所です。Javaのプロジェクトを解析する場合にのみ必要です。

注意しないといけないのは、sonar.projectKeyの扱いになります。
SonarQubeは、解析結果をDBに保存しますが、
その際にプロジェクトごとに認識キーを作成して保存します。

このキーが一致すると同じプロジェクトとみなし、DBを上書きする仕組みになっているので、
複数のプロジェクトを管理する際にうっかり同じプロジェクトキーを設定してしまうと、
以前の解析結果を、他のプロジェクトの解析結果が上書いてしまうことになります。

以上で、Scannerの設定は完了になります。

3.スキャンした結果を確認する

「sonar-project.properties」の階層で、以下を実行します。

sonar-scanner

EXECUTION SUCCESSとなることが確認できたら、GCP上のSonarQubeにアクセスして確認してみます。


作成したプロジェクトについての解析結果が出ています。
プロジェクト名を押下すると、より詳細なレポートを見ることができます。


今回は、サンプルプログラムであるためちょっと貧相な結果ですが、
このページでは以下のことを確認できます。

  • バグの個数
  • リファクタリング対象になりそうな場所
  • カバレッジ
  • 重複したコードの割合

また、コードの問題のある個所を、以下のように表示してくれます。

この画像の例だと、他で使用していない変数があるという指摘が出ています。

まとめ

今回は、GCP上にSonarQubeを配置するための簡単な導入でした。
SonarQubeを使用すると、人を介さずともある程度コードの問題点を洗い出してくれるため、
常に一定の品質を保つことができます。

また、コードのちょっとした問題点などの些末なものが取り除かれた状態でレビューを行えるため、
レビュアーはより業務よりな観点でのレビューに注力することができるようになります。

さらに、今回はローカルからスキャンを実行しましたが、
この処理をコンポーネント化してGCP上に置いてしまえば、
GCPでGitのDevelopブランチに対するコミットを検知し、コンポーネントを起動してスキャンを行い、
その結果をSonarQube上で常時確認できる、というような流れの構築も可能ではないでしょうか。

このように、CI/CD環境の構築を始めると、どんどん夢がふくらんでいくので、
もしもこの記事を読んで興味がありましたら是非試してみてください。

佐藤
LS部 佐藤
新卒3年目で、目下クラウド環境を勉強中です。趣味はパズル全般。