11

のデータベースが3つあるとします。

  • 製造
  • 演出
  • 開発者

私の知る限り、ステージングデータベースは本番データベースと同期している必要がありますが、

開発中は、 Devデータベースでやりたいことが何でもでき、スキーマを変更できます。さて、ここに鶏が先か卵が先かという問題があります。

ステージングでテストするには、Devデータベースで行われた変更に応じてステージングデータベーススキーマを変更する必要があります。ただし、ステージングデータベースは本番環境と同期している必要があります。

どうやってこの問題を回避しますか？

4

5 に答える 5

9

特定の順序で実行される SQL 移行スクリプトとして、すべての変更を dev データベースに書き込む必要があります。スクリプト内でない限り、データベース構造を変更しないでください。スクリプト内にない限り、行を更新、挿入、または削除しないでください。

理想的には、見つけたデータベースの任意のバージョンに対して実行されたスクリプトを追跡する方法を用意してください。

その後、次のようにステージを更新できます。

  • 本番データベースのダンプ
  • 本番ダンプをステージ・データベースに移入
  • 段階的に移行を実行する
  • 移行が機能したことを確認する (単体テスト、手動チェック)

すべてが機能したら...

  • サーバーにバックアップを保持する mysqldump コマンド (変更されている可能性があるため) を使用して prod データベースをダンプします。
  • prod で移行を実行する
  • テスト移行は製品で機能しました
  • ビールを飲む（エラーログを見ながら）
于 2009-01-16T22:48:47.633 に答える
5

ステージングは​​、新しい変更をデプロイする時点までのみ、本番環境と同期する必要があります。

または、新しいアップグレードが検証されるテストと呼ばれる4番目の環境を作成します。これをUAT/Testと呼びます。これは通常、ステージングサーバー上の2番目のデータベースです。

正確な方法論は、物事の同期をどのように維持しているかによって異なります。実際にレプリケーションを使用していますか？それとも、Prod to Stageのバックアップ/復元だけですか？

于 2009-01-16T18:54:00.070 に答える
1

「ステージングデータベースは本番環境と同期している必要があります」正しくありません。

本番スキーマ（「設計」）はステージングスキーマと同期しています。ステージングが最初に来て、生産が続きます。

テストを支援するために本番データをステージングに移動することもありますが、業界によっては危険な場合があります。

ステージングは​​「純粋」です。

本番環境は、実際のデータを純粋なステージングスキーマに配置することにより、ステージングから構築されます。

一部の人々は2つのデータベースを持っています。

今日、＃1はプロダクション、＃2はステージングです。

明日はスキーマを変更する予定です。＃2を新しいデザインにアップグレードします。次に、データを＃1から＃2に移動します。

次に、データの移動が完了したら、アプリケーションソフトウェアを切り替えて＃2を本番環境として使用します。

次の変更の時間になるまで、本番環境として＃2を使用して実行します。

于 2009-01-16T18:56:25.480 に答える
1

ステージングデータベースは、展開メカニズムをテストするためにのみ使用します。生産にマッチします。

開発で変更を作成し、定期的にQAに展開します。本番環境に移行する準備ができたら、すべての変更を1つのリリースパッケージに集約します。そのリリースパッケージは、最初にステージングでテストされ、展開の問題がない場合は、本番環境にプッシュされます。

于 2009-01-16T18:57:17.133 に答える
1

テスト環境を追加する余裕がある場合は、それを検討することをお勧めします。

それ以外の場合は、基本的に開発環境でテストを行う必要があります。ステージング環境でスキーマを変更できるリリースに十分な自信があるところまで。スキーマの変更をステージングにプッシュするときに問題が発生した場合にいつでもロールバックできるように、頻繁にバックアップを作成し、適切なロールバック手順を実行してください。

また、データベーススキーマを比較するための優れたツールはSqlCompareです。スキーマの変更をプッシュする前に、常にこのようなものを使用する必要があります。

于 2009-01-16T18:58:22.357 に答える