版本控制DDL更改

Question

I'm trying to work out the best way to version changes in SQL. I know that there are products like Redgate and Microsoft's SSDT, but equally I'm wondering if a more manual process might make it easier to automate deployments.

I have the following requirements

• Must be able to produce diffs on table structure
• Must be able to automate changes against the database
• Must be able to blame changes and view commit comments

If I was using Redgate or SSDT, would I need to generate deployment scripts from the current state of the database?

Currently I'm wondering if placing change scripts and a syncronised create script into git/svn would be the easiest way to deliver this. But the likelyhood of the two getting out of sync make me uneasy.

Answer 1

Keeping change scripts in source control is a pain because to get back to a specific point in time you need to run the base create and then all the change scripts + you have to write manual rollback scripts (if you need them)

Writing manual change scripts also is a pain as you have to actual write the scripts and well this is the year 2015 so don't do that!

So I would really recommend using either SSDT or redgate, redgate is cool but SSDT is free and also includes design time checking and refactoring so if you do something like renaming a table in SSDT it will generate a sp_rename rather than dropping the first table and creating a new one (which is what the redgate tool would do)

Whichever you use there are command line version of the tools to do a compare / deploy when you actually want to release so just have the checked in code show the state you want the database to be in when you do the release.

For your requirements, both redgate and ssdt will do all three (except number 3 which is taken care of by having your database represented by create statements in source control)

The only thing you don't mention is static or reference data, to handle this either use the redgate data compare tool or you could possibly use the redgate source control ssms add-in if you are not going to use ssdt which lets you link tables to csv files.

If you are going to use SSDT then use a post-deploy script and have a merge statement for each table you need to store in source control.

SSDT rocks and really is the way forward for anyone developing T-Sql code (even if they don't realise it yet!)

Ed