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.
Related
Currently have a release pipeline that runs my migration project in the up direction -
e.g.
The web app project is deployed to the environment
In the Solution we have a fluent migrator project
As part of the release pipeline, we run the up migrations to the latest version
All of the above works great BUT if I want to rollback the web app to an earlier version, then I need to somehow pass into the fluent migrator process the version that I want to roll back to - currently I'm not sure how I would achieve this. It's almost like I would need to know the version that was deployed in the previous release.
Currently, I rollback the web app I have to manually run fluent migrator to rollback to the version of the database I require.
Has anyone fully automated the fluent migrator rollback?
FYI My migration numbers are using the datetime as milliseconds which I get from https://currentmillis.com/
Update:
I had a plan to somehow get the latest migration in the project and use that number as a parameter to either run up to it or down to it. However, after thinking it through, the migrations that run as part of the release only know about the migrations that exist when the code in that release is built. There's no way it would know about any consequent migrations to be able to roll the database back...
I think I would somehow need to pull the latest code, build it and then run down the appropriate migration. I'm not sure this is possible. Might have to stick to a manual database roll back procedure.
A less-than-elegant solution would be to append all migration identifiers to a file that is part of deployment artifacts. This way the forward migration uses the last entry, the backward migration uses the next-to-last entry.
So I have an EF Core project. When I need to add/migrations I issue and update command:
dotnet ef database update -v
This all works fine, if I need to update the QA, Staging, Prod database I update the connection string in my appsettings.json file and run the command.
What happens if I don't have access to production from my local machine? How do you go about updating the database to the latest migration?
If I remember working with Entity Framework (not .net core). It would try and update the database automatically when I deploy a new version of the .net application. Does this functionality still exist in .NET core?
Yes you could run
dbContext.Database.Migrate();
On startup but it is generally not a good idea to conflate database migration with your application lifecycle - best practice is to keep your application start up as fast and simple as possible because an application start failure is hard to diagnose remotely, and a migration would introduce a lot of unwelcome complexity.
The alternative is to run a migration operation as part of your deployment. It depends on what method you use to deploy but say for example you use a CI server, you will be able to run
dotnet ef database update
after copying the new code but before starting the application back up.
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.
I have been following a number of tutorials regarding code-first migrations and am now at the stage where I am ready to deploy to our staging server.
We normally publish web apps to the filesystem and then manually update sites through Remote Desktop (not the greatest I know).
All the tutorials and best practises as far as code first and deployment go seem to be either out of date of specific to Azure deployment.
What is the current best practise for deploying a web app that has been developed with code first migrations (EF6) to a live environment? How then are updates to the live environment handled?
I understand that I can generate scripts using Update-Database but then these do not include any Seed Data. Are scripts the way to go?
Thanks,
You can use DBMigrator update menhod - this will run any pending migrations. The Seed method in your Configuration class will run every time your application starts.
You can also use migrate.exe to run database updates.
I'm using Migrator.NET to manage schema changes on our production environment. Because I've been using EF code-first, all development to the database has been incremental to the code-first classes and no migrations have been applied to the project.
However, I'd like to be able to start using migrations once the project is in a production environment. As the baseline 'up' migration, I'd like to use code-first's database initializer to create the database and prime with default data. However, I'm having problems because the EF context classes and my wrapper classes for EF initializers are in .NET 4, whereas migrator .NET is using .NET 2.
When running the migrator console app, I'm getting 'This assembly is built by runtime newer than the currently loaded runtime...'
Am I expecting to much for this to work? I could use OSQL and create the SQL script on the server, but it would be nice if this worked just as it does in the development environment.
Hmm. Weird. Even if the migratordotnet binary is in .NET 2 you should be able to use it. I worked on a project where we did just this. We used EF Code First to automatically generate the schema if it didn't exist, otherwise we would run the migrations to the existing one (we started creating the migration steps while still in the dev phase).