SonarQubeでAzure Bicep開発を捗らせる(IDE編)
はじめに
自分が最近ちゃんと書けるコードといえば、Azureのインフラコード(IaC)であるBicepやTerraformが主です。
VS Code上で各種Linterや、Copilotも大活躍しているのですが追加で「SonarQube for IDE」も使ってみたらコーディング力が少し上がったので紹介させてください。
SonarQubeとは
SonarQube はコード品質とセキュリティを継続的に解析するプラットフォームです。静的解析によってバグの可能性、脆弱性、使いにくいコード(コードスメル)を検出し、ダッシュボードとレポートで可視化します。チームでのコードレビューの補助や CI パイプラインへの組み込みによって、運用負荷を減らしつつ品質を保つ目的で利用されます。
主な機能:
- 静的解析ルールによるバグ/脆弱性検出
- コードスメルの検出と技術的負債の可視化
- 複数言語サポート(TypeScript, Python, Java, C#, Bicep など拡張プラグインで増やせます)
- CI 統合(解析を自動化し、PR に品質ゲートを組み込む)
- ダッシュボードと履歴(時系列で品質がどう変わっているか追跡可能)
今回の記事で試用するものはVS CodeのSonarQube拡張機能となります。
この拡張機能を使ったコード編集中の静的解析では、特にSonarQubeサーバに繋げたりせずにスタンドアロンで無償で利用できます。
本格的に静的解析を行う場合にはサーバを立てたり、SonarQubeのエディションアップなどを検討しますが、ひとまず今回はライトに導入して気づいたことを書いていきます。
SonarQube for IDEの導入
VS Code拡張機能から「SonarQube for IDE」を検索して導入します。
マーケットプレイスのURLは https://marketplace.visualstudio.com/items?itemName=SonarSource.sonarlint-vscode です。
拡張機能が追加されましたね。特に今はCONNECTED MODEについても何もしなくて大丈夫です。
適当にBicepコードを書いてみる
Storage Accountを作成するコードを書きました。
非常にシンプルなため、Bicep拡張機能のLinterでも特に警告は出ていませんし、実際にAzure上に問題なくデプロイできます。
まあ、実際にはstorageAccountNameにこのデフォルト名でデプロイできる気は全くしないのですが構文的にはAzureはとりあえず受け入れてくれるでしょう。
param storageAccountName string = 'mystorageaccount'
resource storageAccount 'Microsoft.Storage/storageAccounts@2025-01-01' = {
name: storageAccountName
location: 'japaneast'
sku: {
name: 'Standard_LRS'
}
properties: {
// TODO 近々なんとかする
accessTier: 'Hot'
}
kind: 'StorageV2'
}
SonarQubeさんからの警告
高々14行のコードにもかかわらず、4件の警告が出ましたよ。
ひとつ一つ見ていきましょう。
minimumTlsVersion設定しろや!
セキュリティ警告として、TLS Version 1.0, 1.1などは使わないで明示的に最低TLS Versionを指定しようってことですね。
Microsoftも2026/1/31以降にTLS 1.0, 1.1を廃止する計画ですがそれまでも明示的に1.2以上を使うようにしたいです。
リージョン固定なんて…
メンテナンス性&信頼性の観点から、location指定にダイレクトなリージョン名を入れるべきではないとのことです。
resourceGroup().location
とか使うといいよ!
コメントでToDoとかイケていない
メンテナンス性のインフォメーションレベルのメッセージですが、コメントでToDoとか書いても見落とされるのがオチだよと言われてしまいました。
書く順番があるって…知ってた?
メンテナンス性の警告ですが、コードの中に書く要素の順番がしっかり決まっていました(これは私も最近知った)。
今回のコードでいうと、先頭にparameter定義があって、そのあとresouce定義ってところは良いのですが、resource定義の中の順番が問題でした。
上記URLの中からの抜粋ですが、以下の順序でかけとのことです。
- parent
- scope
- name
- location/extendedLocation
- zones
- sku
- kind
- scale
- plan
- identity
- dependsOn
- tags
- properties
無論絶対守るべきというわけではないですが、統一ルールがあることは良いですね。悩む必要がない。
修正後のコード
こちらが修正したコードです。Bicep Linter, SonarQube共に全てパスしました。
param storageAccountName string = 'mystorageaccount'
resource storageAccount 'Microsoft.Storage/storageAccounts@2025-01-01' = {
name: storageAccountName
location: resourceGroup().location
sku: {
name: 'Standard_LRS'
}
kind: 'StorageV2'
properties: {
accessTier: 'Hot'
minimumTlsVersion: 'TLS1_2'
}
}
思ったこと
コード開発を行う早期からこういったBicep LinterやSonarQube for IDEを導入することで、自然と可読性が高くセキュリティ面でも弱くないコードが書けるようになると感じました。
特に規模が大きくなったり、複数人で開発を進めるケースの場合、(動くのに)後から大量のコード修正を行うのはしんどいですよね。
本格的にチームでの開発を行う場合や、CI/CDパイプラインに組み込んで横断的にかつ時系列などでコードレビューを行う場合には、SonarQube Serverを導入していくことができそうです。
おわりに
今回は「無料で」「手軽に」コード品質を上げることができる「SonarQube for IDE」の紹介でした。
手前味噌ですみませんが、私が在籍している会社でのSonarQube紹介ページを最後に張らせてもらいます。
静的コード解析ツールSonarQubeとは?利用するメリットや対応言語、おすすめの活用方法を解説
参考になればと。
Discussion