I would like to know what would be the best guide to follow and things to consider if i would want to Add Migrations to a Project and note that the project:
is live (dev/staging/production environments)
Model of the live versions has changed and some fields/tables are
removed/added
is hosted with Azure App Service (Publish settings)
is an MVC project with Entity Framework 6 using code first
I know the basics of adding/using migrations but that's it.
I would like to know how i can implement migrations to my solution, publish the new project (changed model) without losing any data.
Is this possible and can anyone suggest me anything to look at that is well explained for this kind of setup?
EDIT
I am testing this on development but i can't make it work without having my database recreated, hence losing existing data...
My configuration file:
public Configuration()
{
AutomaticMigrationsEnabled = true; // tried false as well
ContextKey = "ContractCare.Models.ApplicationDbContext";
AutomaticMigrationDataLossAllowed = false;
}
Kind regards
Add an empty snapshot migration to your DEV environement. This will capture the current state of that model:
enable-migrations
Add-Migration InitialBaseline –IgnoreChanges // Tells EF not generate Up() code of existing objects
update-database
Now all subsequent changes in DEV can be deployed to other environments either by changing the connect string and re-running or by generating a script that can be run on those servers update-database -Script.
Before that, you have to "catch up" the other environments to the state of DEV using the processes you already have in place. Then you apply the InitialBaseline migration to those environments.
Moving forward you can apply the DEV migrations to UAT, STG and eventually PROD. Since a lot of migrations tend to happen in DEV, you can roll those up into a single migration as Chris explains here.
Related
I used the migration utility to migrate schema and data from my dev environment to my test environment. In doing so, the default dev business units were migrated to test. How do I wipe that business unit that got migrated?
I’ve wiped out every dependency I can think of. Only problem is that the dev default team got migrated as well. Can't change that to correct business unit and can't delete it.
You can rename that BU & team to match your expectation. We need to keep the BU & Team records guid in sync across environments. That’s why we are migrating the data using utility, otherwise we can create them manually & create confusions/issues like WF not activating after solution import during deployment.
For example if your Dev BU & team has some naming convention different than Test instance - then you may rename it.
I want to understand how people are handing an update to a production app on the Parse.com platform. Here is the scenario that I am not sure about.
Create an called myApp_DEV. The app contains a database as well as associated cloud code.
Once testing is complete and ready for go-live I will clone this app into myApp_PRD (Production version). Cloning it will copy all the database as well as the cloud code.
So far so good.
Now 3 months down the line I want have added some functionality which includes adding some cloud code functions as well as adding some new columns to the tables in the db.
How do I update myApp_PRD with these new database structure. If i try to clone it from my DEV app it tells me the app all ready exists.
If I clone a new app (say myApp_PRD2) from DEV then all the data will be lost since the customer is all ready live.
Any ideas on how to handle this scenario?
Cloud code supports deploying to production and development environments.
You'll first need to link your production app to your existing cloud code. this can be done in the command line:
parse add production
When you're ready to release, it's a simple matter of:
parse deploy production
See the Parse Documentation for all the details.
As for the schema changes, I guess we just have to manually add all the new columns.
I searching for an way to do a different migration in production and development.
I want to create a Spring Webapplication with Maven.
In development i want to update database schema AND load test data.
In production when a new version of the application is deployed i want only change the schema and don't load test data.
My first idea was to save the schema update and insert statements into different folders.
I think every body has solved this problem and can help me, thank you very much.
Basically, you have two options:
You could use different locations for your migrations in your flyway.locations property, i.e.:
for Test
flyway.locations=sql/structure,sql/test
for Production
flyway.locations=sql/structure
That way, you include your test data in the sql/test folder. You would have to take care with numbering, of course.
The second option (the one I prefer), is don't include test data in your migrations at all.
Rather, create your testdata any way you want and create an sql-dump of this data, which you keep separate from your migrations.
This works best if you have a separate database (instance, schema, whatever) containing your pristine testdata, where you apply each migration as part of your build process. This build job could then create a dump always matching the current migration.
When preparing your test machine, you first apply your migrations, then you load the contents of the matching dump.
I think this is a lot cleaner than the first version, especially because your test data can be prepared using other tools (your application) and has not to be handcoded.
I've just started learning .NET MVC so this may be a silly question, but I've yet to find a good answer.
I'm following the Code First approach using the Entity Framework to build my database for me. I've included the following in my Application_Start() method in order to allow me to edit my database by making changes to my Model objects.
Database.SetInitializer<ContactManagerDB>(new DropCreateDatabaseIfModelChanges<ContactManagerDB>());
I was just wondering what would happen if I pushed this application to a production environment and then made a few changes to my models and then updated the application? Would this really drop and recreate the database in the production environment?
What's the best practice for pushing changes to production env. using the Code First approach?
DropCreateDatabaseIfModelChanges should only be use early on in development, never on a production machine. If you pushed to a production machine and made schema changes, you'd loose all your data.
You could delete the EdmMetadata table in your production environment. In that case, EF would not know the current schema to compare to the new, so it would just assume you know what you are doing and it would not touch the database schema.
Code first does not have the ability to upgrade your database while keeping your data intact.
I'm starting an ASP.NET MVC project using SubSonic 3 ActiveRecord. I added a table Users with a primary key ID and recompiled T4 files to generate User class.
I want to make sure that, as I go along with the development, I can regenerate/migrate the database at any point. It looks like I have to create tables and relationships in the database, regenerating ActiveRecord classes and doing migration as described in http://subsonicproject.com/docs/3.0_Migrations. The old 2.x way of defining migrations doesn't seem to be available any more.
Is there a way to drive development from the code rather than database, by changing model classes, and have the database migrated accordingly, without using SimpleRepository? I don't want to put generated code into source code repository, but if I don't, I lose database schema (unless I export and save it manually).
You can still use SubSonic 3 as a DAL and let SubSonic 2.2 generate the migrations for you.
You just need sonic.exe and it's dependencies to execute the migration files.
To be more precise, I have folder Migrations in my DataLayer Project, that keeps all the migration Files but set the BuildAction to none. So I have Syntax Highlighting (but no error checking unless I set BuildAction back to compile) but the code does not mess my project.
You can keep them in an own project, of course. But I like it this way to have it under version control and be sure that my current DAL is matching my migration version.
In addition, I have named my config file migration.config (instead of app.config/web.config) and use this commandline to execute my migrations.
Command: /path/to/sonic.exe
Arguments: migrate /config migration.config
Working Directory: $(SolutionDir)MyProject.Datalayer
Notice the /config switch to override the config file sonic.exe is looking for.
You could have a look at SimpleRepository:
http://subsonicproject.com/docs/Simple_Repo_5_Minute_Demo
The document you linked to does state:
"Bottom line: if you're a developer that is concerned about database design, migrations might not be for you"
I suspect that for the detail of design you want (and I would too), the migrations may not be suitable?