目的から結果まで
Kiwiで目的を決め、Nxで実行し、Allureで結果を見る。
Kiwi TCMSで自動9目的と手動1目的を管理し、レビュー済みの目的をGitへexportする。Nxはその定義に対応したVitest、Playwright、pytestを実行する。今回実行した結果はAllureへ、再利用元を含む実行記録は目的単位でKiwiへ同期する。
- Kiwi：目的・担当・手動結果
- Nx：選択・依存順・cache
- Allure：今回実行した結果
図を拡大 ↗
必要な検査を、一度ずつ
ローカル一式ではbuildを共有し、同じ入力の単体・型検査を再利用します。
Nxのローカル一式は126条件と型検査、build。単体・画面部品72条件と型検査はcache対象。運用38条件は毎回実行する。buildの後にDB統合14条件とブラウザ2条件が実行可能になり、buildは一つのグラフで一回。矢印は依存関係で、兄弟タスクの固定順序や並列実行を示さない。
- ローカル 126条件＋型検査＋build
- cacheは単体・画面部品・型検査
- DB・ブラウザ・運用は毎回実行
検査ごとに環境を分ける
DB統合とブラウザは、それぞれのPostgreSQLを持ちます。
DB統合はVitestから業務API・AI Workerと実PostgreSQLを確認し、固定providerの応答を使う。ブラウザはPlaywrightから専用Web・Auth Worker・D1と別のPostgreSQLを使用し、PCと狭幅で利用者を分ける。共有するのはSaaS build成果物。共有Staging・本番DBを初期化せず、実OpenAIへ通信しない。終了時にそれぞれが所有する接続・process・containerを片付ける。
- 共有するのはbuild成果物
- AIは固定応答で検査
- 共有Staging・本番DBを初期化しない
本番反映は、段階ごとに確認
ローカル検査、準備、切替、公開後の確認を、それぞれ判定します。
固定した候補のローカル検査後、署名bundle・隔離DBの予行・実環境readinessを確認する。承認範囲の正規CLIで切り替え、公開後はsmoke 3条件に加えobserverとログ・主要操作を確認する。DB更新なしは無停止Blue/Green、DB更新ありは明示的な計画停止。手動1目的で準備と公開後確認を記録し、自動検査の合格で代替しない。この図は確認段階を示し、実際の配備完了状態ではない。
- 候補を固定して検査
- 実環境・署名・DB予行は別確認
- 手動目的に準備と公開後の記録
最小構成を保つ3つのルール
- 同じリスクを重複させない
最も低コストな層で確認し、上位層には代表経路を残す。
- 目的があるときだけ追加する
未検出のリスク・担当・見直し条件をKiwiへ記録する。
- 変更と一緒に整理する
廃止仕様・重複・不安定・高コストな検査を見直す。