ドキュメント

Coroidが自らの作業内容を検証する仕組み

なぜCoroidから送られてくるpull requestはすでにチェック済みなのか、そして各検証レイヤーが実際に何を保証するのか。

Coroidから送られてくるpull requestは、あなたが確認する前にすでに検証が完了しています。このセクションではその意味と設定方法について説明します。

検証のレイヤー

検証とは単一のプロセスではありません。4つのレイヤーがそれぞれ異なる問いに答えます。

テストスイート最も信頼性の高い指標です。なぜなら、チームが重要と判断した事項がすでに反映されているからです。Coroidは各タスクごとにクリーンなワークスペースでこれを実行します。

品質ゲートポリシーで定義されたチェック — カバレッジ、リンティング、セキュリティスキャン、ブラウザテストなどです。ブロッキングゲートはタスクを停止させ、アドバイザリーゲートは結果を記録してタスクを続行させます。詳細は「品質ポリシーとゲート.

レビューレビューアエージェントが完成した差分を読み取り、指摘事項を生成します。修正可能な指摘事項は再作業として開発者に戻され、残りはpull requestに添付されます。

証拠プレビューデプロイメント、スキャン結果、カバレッジの差異がpull request自体に添付されるため、検証情報がコードと共に届きます。詳細は「レビュー証拠.

これが保証し、保証しないこと

検証により、変更内容が意図通りに動作し、既存機能を壊さず、定義された基準を満たすことが確認されます。

検証は保証しませんその変更が構築すべき適切なものであることを保証するのではありません。それは仕様書に記載された受け入れ基準や、あなたのレビューの目的です。

すべてのレイヤーを通過しても間違った変更である可能性があります。この区別を明確に保つことが、全体の信頼性を維持する鍵です。検証結果を判断材料と見なすと、人々はレビューをしなくなってしまいます。

事前に実行する目的

各レイヤーはpull requestが作成される前に実行されるため、失敗はpull requestとして拒否されるのではなく、実行中に再作業として戻されます。

ワークスペース内で失敗する方が、画面上で失敗するよりもコストが抑えられます。あなたのレビューは最初の人の確認であるべきで、最初の確認ではありません。

開始方法

初めてこの設定を行う場合:

  1. テストスイートが正常に動作するか確認してください — 「 ビルドおよびテスト設定」を参照してください。これが正しくなければ他の設定は意味をなしません。
  2. 組織のデフォルトポリシーを標準レベルで設定し、最も厳格な設定にしないでください。
  3. 既に使用している証拠プロバイダーを接続します。
  4. ゲートは一度に1つずつ追加し、まずはアドバイザリーゲートから始めます。

このセクションの目次