ドキュメント

チェック項目、実行結果および検出内容

検証実行結果を確認し、検出された問題を分類して対応策を決定する。

「チェック」とは、単一の検証を指します。チェックは単一の検証を指します。 「実行履歴」とは、実行履歴とは、ポリシーに基づき変更内容に対してチェックを実施した一回分の結果を指します。 「検出結果」とは検出結果とは、チェックによって報告される事象を指します。

タスクの検出結果はその 品質管理 セクションに記載されます。品質管理各実行内容は 設定 → アクティビティ で確認できます。設定 → アクティビティ。

実行履歴の確認方法

実行履歴には各チェックの結果と出力内容が記載されています。検証に失敗した場合、その原因を把握するには実行履歴を確認します。

上から順に確認してください。最初に失敗したチェックが本当の原因であることが多いです。ビルドエラーに続いて12件のテストエラーが発生した場合、それは1つの問題であり13個の問題ではありません。

検出結果

検出結果はレビューエージェント、スキャナー、アドバイザリーゲートから生成されます。各検出結果には発見された内容、発生場所、重大度が記載されています。タスクに関連する検出結果はそのタスクに紐付けられます。特定のタスクに属さないテスト失敗は、工場内の「あなたの対応が必要」セクションに一時的に保存され、そこで修正するか理由を付けて承認します。ユニットテスト用のテストフレームワークが存在しないなど、プロジェクト内で実行できないチェック項目については、品質管理画面の該当行にその旨が記載されます。

そのライフサイクルは以下の通りです:

  1. 作成済みチェックまたはレビューアーによって作成されます。
  2. 割り当て済み修正可能な検出結果は再作業として開発者エージェントに戻され、それ以外はpull requestに添付されます。
  3. 解決済み修正済み、承認済み、または無視済みの状態です。

提起された項目

  • アドバイザリーゲート
  • レビューアエージェント
  • 接続されたスキャナー

割り当てられた項目

修正可能な項目

再作業として開発者に戻される

その他の項目

pull requestに添付される

解決済みの項目

  • 修正完了の項目

    この変更で問題が解決される

  • 承認済みの項目

    確かに問題だが、ここでは対応する必要がない。その理由を明記してください。

  • 抑制済みの項目

    誤検知または該当しないルール。その理由を明記してください。

修正可能なファインディングは実行中に処理されます。残りはpull requestに届き、すべてのファインディングは修正、承認、または保留され、最後の2つにはその理由が記載されます。

分類作業

各検出結果に対する問いは「これは真実か?」ではなく「これが次の工程に影響を与えるか?」です。

  • 今すぐ修正正確性やセキュリティなど、レビューで却下される可能性のある問題です。
  • 承認事実ではあるが、今回は対応する必要がない問題です。その理由を記録してください。
  • 無視誤検知であるか、またはこのコードには該当しないルールです。

無視する場合は必ず理由を明記してください。理由の明記されていない無視は、不都合な事実を隠す行為と変わりません。数ヶ月後にはどちらだったか誰にも判断できなくなります。

検出結果が多すぎる場合

検出結果の量はコード品質ではなく設定に関するシグナルです。

ほとんどの変更でチェックが発動する場合、それは問題を発見しているのではなくコードベースの特性を表しています。ルールが既存の規約に合致しないか、または容認している技術的負債であるかのどちらかです。いずれにせよ、そのチェックの設定が適切でないことを意味します。

検出結果とゲート

アドバイザリーゲートによる検出結果は参考情報です。一方、ブロッキングゲートによる同じ検出結果はタスクの進行を停止させます。検出結果自体は同一ですが、ポリシーによって影響が決まるのです。

チェックが正しいが厳格すぎる場合に使うべき手段は、チェック自体を削除するのではなく重大度を変更することです。詳しくは品質ポリシーとゲート。