What is an easy way to deploy database changes using SQL Server?

Question

The software system I work on is a medical billing system, large amounts of data and data tables, and stored procedures.

I was reading the article "12 Steps to Better Code" and in The Joel Test #2 states: Can you make a build in one step?

Now I was wondering, does this mean deployment build (so that a customer can update their deployment).

Now the main issue I'm running across, is how do you do a one step database update?

At the current time, when we make changes to a database, all changes are recorded and added to a database update script, which gets a version number attached to it when a deploy to customer build is created.

Is there a simpler way to do this? Some script or application out there that takes a "before and after" look at a database schema and creates an update script like I mentioned?

Or is this just the way everyone does it, which I would find hard to believe, but plausible.

An automated system would decrease errors, and speed up deployment build times considerably, and I would be interested in knowing how to do so.

Answer 1

There's various levels of complexity that you can go through:

• if you have update scripts that you create manually, and are just looking for a way to easily apply those to various servers, check out the SSW SQL Deploy by SSW Consulting. It can handle that scenario very nicely

• if you tend to do more of a database diff approach, then Red Gate's SQL Compare (already mentioned) and SQL Packager make a great combo. You can diff the database between old and new and then apply the changes in a nice package - as an EXE or a C# project

• if you want a real, end-to-end, well thought out approach (with a bit of a learning curve), check out Innovartis' DBGhost approach. It's a entire methodology / technique how to handle database development and incremental updates. It's very powerful and look very promising - but it's a bit of an all-or-nothing approach: either you buy into it and use it end-to-end, or you don't

Hope this helps a bit!

Answer 2

redgate has a tool SQL Compare to compare databases and generate a script to synchronize. We used to use it but more recently switched to manual scripts using the same process you describe. Using manual, fine grained, scripts with a unique version number has worked out well.

We have our upgrade scripts integrated into unit tests so they get tested along with code as part of continuous integration. I think this is an important part to "making a build in one step."

Answer 3

Take a look at this blog post. I've used this type of single update script from any DB version on a couple projects and it works pretty nicely.

http://blogs.msdn.com/danhardan/archive/2007/03/30/database-change-scripts-mambo-style.aspx

You may have to tweak the workflow a bit to fit your workflow and/or update the template .sql file, but overall I've found the idea to be a pretty solid approach to DB deployments.

EDIT: Just to elaborate on how I've used this technique. Basically, all of my DB revision scripts get put into source control. Then, as a post build step on the build box, this Mambo tool is run on the scripts directory to roll the scripts into a single script encompassed by a transaction to allow for rollback if anything goes awry. Then, the installer is smart enough to look for the .sql script to run against the existing database.

The reason this works is because the rolled up script checks to see each piece that was an individual script has already run against the desired database. As a result, only the latest scripts get run. A caveat to this is that once a script is checked into source control and has been deployed, you cannot edit it since the tracking table already thinks the script has been run. That's fine for the projects I've worked on because we just add another script to the scripts folder.

Hopefully I'm explaining the process well enough to understand. It's really not that complex and can be quite useful if the approach is applicable to your project.

Answer 4

Answer to first question of "Now I was wondering, does this mean deployment build (so that a customer can update their deployment)?"

I believe the Joel Test #2 is not for deployment moves to prod, but for continuios intergration during the development.

As for database changes in prod, they should all be done through a script as part of a transaction rollout or after the database has been backed up. You always want to be able to navigate back should something fail in the rollout.

Answer 5

Develop your database as a set of patches that depend on eachother. Then use a tool like https://github.com/LuvDaSun/sqlpatch (by me) to build an sql file for deployment.

sqlpatch will sort the patches in the right order and make sure that every patch is executed exactly once, even if the same script is run twice.

This strategy can be used for deployment of your database in a ci/cd environment. This make deployment as easy as pushing to a branch.

Answer 6

There are applications that sync databases, but I think your better off doing what you are doing. Writing a script to update a database gives you the ability to handle errors and run transactions. This is considered best practice.

Answer 7

Microsoft themselves introduced Data-tier applications in SQL 2012 as a free option for deploying and upgrading databases.

I use and like this tool, including for production deployments.