SonarQube Server automates code quality and security reviews and provides actionable code intelligence so developers can focus on building better, faster. Deployed by you where you work: on-prem or in the cloud.

はじめに 数年ぶりにSonarQubeを触ってみたくなり、試したところかなり簡単だったので、その感覚を残したく記事化してみました。 SonarQubeとは SonarSourceのプロダクトの一つであり、コード品質、コードセキュリティのチェックを実施するツールです。 さまざまな使い方ができるのだと思いますが、簡単に使うためにはJenkinsなどのツールと同じようにSonarQube用のサーバーとして1プロセス立ち上げ、その中でチェックと、チェック結果を確認・参照することができます。 今回やりたいこと MavenでビルドしているJavaプロジェクトに対して、ソースコードの品質が不安なので第三者チェックしてほしいと思うことがあると思います。その際に頼めるレビューアーがいないので最低限確認するためにツールにレビューをお任せしたい、ということがやりたいことです。 JenkinsのようなCI環境も手
こんにちはー!こねひとちほーのえんじにあのフレンズ@Utmrerだよー! 今回はPull Requestを自動でチェックしてくれるDangerについて紹介します。 Pull Requestでのコミュニケーション Pull Requestのレビューは不具合の指摘やコーディングスタイルの統一、より良いコードのための提案などのために行われます。 ですが、次のようなコミュニケーションをしたことはありませんか…? タイトルにIssue Idを含めてもらえますか? WIPみたいなんですがレビューして大丈夫ですか? Base branchが間違ってます、変更してください。 変更履歴のdocsを更新してください。 このような「実装とは関係のない指摘」はできるだけ減らし、自動化したいものです。それを実現するのがDangerです。 Dangerとは DangerのGitHubには次のように書かれています。 F
Elixir コードもレビューしてくれるサービス Ebert が Plataformatec から以前にリリースされていたので、そちらを紹介します。 GitHub の公開リポジトリであれば無料で使えるとのことで早速使ってみました。 概要 タイトル通り Elixir コードもレビューしてくれるサービスです。 対応言語は最初 Elixir だけかと思っていましたが、実は結構いろいろとサポートしているようです。 Elixir については Credo を使ってレビューしてくれます。 レビュータイミングは日ごとと Pull Request が来た時です。 レビュー結果の例として ecto のリポジトリで試した結果があるので参考になります。 設定方法 add a new repository から画面上の指示に従って作ることができます。 GitHub 認証でアカウントを作った後、連携のための GitH
モデル検査(モデルけんさ、Model Checking)とは、形式システムをアルゴリズム的に検証する手法である。ハードウェアやソフトウェアの設計から導出されたモデルが形式仕様を満足するかどうか検証する。仕様は時相論理の論理式の形式で記述することが多い。 モデル検査はハードウェア設計に適用されることが最も多い。ソフトウェアに対するモデル検査は決定不能であるため、アルゴリズム的な手法だけでは完全ではなく、証明も反証もできない場合がある。 モデルはハードウェア記述言語や専用の言語で記述されたソースコードの形態となるのが一般的である。そのようなプログラムは有限状態機械に対応付けられ、ノード(接点)とエッジから成る有向グラフで表される。原子命題の集合は各ノードと対応し、一般にメモリ要素の内容に対応する。ノードはシステムの状態を表し、エッジはある状態から他の状態への遷移可能性を意味する。その場合、原子
ソフトウェアインスペクション(英: Software inspection)とは、ソフトウェア開発プロジェクトで作成された成果物(仕様書やプログラムなど)を、実際に動作させることなく人間の目で見て検証する作業を言う。 通常のテストでは見つけられない欠陥、具体的にはコーディングルールに対する違反や極めて限定された条件でしか発生しない誤動作に繋がる問題点が検出されることがあり、プログラムを動作させて行うテストと補完関係にあるとされる。一般的に、プログラムを動作させて行うテストを動的テスト、インスペクションやウォークスルーなどのようにプログラムの動作を伴わないテストを静的テストと呼ぶ。 静的テストにはインスペクションの他に、ウォークスルーやピアレビューと呼ばれる技法がある。他の技法とインスペクションの違いは以下の通り。 責任者としてモデレーターが任命され、インスペクション作業全体を統括する 検出
静的コード解析 (せいてきコードかいせき、static code analysis) または静的プログラム解析 (static program analysis) とは、コンピュータのソフトウェアの解析手法の一種であり、実行ファイルを実行することなく解析を行うこと。逆にソフトウェアを実行して行う解析を動的プログラム解析と呼ぶ[1]。静的コード解析はソースコードに対して行われることが多いが、少数ながらオブジェクトコードに対して行う場合もある。また、この用語は以下に列挙するツールを使用した解析を意味することが多い。人間が行う作業はインスペクション、コードレビューなどと呼ぶ。日本語では静的コード分析とも訳される[2]。 ツールが行う静的コード解析の洗練度は、個々の文や宣言だけを検証するものから、プログラム全体を解析するものまで様々である。解析結果の利用も様々で、Lintのように単に指摘するだけの
コード網羅率(コードもうらりつ、英: Code coverage、コードカバレッジ)は、ソフトウェアテストで用いられる尺度の1つである。プログラムのソースコードがテストされた割合を意味する。この場合のテストはコードを見ながら行うもので、ホワイトボックステストに分類される。 コード網羅率は体系的なソフトウェアテストのための技法として最初に生み出されたものの1つである。1963年の Communications of the ACM にある Miller と Maloney の論文に言及されているのが最初である。 コード網羅率の測定にはいくつかの手法があり、主なものとしては以下のような手法がある。 文網羅 - ソースコードの各文がテストで実行されたかどうかで判断する。 分岐網羅 - 制御構造上の分岐でそれぞれの分岐方向がテストされたかどうかで判断する。 条件網羅 - 分岐条件の各項で真と偽の両
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く