Let's suppose I want to add a new feature to my ASP.NET MVC application running SQL Server 2008 as a data source. In order to implement this new feature, I need to add a few new columns to existing database tables.
After performing these changes on my development server and implementing the new features, what's the easiest way to perform the same database changes on the production server while deploying the new version of my application? Is there any way to automate this?
Edit: As I just found out, Visual Studio 2008's Server Explorer seems to be able to extract the necessary changes for me by comparing two different database layouts (Right-click database, click on "Compare Schema"). Does this usually cover my requirements or is there any big gotcha when using this feature?
I believe versioning the database using manually generated scripts similar to the approach described by K Scott Allen is well worth the investment in time. But not the automated solution you're asking for.
Red Gate's SQL Compare utility might do it for you if your needs are relatively straightforward. If not, a tool like ER-Win or ER-Studio can handle hard-core schema and migrations.
You should have db and app layer versioning. Period.
If you have version db 1.0 and app layer 1.0 in production all the changes which are performed afterwards for versions 1.1 and 1.1.5 should be "upgradable" via scripts.
All "alter table" , and "alter proc" statements are runnable via scripts.
Or alternatively:
Restore 1.0 db to db_old database. Create the production db from scripts and just copy the data ( if you don't have very complicated database should not be difficult)
Automatic deployment for applayer 1:0.
Yet again for the whole process you must train it in DEV , test in TEST verify it in qa and lately perform it in PROD environment.
Edit: I personally think that If the team is not able smoothly to upgrade from version 1.0 to 1.1 on the same time on DEV - smells like bad design and mix in the responsibilities on what should be on the app layer and what on the db server
Related
We have a SQL Server 2014 database and we are planning to do a blue green deployment to this database so that the downtime for this database can be reduced during the deployment window.
Are there any options that can be leveraged for implementing this solution?
I would advise following approach from BlueGreenDeployment by Martin Fowler:
Databases can often be a challenge with this technique, particularly
when you need to change the schema to support a new version of the
software. The trick is to separate the deployment of schema changes
from application upgrades. So first apply a database refactoring to
change the schema to support both the new and old version of the
application, deploy that, check everything is working fine so you have
a rollback point, then deploy the new version of the application. (And
when the upgrade has bedded down remove the database support for the
old version.)
I'm trying to find out a proper database development process in my applications. I've tried Visual Studio Database projects with Post/Pre deployment scripts (very nice feature), Entity Framework Database First approach (with separate script for each database change placed under source control), and now I'm dealing with Entity Framework Code First approach. I have to say that I'm really impressed with the possibilities that it gives, but I'm trying to figure out how to manage the changes in the models during the development. Assuming that I have the following environments in my company:
LOCALHOST - for each single developer,
TEST - single machine with SQL Server database for testing purposes,
PRODUCTION - single machine with SQL Server database used by clients
Now each time when I'm working on an application and the code changes, it's ok for me to drop and recreate the database each time when I'm testing an application (so for LOCALHOST and TEST environments). I've created proper database initializers that seeds the database with test data and I'm pretty happy with them.
However with each new build when model changes, I want to handle the PRODUCTION database changes in such a way that I won't lost the whole data. So, in Visual Studio 2012 there is the "SQL Schema Compare" tool and I'm just wondering if it is not enough to manage all changes in the database for PRODUCTION development? I can compare my {local} database schema with PRODUCTION schema and simply apply all changes?
Now, I want to ask what's the point of Code First Migrations here? Why should I manage all changes in the database through it? The only reason I can find is to allow to perform all sort of "INSERT" and "UPDATE" commands. However I think that if database is correctly designed there shouldn't be such need to perform these commands. (It's topic for another discussion so I don't want to go into details). Anyway I want to ask - what are the real advantages of Code First Migrations over the Code First + Schema Compare pattern?
It simplifies deployment. If you didn't manage the migrations in code, then you would have to run the appropriate delta scripts manually on your production environment. With EF migrations, you can configure your application to migrate the database automatically to the latest version on start up.
Typically, before EF migrations, if you wanted to automate this you would either have to run the appropriate delta scripts during a custom installation routine, or write some infrastructure into your application which runs the delta scripts in code. This would need to know the current database version, so that it knows which of the scripts to run, which you would normally have in a DbVersion table or something similar. With EF migrations, this plumbing is already in place for you.
Using migrations means the alignment of model and database changes is automated and therefore easier to manage.
I developed a website using EF 4.1 code first,Mvc3 ,Sql Sever 2008 r2, and deployed it.
The database on the host got filled with critical data and it still grows.
Now I want to add new columns to different tables and also add new tables.
Even if I back up my SQL and bring it to the development environment and using base.seed() or even create a script using SQL server management I will lose data and I have tried different way and I couldn't find a way which I wouldn't lose data.
I looked at code first migration and it didn't solve my problem. My team added some tables to database using SQL server management and if I use code first migration it wont pick the changes that occurs manually. someone suggested that using reverse engineering tools that would create code first from database but this also makes many unwanted code.
What is the best way or best practices for changing database using code first approach?
Migrations will help you. You just need to script current database and recreate it in your environment. Then you need to add empty initial migration to use your current database as a starting point. You will then add all new tables and columns and let migrations do their job. Sure there can be problems because you have manually changed the database in the production but that is your team's failure in the first place because it violates code first development approach. If this was supposed to happen you should not use code first approach.
As alternative simply develop new version of your application with new tables and columns, create database from your application in your development environment and use database tools for schema compare either in VS 2010 (Premium or Ultimate) or in another commercial tool like Red Gate Compare. This will be able to create diff SQL script for upgrading old DB schema to a new one.
For EF 4.1 you have the Code First Migrations available as a Nuget-package, that let's you migrate you database as your models change.
As of EF 4.3, Migrations is now included in Entity Framework.
The ADO.NET team has blogged about how to get started with EF 4.3 Migrations.
I have, admittedly, done very little searching on my own, so feel free to insult and/or harass me.
I have two databases that I use, one for development and one for production. In Visual Studio 2010, I have simple overrides that change the connection string based on whether I'm building for Debug or for Release.
Right now, I manually change the database schemas when needed. I've thought about creating scripts, but I'm wondering if there is a better way? Can I create a DB in Visual Studio on my local computer, migrate those changes to the development SQL and then, finally, migrate up to Production so that the schema version matches the release?
Thanks in advance!
.NET 4 | Visual Studio 2010 | MS SQL Server 2008
Are you familiar with Visual Studio Database Edition? It's reason for being is to help you with what you just described. Not only does it allow you to version control your database schema, it allows you to build deployment T-SQL scripts to update a database from one version to another. It has built in schema compare and data compare. I highly recommend it. We use it to version control our database schema and to do deployments. I would never attempt to update database schemas by creating manual scripts anymore.
This used to be a pain in the ass for me. Then I bought this: http://www.red-gate.com/products/sql-development/sql-source-control/
Which, providing your're using a compatible Source-Control solution (such as SVN), you can make changes in one database, commit them, and then update other databases with the same structure.
As Randy mentions, the Database Edition of VS.NET will do this.
I use SQL Delta. It's a third party tool and very well priced for what it does. I've used it for a number of years on extremely large projects (that is the database has hundreds of tables and thousands of stored procedures) and it has never failed us in what it does.
The way I used it is this.
I get it ot produce a blank database
schema as per the development
database.
Move this database over to
the production server
Sync the production database with this database
You can also produce scripts and run the scripts and all of this can be automated.
I have been working on a project and gotten it through the first stage. However, the requirments ended up changing and I have to add new tables and redo some of the foriegn key references in the DB.
The problem I have is my lack of knowledge of dealing with doing this kind of change to a staging then production database once I get the development done on dev database.
What are some strategies for migrating database schema changes and maintaining data in the database?
About as far as my knowledge is on doing this is open up Sql Server Management Studio and starting adding tables manually. I know this is probably a bad way to do it so looking for how to do it properly while realizing I probably started out wrong.
For maintaining schema changes you can use ApexSQL Diff, a SQL Server and SQL Azure schema comparison and synchronization tool, and for maintaining data in the database you can use ApexSQL Data Diff, a SQL Server and SQL Azure data comparison and synchronization tool.
Hope this helps
Disclaimer: I work for ApexSQL as a Support Engineer
You have to have something called as a "KIT". Obviously, if you are maintaining some kind of a source control, all the scripts for the changes that you do in the development environments should be maintained in the source control configuration tool.
Once you are done with all the scripts/changes that you deem certified to move to next higher environment. Prepare the kit with having all these scripts in folders (ideally categorized as Procedures, Tables, Functions, Bootstraps) And then have a batch files that could execute these scripts in the kit in a particular order using OSQL command line utility.
Have separate batch files for UAT/ Staging/ production so that you can just double click on the batch file to execute the kit in the appropriate server. Check for OSQL options.
This way all your environments are in sync!
I typically use something like the SQL Server Publishing Wizard to produce SQL scripts of the changes. That is a rather simple and easy approach. The major downside with that tool is that the produced will drop and recreate tables that are not changed but used by procedures that have changed (and I can't understand why), so there is some manual labour involved in going through the script and remove things that don't need to be there.
Note that you don't need to download and install this tool; you can launch it from within Visual Studio. Right-click on a connection in the Server Explorer and select "Publish to Provider" in the context menu.
Red Gate SQL Compare and SQL Data Compare all the way. Since my company bought it, it saved me tons of time staging our databases from DEV to TEST to ACCEPTANCE to PRODUCTION.
And you can have it synchronize with a scripts folder too for easy integration in a source control system.
http://www.red-gate.com
You might want to check out a tool like Liquibase: http://liquibase.org/
You can use visual studio 2015. Go to Tools=> SQL server => New Schema comparison
step 1) Select source and target Database.
Click on Compare option.
step 2) once comparison completed, you can click on icon Generate Script(Shift+alt+G)
this will generate Commit script.
step 3) To generate rollback script for database changes just swap database from step 1
There are some tools available to help you with that.
If you have Visual Studio Team edition, check database projects (aka DataDude aka Visual Studio Team for Database Professionals) See here and here
It allows you to generate a model from the dev/integration database and then (for many, but not all cases) automatically create scripts which update your prod database with the changes you made to dev/integration.
For VS 2008, make sure you get the GDR2 patches.
We have found the best way to push changes is to treat databases changes like code. All changes are in scripts, they are in source control and they are part of a version. Nothing is ever under any circumstances pushed to prod that is not scripted and in source control. That way you don't accidentally push changes that are in dev, but not yet ready to be pushed to prod. Further you can restore prod data to the dev box and rerun all the scripts not yet pushed and you have fresh data and all the dev work preserved. This also works great when you have lookup values to tables that are chaging that you don;t want pushed to prod until other things move as well. Script the insert and put it with the rest of the code for the version.
It's nice to use those tools to do a compare to see if something is missed in the scripts, but I would NEVER rely on them alone. Far too much risk of pushing something "not yet ready for prime time" to prod.
A good database design tool (such as Sybase Powerdesigner) will allow you to create the design changes to the data model, then generate the code to implement those changes. You can then store and run the code as you choose. This tool should also be able to do reverse engineering when you inherit a database you didn't build.
Finding all the changes between development and production is often difficult even in an organized, well-documented environment. Idera has a tool for SQL Server which will detect structural differences between your development and production database and another tool which detects changes in the data. In fact, I often use these to go the other direction and sync development with production to start a new project.