pull requestは、Coroidから届く前に検証を受けています。この セクションでは、その意味と設定方法を説明します。
レイヤー
検証とは単一のプロセスではありません。4つのレイヤーがそれぞれ異なる問いに答えます。
あなたのテストスイートCoroidは、チームが重要と判断した内容がすでに反映されているため、最も信頼性の高い指標です。Coroidは各タスクごとにクリーンなワークスペースでこれを実行します。
品質ゲートポリシーで定義されたチェック項目 — カバレッジ、リンティング、ブラウザテスト、およびグローバリゼーション チェック項目多言語プロジェクト向けです。ブロッキングゲートはタスクを停止し、アドバイザリーゲートは結果を記録して処理を続行させます。詳細は品質ポリシーとゲートをご覧ください。セキュリティスキャンには別の位置付けがあります。詳細はセキュリティ。
レビューレビュー担当エージェントが完成した差分を読み取り、指摘事項を生成します。修正可能な指摘事項は再作業として開発者に戻され、それ以外はpull requestに添付されます。
証拠プレビュー展開、スキャン結果、カバレッジの差異がpull request自体に添付されるため、検証情報がコードと共に提供されます。詳細はレビュー証拠。
- テストスイートこの変更により既存の機能が壊れていませんか？
- 品質ゲートポリシーで定められた基準を満たしていますか？
- レビュー作業差分を注意深く読む人がそれを承認しますか？
- 証拠資料コードの隣に証拠が添付されていますか？
- ユーザーによるレビューこれは適切な変更ですか？
pull requestが存在する前に各自動化レイヤーが実行されるため、失敗した場合は実行中に再作業として戻されます。
これが証明するものと証明しないもの
検証により、変更が意図した通りに動作し、既存の機能を壊さず、定義した基準を満たすことが確認されます。
ただし、そうではありませんこの変更が構築すべき適切なものかどうかを判断するのは、仕様書に記載された受入基準と、あなたのレビューの役割です。
すべてのレイヤーを通過しても間違った変更になる場合があります。この区別を明確に保つことで、全体の信頼性が維持されます。検証結果を判断材料として扱うと、人々はレビューをやめてしまいます。
事前に実行する目的
pull requestが作成される前にすべてのレイヤーが実行されるため、失敗はpull requestとして拒否されるのではなく、実行中に再作業として戻されます。
ワークスペース内で失敗する方が、画面で確認するよりもコストが抑えられます。あなたのレビューは最初の人の確認であるべきで、最初の確認ではありません。
開始方法
初めてこの設定を行う場合：
- テストスイートが正常に動作することを確認してください — 詳細は ビルドおよびテスト設定これが正しくないと他の設定は意味をなしません。
- 組織のデフォルトポリシーを標準レベルで設定し、最も厳格な設定は避けてください。
- 既に使用している証拠プロバイダーを接続します。
- ゲートは一度に1つずつ追加し、まずはアドバイザリータイプから始めます。