データベースの移行：ビルドスクリプトで管理するか、アプリ起動時に自動的に管理しますか？

Question

私は新しいWebアプリケーション用のデプロイメントシステムを開発中ですが、データベース移行を管理するプロセスの最善のポイントはどこにあるのでしょうか（移行を行う方法の問題はまったく別の問題です）。

行くには二つの方法があるようです。

1. は、プロセス構築/
2. 実行 が手動でコマンド ラインまたは自動 展開の一部として実行することができるいずれかの移行スクリプトを使用しますが、アプリケーションが の起動時に移行する（私はASP.NETを使用しているので、 は十分に簡単に実行でき、長時間実行されるユーザー要求を引き起こすことはありません）

誰もがこれらのアプローチに関する提案/洞察/経験を持っていますか？その他の提案はありますか？

＃1がもっと魅力的かもしれない理由はわかりました.DBの更新時期を完全に制御できます。しかし、デプロイメント間を素早く反復することができ、手作業を減らすことができるので＃2が大好きです。私の開発マシンで＃2を使用しても、より迅速な反復が可能です。うーん、両者が良いものだと思うようになってから...

Answer 1

私はオプション＃1が好きです。実際に各アプリケーションの移行を実行するのではなく、データベーススキーマ（バージョン番号？）がコードと一致することを確認し、そうでない場合は、データベーススキーマの不一致に関する警告またはエラーをスローします。

Answer 2

〜100のクライアントを持つ販売代理店システムがあり、アプリケーションの起動時にデータベースを更新しています（True、私たちはデスクトップアプリケーションです）。私はこのアプローチが気に入っています。クライアントデータベースが新規か、verison xyzにのみ更新されますか？）。

サーバサイドで私はあなたの＃1オプションを選択しています：オリジナルのデータベースのコピーに基づいて仮想マシン上にSQLクエリファイルを作成し、このクエリを実際のサーバに対して実行します。

ので、私見：

• 切断クライアント：起動、反復スクリプト
• サーバー：VM上で作成クエリが

だから、私は実際に、実際のデータベースに基づいてこの問題にも関わっており、フレームワークのいくつか（半分）はRikMigrationsとなっています。グーグルの中には、DBのバージョン/移行フレームワークについての良いスタートアップがあります：.NET Database Migration Tool Roundup。必然的にドキュメンテーションではありませんが、チームのブログはインタラクティブにすることができます。

Answer 3

いくつかの理由からオプション1を選ぶことをお勧めします。まず、統合テストでは通常、DBスキーマを最新にする必要があり、スキーマをアップグレードするためのWebサイトを立ち上げることは巨大なタイムウォスターとなります。第2に、サイトが稼動している間にデータベーススキーマを変更することはできません（例えば、2つのインデックスを追加して処理速度を上げるなど）。

物事の生産面では、トランザクションMSI形式のインストールでデータベースをアップグレードすると、データベースのアプリケーションのバージョンが非同期になる可能性があるため、各アプリケーションの起動時にアップグレードするよりもはるかに優れています。

移行フレームワークをお探しの場合は、Wizardbyをご覧ください。

Answer 4

起動時に移行するよりもアプリケーションを顧客のマシンで実行する必要がある場合は、多くのサポート呼び出しを防ぐことができます。ユーザーの介入なしにシームレスな移行を行うことができると仮定します（通常、データベースを変更する）。

アプリケーションが常にあなたのコントロール下で動作する場合、自動移行はそれほど問題にはなりませんが、特にダウンタイムや手動展開のステップを最小限に抑えたい場合には、優れた機能です。