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