Quality Gates

• はじめに
• ビデオツアー
• クオリティゲートとビルド失敗
• クオリティゲートの作成とカスタマイズ
• クオリティゲートの状態を探索
• 問題修正の優先順位付けと Breaking-Point メトリック

品質ゲートはコード品質の事実に対するチェックで である必要がある リリース前、および必要に応じてソース管理へのコミット前に適用されます。Quality Gate は、ソフトウェア品質の PASS/FAIL の基準と見なすことができます。

CppDependは技術的負債量、コードカバレッジ、特定の重大度の問題数などの測定に関連する12のデフォルト品質ゲートを提供。

特別な点に注意 赤/黄/緑のひし形アイコン クオリティゲートの状態を表示: 失敗 / 警告 / 成功。

品質ゲートの用途： ビルドを失敗させる 特定の基準が検証されない場合。

少なくとも1つのクオリティゲートが失敗すると、 CppDepend.Console.exe ビルドを失敗させるために使用できるゼロ以外の値を返します。

CppDependのユニークな点は、品質ゲートがC# LINQクエリであり、簡単に作成・編集・カスタマイズできること。例えば、品質ゲートで一定のコードカバレッジを強制するには次のように書くだけ：

1// <QualityGate Name="Percentage Code Coverage" Unit="%" />
2
3failif value < 70%
4
5warnif value < 80%
6
7codeBase.PercentageCoverage

特別な句にも注目 failif (必須条項) および warnif （オプション句）は CppDepend CQLinq 固有です。 codebase.PercentageCoverage は実際には CppDepend が評価する C# ステートメントです。

Quality Gate の名前と単位を定義する特別なヘッダーコメントに注目してください。ここでの単位は文字列「%」です。読みやすくするために、しきい値の後に必要に応じて繰り返すことができます。

Quality Gate は、ベースライン以降の差分に基づいてメジャーを決定することもできます。たとえば、以下の Quality Gate は、ベースライン以降、全体的な技術的負債が特定のしきい値を超えて増加しないことを保証します。

注意: タグを使用して、開発者以外向けに Quality Gate を説明できます。

1// <QualityGate Name="New Debt since Baseline" Unit="man-days" />
2
3failif value > 2 man-days
4
5warnif value > 0 man-days
6
7let debt = Issues.Sum(i => i.Debt)
8
9let debtInBaseline = IssuesInBaseline.Sum(i => i.Debt)
10
11select (debt - debtInBaseline).ToManDay()
12
13//<Description>
14
15// This Quality Gate fails if the estimated effort to fix new or worsened
16
17// issues (what is called the *New Debt since Baseline*) is higher
18
19// than 2 man-days.
20
21//
22
23// This Quality Gate warns if this estimated effort is positive.
24
25//
26
27// Debt documentation: http://www.CppDepend.com/docs/technical-debt#Debt
28
29//</Description>

最後に、Quality Gate のしきい値を定義する際、キーワード 値 キーワードに置き換える必要があります count LINQ クエリがスカラーではなく行を返す場合。

これは、意味がある場合に Quality Gate の結果をより有益にするのに役立ちます。

Quality Gates のステータス セットは C# LINQ クエリから照会できます。

ダッシュボードは Quality Gates のステータスを要約します。ワンクリックで、各 Quality Gate の詳細なステータスを表示する LINQ クエリが生成されます。Quality Gates のステータスは HTML+js レポートでも提供されます。

この ブレイキングポイント 問題または問題セットについて、問題の修正にかかる推定コストが、問題を修正しないままにしておく推定コストに達するまでの、現在からの時点です。

ブレイキングポイントは 負債を年利で割った値。たとえば、負債の修正にかかる推定コストが 10 人日で、推定年間利息が年間 2 人日の場合、損益分岐点は現在から 5 年後となります。

ブレイキングポイントに注意 より低い 年という単位は、今後 12 か月間、負債を修正する方が修正しないよりも安価になると推定されることを意味します。

損益分岐点は、負債や年間利息（人月または人年）のような人時ではなく、通常の期間（月または年）で測定されることにも注意してください。損益分岐点の値は TimeSpan 型です。

に関しては 最初に修正すべき問題の優先順位付け、問題の重大度は重要なパラメーターです。補足すると、重大度は年間利息の離散的な尺度です。したがって、年間利息が高いほど、修正が重要になります。

ただし、特定の重大度レベルが与えられても、すべての問題が同等というわけではありません。修正により多くの労力を要するものもあります。これは技術的負債の指標で推定されます。したがって、次を推定するには 投資収益率 (ROI) 問題の修正については、負債を年間利息で割って推定することに意味があります。この推定は損益分岐点であり、値が低いほど ROI が高くなります。

デフォルト ルールのセットでは、ベースライン以降の新しい問題に関連する問題（次のようなもの）は、 API破壊的変更, さらに悪化するコード要素の品質, テストされていない新しいコード要素... は、他の問題よりも高い年間利息、ひいては高い重要度を生じさせる問題です。これは次に準拠しています 最近導入された問題を最初に修正するベスト プラクティス.