I'm faced with this scenario: I want to release my software into production on Azure, but there's a code-first database migration that must be applied at the same time to an Azure SQL database. During the time that new software version is pushed without the new database schema (or vice-versa), there will be a period of time that software will throw the exception The model backing the 'BlogContext' context has changed since the database was created..
My software is deployed upon pushing git commits to a branch using continuous integration in Visual Studio Team Services, so I really need a way to run update-database at the same time.
It appears this can be done using a manual publish from Visual Studio by checking the Update Database box (below), but I need this to be automated.
If you do not care about the data just drop the dbo.__MigrationHistory table
Hope this helps.
Can you take direct control over the deployment process (Team Services can help, or Octopus, Jenkins, others)? If so, deploy the database ahead of the code. That's how I would do it if I wasn't using Entity Framework. I would assume the same even with Entity Framework.
An entity framework context is initialised, by default, using CreateDatabaseIfNotExists<TContext>. If the database schema is different than the EF model, then error The model backing the 'BlogContext' context has changed since the database was created. will be triggered.
By adding to your db context contructor Database.SetInitializer<context>(null); the model error will not be triggered. This means you can deploy schema changes to production, without causing model errors, ahead of the new version of the application being deployed that contains the new db context, which equals no down-time.
Make use of an appSetting so that production code will use the null initializer.
Related
I have 2 databases, development and production.
I added a new entity, added a migration then updated the development database.
It worked, development database has the new table.
I switched the database in my configuration to the production database.
I used Update-Database command from Package Manager Console but nothing happened.
My production database still doesn't have the new table.
What now?
What is the valid workflow for such scenario?
BTW, both databases already contain structure and data. The production database contains more recent data, the development database is one migration ahead.
UPDATE: I tried to revert the last migration on development database, it worked. Then I tried to apply it again on production. Didn't work. It seems like it refuses to apply the same migration again.
OK, I figured it out.
I assumed when I change the runtime profile for production the file appsettings.Production.json will be loaded on migration.
It didn't happen. The migration used appsettings.Development.json instead.
I changed the connection string in my appsettings.Development.json file to the production database and it worked.
It's weird, when I debug the web application it respects the settings. It either uses the development or production settings, as selected in Visual Studio. Migrations just use the development file.
If there's a cleaner way (IDK, tell the Update-Database command to use a different appsettings file), please let me know in comment.
The documentation for Entity Framework says to use migration CLI commands to create a database that doesn't exist yet for our EF model, and sync a database when our EF model changes.
Why do we need to explicitly run CLI commands outside our application in order to handle migration?
Can our applications that use EF implicitly handle migration: create a database if it doesn't exist for our EF model and sync a database when our EF model changes?
I had a little experience with Hibernate before, and I didn't hear about migration then. I might be wrong but left with the impression that applications using Hibernate could handle migration implicitly.
You can do either one you want. If you have a formal DevOps deployment process you would normally deploy your database schema then, and the CLI commands are how you do that with Migrations. You can run the migration in the deployment pipeline, or use the CLI to generate the upgrade scripts and run the scripts in the deployment pipeline.
See
Some apps may want to apply migrations at runtime during startup or
first run. Do this using the Migrate() method. . . .
Warning
This approach isn't for everyone. While it's great for apps with a
local database, most applications will require more robust deployment
strategy like generating SQL scripts.
Apply migrations at runtime
So while you would normally apply migrations at runtime on your private developer database, for deployment to shared environments it't often not the best choice.
I have an Azure website being deployed using the source control deployment and am using EF Code First Migrations to manage my database schemas. Everything is set up and appears to be functioning properly and it deploys without errors, but there are only 4 migrations in my migration table in the database and there should be 5. My application is also throwing the following error when I try to hit the database
The model backing the 'dbContext' context has changed since the database was created. Consider using Code First Migrations to update the database (http://go.microsoft.com/fwlink/?LinkId=238269).
indicating not all of the migrations have been run. Is there somewhere on Azure I can look to see more detailed log files on the deployment and does anyone know why the migrations would run locally but not on azure?
Add this to your db context contructor:
Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyContext, Data.Migrations.Configuration>());
note: change "MyContext" to the name of your context.
So we're using the new SSDT Microsoft released, pretty cool stuff. We are keeping a database project under version control with all the schemas, and an offline database for development and we can later deploy on SQL Azure database. We;re using EF in development, so my question is where would the edmx fit in, should we update the edmx file from the offline database or from the online SQL Azure directly, whats the best practice on this?
I would say that in your case "the production database is the truth", so I would update from SQL Azure. There's no right answer tho really.
Incidentally, in the early betas of SSDT it was possible to have a reference from an EDMX to a SSDT project thus your source code became the truth (which, in my opinion, is preferable) and the EDMX knew it was always working against "the truth". Unfortunately they ditched this feature and there are no signs of it returning.
For the EF to work correctly the EDMX file has to be in-synch with the database you are connecting to. It's hard to answer your question without knowing the development process you follow but I would imagine you use Sql Azure in production and develop against an on-premises database. Therefore one copy of the Edmx file will be used on production server. In the development environment you have a "living" copy of the edmx file that is changed as needed when the local database changes. When you get to the point you when you are ready to ship you deploy your app (include the edmx file) to a production environment that uses Sql Azure.
If, in your development environment, you update the edmx file from the SQL Azure then stuff will break or will not work correctly if the schema of the database in Azure is different from schema of your local database.
I guess I should have thought of this before I started my project but I have successfully built and tested a mini application using the code-first approach and I am ready to deploy it to a production web server.
I have moved the folder to my staging server and everything works well. I am just curious if there is a suggested deployment strategy?
If I make a change to the application I don't want to lose all the data if the application is restarted.
Should I just generate the DB scripts from the code-first project and then move it to my server that way?
Any tips and guide links would be useful.
Thanks.
Actually database initializer is only for development. Deploying such code to production is the best way to get some troubles. Code-first currently doesn't have any approach for database evolution so you must manually build change scripts to your database after new version. The easiest approach is using Database tools in VS Studio 2010 Premium and Ultimate. If you will have a database with the old schema and a database with the new schema and VS will prepare change script for you.
Here are the steps I follow.
Comment out any Initialization strategy I'm using.
Generate the database scripts for schema + data for all the tables EXCEPT the EdmMetadata table and run them on the web server. (Of course, if it's a production server, BE CAREFUL about this step. In my case, during development, the data in production and development are identical.)
Commit my solution to subversion which then triggers TeamCity to build, test, and deploy to the web server (of course, you will have your own method for this step, but somehow deploy the website to the web server).
You're all done!
The Initializer and the EdmMetadata tables are needed for development only.