プラン

「プラン」とは、複数のタスクを段階にまとめた順序付けられたセットです。コードが記述される前に、そのプランを承認する必要があります。

特定の順序で複数の変更が必要な場合や、いずれの作業にも着手する前に全体のアプローチを確認したい場合に、プランを利用します。

ライフサイクル#

計画立案は独立したステージであり、即座に変換が行われるわけではありません。

1. 計画立案が開始されます。リクエストが要件定義を通過すると、アーキテクトがコードベースを調査し、段階やタスクを策定します。計画立案は自動的に開始されますが、リクエストに添付ファイルが含まれる場合やSDLCワークフローが使用された場合は、プランを作成または準備を完了した時点で開始されます。
2. ドラフトをレビューします。これはシステム全体において最もコストが低い介入ポイントです。
3. 承認、修正、またはリセット。承認すると実行に移され、修正するとフィードバックと共に差し戻され、リセットすると計画立案からやり直されます。
4. 実行。タスクは段階の境界を守りながら順番に実行されます。

承認と同時に実行することも、承認して後から実行を開始することも可能です。

リセットよりも修正を選択しましょう#

プランがほぼ正しい場合、修正を施すことでアーキテクトがコードベースに関して得た知見を活かし、フィードバックを反映できます。一方、リセットするとそれらの情報が破棄され、一からやり直しになります。

アプローチ全体が誤っている場合はリセットし、アプローチは正しいが詳細が不十分な場合は修正しましょう。修正の方がはるかにコストが低く、却下されたプランの内容も失われることはありません。次の試みの入力として活用されるのです。

実行中のプランを制御する#

実行中のプランは一時停止、再開、キャンセルが可能で、各段階の進捗を確認できます。また、プランをクローンすることも可能で、これはうまく機能した構造を繰り返し利用するための実用的な方法です。例えば、別のサービスに同じマイグレーションを適用する場合などが該当します。

完了したプランは、アクティブなビューを明確に保つためにアーカイブできます。

pull request は1つだけ、タスクごとに作成されるわけではありません#

プランのタスクはそれぞれ別個のpull requestを開くのではなく、独自のブランチで作業を行い、共通のレーン・ブランチ」にマージされます。作業が条件を満たすと、そのブランチがベース・ブランチに対する単一のプルリクエストとして昇格します。

そのため、完成した機能を一度にレビューでき、半完成の段階を個別に承認する必要がなくなります。

クロスプロジェクトのプランは例外です。レーンとは異なるプロジェクトに属するタスクは別個に昇格されるため、リポジトリごとに1つのpull requestが生成されます。pull requestが2つのリポジトリにまたがることはありません。

ベース・ブランチが更新された場合#

プランは数時間にわたって実行されることもあり、その間にもチームはベース・ブランチに継続的にマージを行います。プランは開始時点のベース・ブランチを基準に構築、テスト、レビューされました。pull requestが完成する頃には、それがマージされるブランチが既に変更されている可能性があります。

プランが実行を開始すると、Coroidはベース・ブランチの最新コミットをプランのベースラインプランのpull requestがマージされる前に、Coroidは再度ベースブランチを確認します。プランで対象外のファイルを含め、ファイル内容の変更があればすべて対象となります。新しい認証方式やセキュリティルールにより、正しいコードが誤動作する可能性があるため、マージコンフリクトを待つことはありません。

ベースブランチが更新された場合、承認してマージこのボタンは無効なままで、プロモーションレビューには新しいコミットとそれらが変更したファイルが一覧表示されます。次に行う処理を選択できます：

• 新しいmainブランチを採用（ベースブランチにちなんで名付けられています）— この変更は該当する作業には影響しません。Coroidは、どのコミットを誰が承認し、その理由を記録し、そのコミットを新しいベースラインとします。閲覧中にブランチが再び更新された場合、Coroidはそれを拒否し、より新しいコミットを先に表示します。表示されない限り、いかなるコミットも承認されることはありません。
• マージして再検証— Coroidはベースブランチをレーン・ブランチにマージし、競合があればそれを解決します。その後、開発者、QA担当者、レビュアーによるプロセスを再度実行し、プランの受入基準および上位コミットに照らして検証します。検証が完了するまで承認は保留され、その後で初めて新しいコミットがベースラインとなります。マージまたは再検証に失敗した場合、決定権は再びユーザーに戻ります。

一時停止がデフォルト設定です。プロジェクト側で「マージして再検証」を選択すれば、Coroidはユーザーの待機を待たずに処理を開始します。詳細はこちらをご覧ください。リポジトリおよびブランチ設定。再検証にはエージェントの稼働時間が消費されます。

最初からやり直しで作成されたプランは新しいベースラインとして記録されるため、その時点のベースブランチに対して実行されます。以前の試行で得られた証拠は履歴に残りますが、新しい試行の有効なデータとはなりません。

強制マージこれもこのチェックをスキップし、その理由を記載した内容を記録します。詳細はマージ処理。

段階と並列処理#

段階は順序を決定するものであり、並列処理を意味するわけではありません。ある段階内のタスクはリソースに余裕があれば並列で実行できますが、次の段階は現在の段階が完了するまで待機します。

並列処理に対応するタスクが10個あり、エージェントのスロットが1つしかない場合でも、タスクは順番に実行されます。構造自体がリソースを生み出すわけではありません —リソースとエージェント・スロット。

プランかタスクか？#

「新規作業」フォームでは、「プラン」またはタスク」を「作成方法」の下で選択するか、または「自動」のままにして、要件定義に判断を委ねてください。複数のプロジェクトにまたがる作業は常にプランとなります。選択した方式と要件定義の推奨が異なる場合、いかなる作業も作成される前にその推奨内容が表示されます。

判断基準はレビュー可能性です。同僚が一度に読める範囲のpull requestはタスクであり、複数の順序付けられた変更が必要なものはプランです。

規模が大きい作業においてタスクを選択してしまう方がリスクが高い誤りです。タスクの途中で処理が行き詰まり、実行が無駄になる可能性があるからです。プランを選択してしまうと、必ずしも必要ではない承認ステップが追加されるだけです。

デリバリー・ゲート#

プランには、その出力が進捗する前に満たすべき条件を定めるデリバリー・ゲートを設定できます。詳しくは品質ゲート。

関連項目#

• タスク、プラン、スプリント、レーン
• スプリント
• 仕様書
• 来歴