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