Coroidはビルド工程だけでなく、完全なソフトウェアライフサイクルをモデル化します。その大部分は自動的に実行されますが、重要度が高い作業の場合にのみ有効にできる任意のチェックポイントも存在します。
任意のSDLCワークフロー
「新規作業フォームの詳細設定欄にはチェックボックスが用意されています：
SDLCワークフローを利用（任意）— 計画立案前に意図と仕様書をレビューします。このオプションを無効にすると、要件定義から直接計画を開始できます。
デフォルトでは無効になっています。無効にすると、要件定義が通過次第すぐに計画が開始されます。要件定義有効にすると、まず2つの成果物が作成・承認されます：
- 意図— 作業の目的や、それを決定した根拠となる判断や前提条件が記録されます。
- 仕様書— 作業範囲、除外項目、受入基準が明記されます。
これらが承認された後にのみ、計画立案が始まります。
いつ有効にすべきか
間違ったものを構築した際のコストが高い場合、依頼者自身が計画をレビューしない場合、または要件定義に記載されていない前提条件を明文化して合意を得たい場合に、この機能を有効にしてください。
要件定義が明確な場合は無効にしてください。定型作業に余分な承認プロセスを加えると、メリットのない手間が増えるだけです。なお、計画承認ステップはどちらの場合でも適用されます。
5つのステーション
完全なライフサイクルは5つの段階で構成され、各段階で次の段階で利用する証拠が生成されます。
| ステーション | 処理内容 | ステータス |
|---|---|---|
| 定義 | 曖昧な要求が、承認済みの意図、判断、前提条件、成功指標に変換されます。 | ベータ版 |
| 可視化 | 任意のUIコンセプトが洗練され、設計ガイドラインとして承認されます。 | ベータ版 |
| 実装 | 計画が分解され、エージェントがそれを実行します。 | 利用可能 |
| 証明する | 要件がタスク、チェック項目、レビュー結果、およびプルリクエストの変更内容に紐付く | 利用可能 |
| 改善する | 監視、修正、評価を通じてリグレッションを次のサイクルの作業に変換する | 利用可能 |
- 定義段階承認された意図、判断、前提条件、成功指標ベータ版
- 可視化段階オプションのUIコンセプト。設計ガイダンスとして承認されるベータ版
- 納品段階プランが分解され、エージェントがそれを実行する利用可能
- 証明段階要件がタスク、チェック、ファインディング、変更にマッピングされる利用可能
- 改善段階リグレッションが次のサイクルの作業となる利用可能
オプションSDLCワークフローを有効にして、計画開始前に意図と仕様を承認します。
インプルーブが次のサイクルに反映される：モニター、修復、評価がリグレッションを新しい作業に変える。
「定義」と「可視化」は現在開発中の機能です。「デリバリー」「証明する」「改善する」は、チェックポイントを有効にしたかどうかにかかわらず、現在すべてのタスクで実行される処理です。
アーティファクトがバージョン管理される理由
承認はアーティファクトの正確なバージョンに紐付きます。承認済みのアーティファクトを編集すると、合意された内容が黙って変更されるのではなく、新しいドラフトが作成されます。
これこそが承認に意味を持たせる仕組みです。「仕様書」に紐付くだけで、その特定のバージョンに紐付かない承認では、後で文書の内容が変わってもそれに合致する承認となり、本来の承認とは言えません。
承認の役割
プロダクト、デザイン、技術、セキュリティ、リリースの各責任を個別に割り当てられるため、セキュリティへの影響を承認する人がスコープを承認する人と必ずしも一致するわけではありません。
証拠の系譜
各工程で証拠を作成する目的は、完成したpull requestを遡って追跡できるようにするためです。つまり、この変更がこのタスクを実装し、そのタスクがこの要件に基づき、さらにその要件が承認された意図に基づくのです。
この連鎖があるからこそ、自律的なデリバリーを監査可能にできます。これがなければ動作するコードはあっても、なぜそれが求められたコードなのかの根拠が存在しません。
レビュー済みのコードからリリースまで
pull requestは作業サイクルの出力物です。リポジトリのルールでマージが許可されると、リリースは完全なコミットSHAを固定し、そのコミットに含まれる変更内容を記録します。その準備状態のゲートでは、選択された環境に対してその正確なコミットが評価されます。承認はゲートのスナップショットに紐付き、候補やポリシーを編集すると以前の決定が無効になります。
デプロイを要求すると、接続されたパイプラインで処理が開始されます。プロバイダーのコールバックまたは手動の証明により、どのコードが環境に到達したかが記録され、デプロイ後のカナリア分析で健全性が別途記録されます。したがって、タスク、pull request、リリースはそれぞれ異なる意味を持ちます。作業が完了したからといって、コードが本番環境に到達した証拠にはならないのです。
これが計画とどのように関連するか
SDLCワークフローと計画は異なるチェックポイントです：
- SDLCワークフローはSDLCワークフローは何を構築すべきかを、アプローチが存在する前に承認します。
- 計画は計画はどのように構築するかを、コードが存在する前に承認します。
どちらか一方、両方、またはどちらも使用しないことも可能です。どちらも、意見が分かれる完成したpull requestをレビューするよりもコストが低いのです。