Overview:
I am working on
ASP.NET MVC Project with Entity Framework's Code First
approach for the database.
I recently automated the deployment process via VSO pipelines (Build & Release)
Problem:
For Application Deployment it's perfect and working fine.
For Database I am facing issues (explained below).
Details:
I read this, this and this but issues in these solutions are
They are using Publish Profile setting, which would run the migration on application start event, which I don't want (not a best practice though)
For others using Build Pipeline (copying (a) EF tools, (b) Dll's and (c) run migrate.exe via command line to run update-database command), and it will eventually run migrations on Successful Build. I rather want it to deploy changes on 'Successful Release'.
My Work
I moved step (c) from build to release pipeline. But it's not able to find the drop.
Secondly, How to roll back in case of a crash on production?
Can anyone suggest what the best approach to solving this scenario?
In the case of crash on production, you can rollback database to previous version by running update-database -TargetMigration:"Migration_Name"
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 wondering if it is possible to run some automated tasks either on a Release (web deploy) action, or Branch Merge (TFS) action?
Ideally I would like to set up a process that will automatically combine EF migrations since the last release. I'm still looking into how I would automate this, but I think the first step is hooking into a suitable event.
I haven't setup a build server yet, but I'm guessing if the above isn't possible then this would be an option for attaching a custom procedure to the MSBuild task?
Alternatively, if anyone has experience in automating things like this I would be happy to hear it. I am the head of development at a web development company and I would like to facilitate our current processes by automating some of our standard procedures, and this is something we do over any over again for each development!
I appreciate your time looking at my question, thanks.
VSTS and TFS2015 both support a CI/CD process via their new build and release system. Very flexible and powerful. Check it out!
https://msdn.microsoft.com/Library/vs/alm/Release/getting-started/understand-rm
VS/WebDeploy does support deploying EF migrations with a web application:
https://msdn.microsoft.com/en-us/library/dd394698?f=255&MSPPError=-2147217396#efcfmigrations
This works fine for deploying a small application/system but when you want to deploy a larger system with many components it doesn't work as well. We create MSDeploy packages for each component of the system. For example, this is how we deploy SQL databases:
http://dotnetcatch.chief7.space/2016/02/10/deploying-a-database-project-with-msdeploy/
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.