これは他のドキュメントが参照するページです。各実行ステージを明記しているため、他の記事で処理が行われる場所を正確に特定できます。
パス
- 1
仕様定義何を構築するか、およびそれが正常に動作したかをどう確認するか
アーキテクト編集可能 - 2計画立案
順序付けられた手順で、コードを書く前にレビューを受けます。
アーキテクト承認可能 - 3
ビルド作成隔離されたワークスペースでコードとテストを作成します。
開発者 - 4
検証実施ご自身のテストスイートに加え、チェックと品質ゲートを実施します。
QA - 5
レビュー実行差分に対して自動化されたレビューが行われます。
レビュー担当者 - 6プルリクエスト作成
リポジトリ内のブランチ上にあり、あなたの承認を待っています。
マージ可能
検証失敗や修正可能なレビュー指摘は、pull requestが作成される前に開発者へ再作業として戻されます。
これらのステージは、タスクが実行される2つのモードで共通しています。標準モードでは、プラットフォームがタスクをあるステージから次のステージへと進めます。コーディネーター・モードでは、計画エージェントがコーディネーターとしてタスクに留まり、各ステージを適切なエージェントに割り当て、各結果後の処理を決定します。作業を戻すことも含まれます。いずれの場合も、ステージは独自のチェックによって終了します。詳細はエージェントの役割をご覧ください。2つのモードの違いについて説明しています。
仕様
Coroidはあなたの文章から直接始まるわけではありません。まずあなたの記述を仕様に変換します。つまり、何を構築するか、明確に範囲外とされるもの、そして作業が成功したかを判断する受入基準です。
これは重要です。なぜなら受入基準こそが、後で検証ステージでテスト対象となるからです。曖昧な仕様では、成果を判断しにくくなります。
タスクの「仕様」タブで仕様を閲覧・編集できます。仕様タブで実行開始前に設定できます。
この仕様駆動型開発ガイドでは、テスト可能な基準の記述方法、範囲の境界設定、計画・実装・レビューを通じて同じ成功定義を維持する方法を解説しています。
計画
小規模な変更を超える場合、仕様は計画に変わります。これは順序付けられた手順の集合で、フェーズに分けられます。コードを記述する前に計画を承認します。
計画を却下するのはコストが低く、アプローチが誤っている場合には適切な判断です。コード記述後に却下するとコストが高くなります。このステージこそが、あなたの判断が最も影響力を持つ場面です。
構築
エージェントはリポジトリを隔離されたワークスペースにクローンし、そこで作業します。コードを読み取り、変更を記述し、テストを作成または更新します。
ワークスペースは一時的でタスクごとに異なります。エージェントの作業がデフォルトブランチに影響を与えることはありません。同時に実行される2つのタスクが互いの進行中の作業を参照することもありません。
検証
まずあなた自身のテストスイートが実行されます。これが最も信頼性の高いシグナルです。なぜなら、チームが既に重要と判断した内容が反映されているからです。
さらに、品質ゲートでは、組織が設定した内容が実行されます。カバレッジの閾値、リンティング、プレビュー環境でのブラウザテスト、そしてセキュリティの保護機能です。ブロッキングゲートはタスクを停止し、アドバイザリーゲートは検出結果を記録してタスクを続行させます。
レビュー
レビューアーエージェントは同僚と同じように差分を確認し、検出結果を生成します。修正可能な検出結果は再作業のために送り返され、それ以外はpull requestに添付されてあなたが確認できるようになります。
だからこそ、Coroid pull requestはすでにレビュー済みの状態で届きます。あなたのレビューを置き換えるためではなく、あなたのレビューが最初のものにならないようにするためです。
プルリクエスト
ブランチがプッシュされ、pull requestがベースブランチに対して開かれます。変更内容、テスト結果、検証結果、レビュー結果が含まれます。タスクの要求通りにコードが既に完成している場合は、プッシュするものはありません。代わりにQAが変更されていないコードを検証し、pull requestなしでタスクが完了します。
Coroidのタスク自動化はここで終了します。マージはあなたの役割です。
マージ後
配信用に準備するには「リリースを開いて、配信するコミットを正確に設定します。リリースには複数のマージ済みプルリクエスト、直接コミット、またはCoroid外でマージされた作業が含まれる場合があります。リリースゲートと承認はそのコミットおよび特定の環境に関連します。パイプラインがそれをデプロイし、Coroidが配信済みと表示する前に、観測された成功または明示的な保証を記録します。"COMPLETEDとマークされたタスクや、マージ済みのpull requestだけではデプロイを証明できません。
タスクのステータス
タスクのステータスにより、上記のプロセス内でどの段階にあるかがわかります：
| ステータス | 意味 |
|---|---|
PENDING | 承認済み、利用可能なエージェントスロットを待機中 |
IN_PROGRESS | 現在作業中 |
PENDING_REVIEW | 作業が完了しレビュー済み、統合または承認を待機中 |
COMPLETED | タスクの作業は完了、デプロイは別途追跡 |
NEEDS_HUMAN_REVIEW | Coroidが単独で処理を続行できず、あなたに質問をしています。 |
PAUSED | 一時的に停止、再開可能 |
FAILED | 実行を完了できませんでした |
CANCELLED | あなたによって停止されました |
WONT_FIX | 作業を行わずに意図的に閉じられました |
スループットを決定する要因
1つのエージェントスロット一度に1つのタスクのみを実行します。スロットは並列で処理される作業量を決定するものであり、単一のタスクの完了時間を短縮するわけではありません。タスクの所要時間は変更の規模とテストスイートの実行時間によって決まります。
次へ
エージェントの役割— 各作業ステージを担当するエージェントを確認してください。その後、以下をご覧ください。リリース環境間でのマージ後の処理フローについてはこちらを参照してください。