055-design-parallel-change について
Java エンタープライズ開発者向けの、データベース移行を設計する対話型スキルです。Parallel Change の要否を判断し、互換性と検証を考慮した展開手順を組み立てます。
主な機能
- 01移行時の互換性要件の評価
- 02拡張・移行・縮小の手順設計
- 03バックフィルとスキーマ変更の計画
- 04検証とクリーンアップの定義
- 05フレームワーク別 Flyway スキルへの引き継ぎ
活用シーン
- 01安全なカラム名変更の計画
- 02ゼロダウンタイム移行の評価
- 03バックフィルと縮小展開の設計
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/055-design-parallel-changeを入力して読み込まれたか確認します。
同梱ファイルreferences/055-design-parallel-change.md
詳細
Parallel Change 設計
データベース移行のシナリオで、Java Enterprise 開発者が Parallel Change を活用できるようにガイドします。これは対話型の SKILL です。
この Skill で扱う内容
- データベース移行に互換性ウィンドウが必要かどうかの判断
- データベースの変更を、デプロイ可能な expand、migrate、contract の各ステップに分ける方法
- ロールアウトおよびロールバックの期間中に、旧バージョンと新バージョンのアプリケーションを維持する方法
- カラム名の変更、型またはデータ解釈の変更、大規模なバックフィル、リレーションシップテーブルの変更、インデックスや一意性の変更への対応
- 一時的な二重経路、追加のマイグレーション、検証作業、クリーンアップの延期などのトレードオフの説明
- 設計方針が明確になった後、Spring Boot、Quarkus、または Micronaut の Flyway スキルにフレームワーク固有の実装を引き継ぐ方法
制約
Parallel Change をデータベース移行の設計パターンとして使用し、必要に応じて実装の詳細をフレームワーク固有のマイグレーションスキルに引き継ぎます。
- 必須：Parallel Change のガイダンスを適用する前に
references/055-design-parallel-change.mdを読む - 必須：Parallel Change を推奨する場合、expand、migrate、contract をそれぞれ独立したデプロイ可能なステップとして説明する
- 必須：フレームワーク固有の Flyway 実装の詳細を推奨する前に、Parallel Change が必要かどうかを判断する
- 必須：変更が追加的で、すぐに安全に適用でき、旧バージョンと新バージョンのアプリケーションを共存させる必要がない場合は、よりシンプルな単一のマイグレーションを推奨する
- 必須：選択したアプローチの互換性、データ保全、検証、クリーンアップに関するトレードオフを説明する
- 必須：移行戦略を選択した後、Spring Boot、Quarkus、または Micronaut の実装の詳細には、フレームワーク固有の Flyway スキルを使用する
このスキルを使用する場面
- このデータベース移行に Parallel Change を適用する
- このスキーマ変更で expand migrate contract を使用する
- 安全なカラム名変更のマイグレーションを計画する
- ダウンタイムなしの安全なデータベース移行を計画する
- この Flyway マイグレーションで Parallel Change を使用すべきか判断する
- 安全なバックフィルと contract マイグレーションを設計する
- このスキーマ変更に互換性ウィンドウが必要か判断する
ワークフロー
- 移行リスクを分類する
references/055-design-parallel-change.md を読み、移行によって影響を受けるスキーマの形状、データの意味、アプリケーションの読み取り／書き込み経路、ロールアウト期間、ロールバックの想定、本番データのリスクを特定します。
- Parallel Change とシンプルなマイグレーションのどちらかを選ぶ
旧バージョンと新バージョンのアプリケーション、またはデータの解釈を共存させる必要がある場合は、Parallel Change を推奨します。変更が追加的で、小規模かつすぐに安全に適用でき、互換性ウィンドウが不要な場合は、よりシンプルな前進のみのマイグレーションを推奨します。
- Expand、Migrate、Contract を設計する
Parallel Change では、expand、migrate、contract を独立してデプロイできるステップに分けます。expand と migrate の間は旧形式を有効な状態に保ち、デプロイ済みのすべてのコードとデータが新しい形式に移行した後にのみ contract を実施します。
- 検証と運用を計画する
旧リリースのフィクスチャチェック、行数の想定、重複検出、バックフィルの監視、ロールバックの動作、クリーンアップの責任者を定義します。可能であれば、本番用の SQL 方言を使ったマイグレーションテストと、本番環境に近いデータサンプルを優先します。
- フレームワーク実装を引き継ぐ
戦略が明確になった後、フレームワーク固有の Flyway 依存関係、設定、マイグレーションの配置場所、テストについては、313-frameworks-spring-db-migrations-flyway、413-frameworks-quarkus-db-migrations-flyway、または 513-frameworks-micronaut-db-migrations-flyway を使用します。
- 移行計画を報告する
選択したアプローチ、採用しなかった代替案、expand／migrate／contract の順序またはシンプルなマイグレーション、検証の根拠、クリーンアップの開始条件、トレードオフ、省略したチェック、残るリスクを報告します。
参考資料
詳細なガイダンス、例、制約については、references/055-design-parallel-change.md を参照してください。