パッケージマネージャーを使用して、 'update-database -verbose'をローカルで実行できます。
おそらく愚かな質問ですが、オンラインで見つけることができません-私のウェブサイトが展開されたら-サーバーでこれを手動で実行するにはどうすればよいですか?
次に、データベース移行を運用環境に展開するために推奨する他の戦略は何ですか?また、どのような戦略が望ましいでしょうか?
ありがとう
いくつかのオプションがあります:
update-database -script
を使用して、サーバー上のデータベースを更新するSQLコマンドを生成できます。/packages/EntityFramework5.0.0/tools/migrate.exe
のパッケージフォルダーにある migrate.exe 実行可能ファイルを使用できます。過去にJet BrainsのTeam City Build Serverで正常に使用して、デプロイスクリプトで移行をセットアップしました。更新:また、 Sayed Ibrahimのブログ をチェックしてください。彼はMicrosoftのMsBuildチームで働いており、展開に関する優れた洞察を持っています。
私は質問がすでに回答されていることを知っていますが、将来の参考のために:
オプションの1つは、DBコンテキストクラスのコンストラクターに次のようなものを配置することです。
public MyDbContext()
{
System.Data.Entity.Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyDbContext, Configuration>());
}
私たちにとって、DBAは実稼働(および実稼働前)環境にアクセスできる唯一のグループです。 Update-Database -Script
パッケージコンソールコマンドを使用して、データベースの更新に必要なSqlを取得するだけです。これは彼らに渡され、そこで検証することができます。
少し単純すぎるかもしれませんが、うまくいきます。
HTH。
簡単な解決策:ローカルパッケージマネージャーコンソールからUpdate-Database
を実行し、接続文字列パラメーターに運用接続文字列を提供します。接続プロバイダー名(このサンプルコードのSqlServer)も提供する必要があります。
Update-Database -ConnectionString <your real remote server connection string here> -ConnectionProviderName System.Data.SqlClient
接続文字列の代わりに、app.configファイルのconnectionStrings
セクションにある接続文字列名を使用できます。
Update-Database -ConnectionStringName <your connection string name here>
ローカルマシンからそのサーバーにアクセスする権限が必要です。たとえば、Sql Server Management Studioからサーバーに接続できる場合、これを使用できます。
このアプローチは実際の実動システムには推奨されないことに注意してください。受け入れられた答えで説明されているようなものを使用する必要があります。ただし、開発用リモートサーバー、テスト環境などでの迅速なハッキングには役立ちます。
個人的には、アプリケーションのstartメソッドが呼び出されるたびに実行される自動移行をセットアップするのが好きです。こうすることで、すべてのデプロイメントで移行を実行し、アプリケーションを自動的に更新するだけです。
AppHarborからこの投稿をチェックしてください。 http://blog.appharbor.com/2012/04/24/automatic-migrations-with-entity-framework-4-
基本的には、自動移行を有効にして、OnModelCreatingメソッドまたはGlobal.asaxのいずれかからコードからDatabaseInitializerを呼び出します。
皆に簡単な答えを与えるためだけです。
これは、MigrationsフォルダのConfiguration.csの「Update-Database」です。
internal sealed class Configuration : DbMigrationsConfiguration<projectname.Models.dbContext>
{
public Configuration()
{
AutomaticMigrationsEnabled = true;
AutomaticMigrationDataLossAllowed = true; // Update-Data -Force (deletes columns etc)
}
そして、最初にリモートサーバーで「移行を有効にする」には、これをGlobal.asax.csファイルに追加します。
protected void Application_Start()
{
....
System.Data.Entity.Database.SetInitializer(new MigrateDatabaseToLatestVersion<dbContext, Migrations.Configuration>());
EFコマンド(update-database -script)を使用してスクリプトを取得するか、手動でスクリプトを作成できます。これは、実稼働環境でデータベースを更新する場合の最も重要なことではありません。私にとって最も重要なことは、すべてのスクリプトが正しく実行され、期待どおりにレコードに影響を与えたことを確認することです。私の意見では、運用前環境が必要であり、データベースは運用環境のコピーである必要があります。このようにして、スクリプトを実行し、かなり類似した環境にアプリケーションをデプロイして、問題があるかどうかを確認できます。時々、スクリプトはDEV環境で正しく実行されますが、実稼働環境では失敗します。頭痛を避けるために、運用前環境で運用環境をシミュレートする必要があります。スクリプトに関して、チームに複数の開発者がいる場合、スクリプトを構造スクリプトとデータスクリプトに分類することを好みます。構造スクリプトは、データベースの構造を変更し(テーブルの追加、テーブルへの列の追加など)、データスクリプトはレコードの挿入/更新/削除を行います。また、各スクリプトは依存関係を指定して、間違った順序で実行できないようにする必要があります。テーブルAに行を挿入するデータスクリプトは、テーブルAが作成されるまで実行できません。これが私がしていることです。-実行されたスクリプトを登録するためのテーブルを定義します。例:ExecutedScriptsHistory。 -各スクリプトには番号と名前があります。 -スクリプトが実行された後、新しい行がテーブルExecutedScriptsHistoryに挿入されます。 -スクリプトが実行される前に、その依存関係をチェックします。そのために、スクリプトが実行されたかどうかを確認します(テーブルExecutedScriptsHistoryに存在します)。
スクリプトを実行した後、ExecutedScriptsHistoryを確認してすべてのスクリプトが実行されたかどうかを確認できます。この戦略は、MicrosoftがEF Migrationで選択した戦略と似ていますが、完全に制御できます。