この問題には2つの部分があると思います。
1つは、データベーススキーマの管理であり、その変更です。これはSouthを使用して行い、作業モデルと移行ファイルの両方をSCMリポジトリに保持します。安全性（またはパラノイア）のために、移行を実行する前に（そして、本当に怖い場合は、後で）データベースのダンプを取ります。サウスは、これまでのすべての要件に十分対応できました。
2つ目は、Southによって生成された移行ファイルを実行するだけでなく、スキーマ変更をデプロイすることです。私の経験では、データベースを変更するには、通常、デプロイされたコードを変更する必要があります。小さなWebファームを使用している場合でも、デプロイされたコードをデータベーススキーマの現在のバージョンと同期させることは簡単ではない可能性があります。これは、さまざまなキャッシュレイヤーと、すでにアクティブなサイトユーザーへの影響を考慮するとさらに悪化します。サイトが異なれば、この問題の処理も異なります。万能の答えはないと思います。
この問題の2番目の部分を解決することは、必ずしも簡単ではありません。万能のアプローチがあるとは思いません。また、Webサイトと環境に関する十分な情報がないため、状況に最も適したソリューションを提案できません。ただし、ほとんどの状況で展開をガイドするために留意できる考慮事項がいくつかあると思います。
サイト全体（Webサーバーとデータベース）をオフラインにすることは、場合によってはオプションです。これは確かに、更新を管理するための最も簡単な方法です。ただし、頻繁なダウンタイム（計画されている場合でも）は、ビジネスを迅速に進めるための良い方法であり、小さなコード変更でも展開するのが面倒であり、大規模なデータセットや複雑な移行がある場合は数時間かかる場合があります。とはいえ、私が管理を支援しているサイト（すべて内部にあり、通常は営業日の営業時間中にのみ使用されます）の場合、このアプローチは驚異的に機能します。
マスターデータベースのコピーに変更を加える場合は注意してください。ここでの主な問題は、サイトがまだ稼働していて、おそらくデータベースへの書き込みを受け入れていることです。後で使用するためにクローンを移行するのに忙しいときに、マスターデータベースに書き込まれたデータはどうなりますか？サイトは常にダウンしているか、一時的に読み取り専用状態にする必要があります。そうしないと、サイトが失われます。
変更に下位互換性があり、Webファームがある場合は、ライブの本番データベースサーバーを更新してから（ほとんどの状況で避けられないと思います）、ファーム内のノードを段階的に更新することで、ノードを削除できる場合があります。短期間のロードバランサー。これは問題なく機能しますが、ここでの主な問題は、すでに更新されているノードが古いノードでサポートされていないURLのリクエストを送信した場合、ロードバランサーレベルで管理できないため失敗することです。
私は他のいくつかの方法がうまく機能するのを見たり聞いたりしました。
1つは、すべてのコード変更を機能ロックにラップすることです。機能ロックは、サイト全体の構成オプションを使用して実行時に構成できます。これは基本的に、すべての変更がオフになっているコードをリリースし、サーバーに必要なすべての更新を行った後、構成オプションを変更して機能を有効にできることを意味します。しかし、これはかなり重いコードになります...
2つ目は、コードに移行を管理させることです。コードへの変更が実行時に移行を処理するように記述されているサイトについて聞いたことがあります。使用されているスキーマのバージョンと、返されたデータの形式を検出できます。データが古いスキーマからのものである場合は、その場で移行を行い、データがすでに新しいスキーマからのものである場合は、何もしません。 。自然なサイトの使用から、データの大部分はサイトを使用する人々によって移行され、残りはいつでも移行スクリプトを使用して実行できます。
しかし、この時点でGoogleがあなたの友達になると思います。なぜなら、私が言うように、ソリューションは非常にコンテキスト固有であり、この答えが無意味になり始めるのではないかと心配しています...「ゼロダウンタイム展開」のようなものを検索してください。 これ たくさんのアイデアがあります...