継続的デリバリーでの本番環境でのリレーショナルデータベース（およびスキーマ）の移行パターンとは何ですか？
多くの従来の開発では、DBAは、現在のリリースサイクルで作成された多くの小さなスクリプトから大きな移行スクリプトを配置します。しかし、CDの場合、開発者は、他のスクリプトでコンパイルするのを待つのではなく、今すぐ変更を本番環境にプッシュしたいと思うかもしれません。
私はrails-migrationで知っていますが、生のsqlスクリプトを使用する方が合理的に見えます。
移行を管理するためのflywayのようなツールも見たことがありますが、本番環境でそれらを使用している多くの人々のことは読んでいません。これが、ここでの一般的な慣行は何であるか疑問に思う理由です。
Flywayは、継続的デリバリー/デプロイに最適です。多くのクライアントは、本番環境を含むすべての環境でこれを使用しています。
環境間でDB移行をカスケードするための最も重要なことは、次の3つのステップのプロセスを持つことです。
ステップ1
古いアプリケーションコードは古いDBと連携して機能します。
ステップ2
新しいアプリケーションコードがデプロイされ、起動時にDBが移行されます。古いアプリケーションコードが新しいDBで引き続き機能するように、この移行には下位互換性が必要です。これは次の理由で不可欠です。
このステップには、互換性ビューとそのジョブを実行するためのトリガーが含まれる場合があります。
ステップ3
変更が機能することが証明された後、アプリケーションコードの次のバージョンが、必要なDB移行とともにデプロイされ、残りの古い（ステップ1から）および互換性（ステップ2から）の構造が破棄されます。
データベースへの変更を単一の（生の）SQLファイルとして実装してから、sqlpatchを使用して移行スクリプトを作成します。
私は通常、データベース専用の単一のgitリポジトリとそれに接続されたCD環境を持っています。私は通常、対応するブランチにプッシュすると自動的に移行される本番データベースと開発データベースを持っています。
この設定により、機能ブランチ用に別のデータベースを設定して実験することが非常に簡単になります。Sqlpatchは、個別のsqlファイルのすべての依存関係を処理するため、機能ブランチを別のブランチに簡単にマージできます。