So transitioning from the development/deployment approach of
Have DB under Source Control and have deployment pipeline for specific versions of the DB
Have Web App/API under Source Control and have deployment pipelines for these;
and then have dependencies of the Web APP/API on DB Versions - hence to add a new DB change for example we have to do a DB release; before we do an APP release - and the DB change has to not 'break' the old app - and then we can upgrade the App to use the new DB Change
Whilst painful - this works; it also works when you have N Servers for the web app (horizontal scale) with a suitably SINGLE DB Server.
Now working towards EF Core 3.1 Code First using Data Migrations. All working as expected one a single web app with single DB.
But - if this was deployed to N Web Servers, again with a single DB instance; Then.....
"IF" Web Servers upgraded one at a time then then Data Migration would occur on the start up of the first "new" app - and potentially the old web apps would continue to work (depends on the changes)
The above isn't really my concern; it's
If you have simultaneous deployment over multiple web app servers and these apps start at the same time; then I imagine the Data Migrations would be attempted all at the same time.... meaning one of them must fail.
So: $64,000 Question - how do people deal with the horiztonal scale out of Web app with Single DB Server with EF Code First Data Migrations?
Is it "just be careful with your changes"?
how do people deal with the horiztonal scale out of Web app with Single DB Server with EF Code First Data Migrations?
Applying migrations at runtime is suitable only for dev and simple production deployments.
The most common pattern here is to generate the database change scripts (perhaps using Migrations, perhaps using a database-oriented tool like SQL Server Data Tools), review the changes for backwards-compatibility and ability to be applied online, and deploy them first.
Related
We have a typical administrative app that was written in C#. This app maps to a SQL server database that is shared with our customer portal. The customer portal is managed by a separate dev team and is constantly being updated via migration scripts (Fluent - NHibernate).
The problem is that the devs of the admin app are refreshing the entity framework definition against dev all the time which makes it undeployable to production until the other team has deployed its migrations (which have priority). In fact, at any given time the dev database will not look like production at all.
The worst problem occurs when new fields are added to the shared database by the customer portal team. The admin app team then refreshes their entity framework mappings from dev, which makes it undeployable to the other environments. This means that quick fixes to the admin tool can't be deployed independently and when needed.
Is there a way to properly manage this with Entity Framework? Are the devs of the Admin app not using Entity Framework correctly in this case? Keep in mind that our customer portal does not use EF and the DB migrations to the portal have priority. Should we use a different ORM?
I'm using an orientdb server for developments. Work great. Has classes, about to add support for files, etc. I'm about to provision a server on Azure for orientdb for testing by external people.
Question is
What is the database migration plan as in how to move data between the test database and the development database? Currently, it is just data but soon files will be added. coming from EF background
you can simply make a copy of db folder from test instance to develop.
Alternatively you can do an export (in.gz format) from test and then import in develop
I have a team developing a web application using EF. They all have local copies of their DB, as well as there being a central DB for a published version of the app. Some of the devs, and the CI server, have built their initial DB from a later version of the model than others, and so when they run Update-Database or the migrate.exe tool, they get errors when running migrations they don't actually need.
Other than blowing away all DBs and starting over, what's the best way to get everyone on the same page migrations-wise? Can migrate or Update-Database be told to mark migrations as being applied even if they fail, and continue?
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 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.