SonarQube をどのように実装し、その大きな可能性を実現したか

私たちは、SonarQube コードの品質を継続的に分析および測定するためのプラットフォームを、National Settlement Depository の DPO システム (Alameda 預託および清算会計システムへの追加) 開発の既存のプロセスに実装した経験を共有したいと思います。

National Settlement Depository (モスクワ取引所グループ企業) は、50 兆ルーブル以上の価値があるロシアおよび外国の発行体の証券を保管および記録する主要な金融インフラ企業の XNUMX つです。 システムによって実行される操作量の増加と機能の継続的な増加により、システムのソース コードの高品質を維持する必要があります。 この目標を達成するためのツールの XNUMX つは、SonarQube 静的アナライザーです。 この記事では、SonarQube 静的アナライザーを部門の既存の開発プロセスにシームレスに実装した成功体験について説明します。

部門について簡単に説明すると

当社の能力には、NSD クライアントへの支払い、電子文書管理 (EDF)、取引リポジトリ メッセージの処理 (取引所外取引の登録)、クライアントと NSD 間の電子対話チャネルなどのモジュールが含まれます。 一般に、運用の技術面での大きな作業が行われます。 私たちはアプリケーションに基づいて作業を行います。 窓口の申請はアナリストによって処理されます。アナリストは顧客の要件を収集し、それをプログラムにどのように組み込むべきかというビジョンを私たちに提示します。 さらに、標準的なスキーム: コード開発 - テスト - 試行運用 - 生産回路へのコードの直接顧客への配信。

SonarQube を選ぶ理由

私たちの部門にとって、コード品質管理用のプラットフォームを実装するのはこれが初めての経験です。以前はコード レビューのみで手動で行っていました。 しかし、作業量が増大するにつれ、このプロセスの自動化が必要になります。 さらに、チームには社内の開発規定に詳しくない経験の浅い従業員もおり、ミスが多くなる傾向があります。 コードの品質を管理するために、静的アナライザーを実装することが決定されました。 SonarQube はすでに一部の NSD システムで使用されているため、選択にそれほど時間はかかりませんでした。 以前は、他の部門の同僚がこれを使用して、Alameda システム (NSD 独自の保管および清算会計システム)、CFT (会計、残高、必須報告書および内部報告書の作成のための情報システム) などのマイクロサービスのコードを分析していました。システム。 実験のために、SonarQube の無料バージョンから始めることにしました。 それでは、私たちのケースに移りましょう。

実装プロセス

我々は持っている:

• TeamCity でのシステムの自動組み立て。
• GitLab のフィーチャー ブランチからマスター ブランチに MergeRequest 経由でコードをアップロードするプロセスをセットアップします (GitHub Flow に従った開発プロセス)。
• SonarQube は、スケジュールに従って DPO システムのコードを分析するように構成されています。

私たちの目的: AVE の CI/CD プロセスに自動コード分析を実装します。

カスタマイズが必要: メイン ブランチへの MergeRequest ごとに静的アナライザーによってコードを自動的にチェックするプロセス。

それらの。 ターゲットの図は次のとおりです。開発者が変更を機能ブランチにアップロードするとすぐに、コード内の新しいエラーの自動チェックが開始されます。 エラーがない場合は変更を受け入れることができますが、そうでない場合はエラーを修正する必要があります。 すでに初期段階で、コード内の一定数のエラーを特定することができました。 このシステムには非常に柔軟な設定があり、システムやプログラミング スタイルごとに、開発者の特定のタスクに合わせて機能するように構成できます。

SonarQube での QualityGate の構成

QualityGate 分析は、インターネットの奥深くで読まれているものです。 当初、私たちは別のアプローチを使用していましたが、より複雑で、ある意味完全に正しいとは言えませんでした。 まず、SonarQube でスキャンを XNUMX 回実行しました。機能ブランチとその機能ブランチをマージするブランチをスキャンし、エラーの数を比較しました。 この方法は安定しておらず、常に正しい結果が得られるとは限りませんでした。 そして、SonarQube を XNUMX 回実行する代わりに、発生するエラーの数に制限を設定し (QualityGate)、アップロードして比較するブランチのみを分析できることがわかりました。

今のところ、まだかなり原始的なコードチェックを使用しています。 SonarQube は、Delphi などの一部のプログラミング言語と互換性がないことに注意してください。 現時点では、私たちのシステムでは PLSql コードのみを分析しています。

次のように機能します。

• プロジェクトの PL/SQL コードのみを分析します。
• QualityGate は、コミットによってエラーの数が増加しないように SonarQube で設定されています。
• 最初の実行時のエラーの数は 229 でした。コミット中にさらにエラーが発生した場合、マージは許可されません。
• さらに、エラーを修正すれば、QualityGate を再構成することが可能になります。
• テストによるコード カバレッジなど、分析用の新しい項目を追加することもできます。

作業スキーム：

スクリプトのコメントを見ると、機能ブランチのエラー数が増加していないことがわかります。 それですべてOKです。

「結合」ボタンが使用可能になります。

スクリプトのコメントを見ると、機能ブランチのエラー数が許容値を超えていることがわかります。 つまり、すべてが悪いのです。

「結合」ボタンは赤色です。 現時点では、誤ったコードへの変更をアップロードすることは禁止されていませんが、これは責任のある開発者の裁量で行われます。 将来的には、そのようなコミットがメイン ブランチに対して行われないようにすることができます。

バグに自分で対処する

次に、SonarQube は厳格な基準に従って分析するため、システムによって検出されたすべてのエラーを確認する必要があります。 彼がエラーだと考えているものは、実際には私たちのコード内のエラーではない可能性があります。 したがって、これが本当に間違いであるか、または条件を編集する必要がないかどうかを確認してメモする必要があります。 したがって、エラーの数が減ります。 時間が経つにつれて、システムはこれらのニュアンスを理解できるようになります。

私たちは何に来たのですか

私たちの目標は、この場合、コード検証を自動化に移行することが適切かどうかを理解することでした。 そして結果は期待に応えました。 SonarQube を使用すると、必要な言語を操作でき、かなり有能な分析を行うことができ、開発者のヒントから学ぶことができる可能性があります。 全体として、私たちは SonarQube での最初の経験に満足しており、この方向にさらに開発する予定です。 将来的には、コードレビューにかかる時間と労力をさらに節約し、人的要因を排除することでコードレビューを改善できるようになると期待しています。 おそらくその過程で、プラットフォームの欠点を発見することになるでしょう。あるいは、逆に、これが大きな可能性を秘めた素晴らしいものであることを改めて確認することになるでしょう。

この概要記事では、SonarQube 静的アナライザーについて説明しました。 ご質問がございましたら、コメントにご記入ください。 このトピックに興味がある場合は、新しい出版物で、すべてを正しく設定し、そのようなチェックを行うコードを記述する方法をさらに詳しく説明します。

テキストの作者： アタンヤ

出所： habr.com