Using SQL Source Control and Vault Professional Part 4
Two weeks ago I upgraded our installation of Fortress to the latest version, which is now named Vault Professional. This is the version of Vault (i.e. Vault Standard 5.1 / Vault Professional 5.1) that will be officially supported with Red-Gate SQL Source Control 2.1. While the folks at Red-Gate did a fantastic job of working with me to get SQL Source Control to work with the older Fortress version, we weren’t going to just sit on that. There are a couple of things that Vault Professional cleaned up for us, such as improved integration with Visual Studio 2010, so it was a win all around.
Shortly after that upgrade, I received notice from Red-Gate that they had a new Early Access version of SQL Source Control available that included the ability to source control static data. The idea here is that you probably have a few fairly static lookup tables in your system, and those data values are similar in concept to source code, and should be versioned in your source control management system also. I agree with this, but please be wise…somebody out there is bound to try to use this feature as their disaster recovery for their entire database, and that is NOT the purpose. First off, you should never have your PROD (or LIVE, whatever you call it) system attached to source control. Source Control is for development, not for PROD systems. Second, use the features that are intended for this purpose, such as BACKUP and RESTORE.
Laying that tangent aside, it is great that now you can include these critical values in your repository and make them part of a deployment process. As you would guess, SQL Source Control uses SQL Data Compare to create the data change scripts just like it uses SQL Compare to create the schema change scripts. Once again, they did a very good job with the integration to their other products. At this point we are really starting to see some good payback on our investment in the full SQL Developer Bundle. Those products were worth the investment back when we only used them sporadically for troubleshooting and DBA analysis, but now with SQL Source Control, they are becoming everyday-use products for the development team.
I like this software (SQL Source Control) so much that I am about to break my own rules and distribute it to my team to use even though it is still in beta. This is the first time that I have approved the use of any beta software in a production scenario (actively building our next versions of internal software) but I predict that the usability and productivity gain of using SQL Source Control over manual scripting is worth the risk. Of course, I have also put this beta software through its paces pretty well to be comfortable with it, and Red-Gate has proven their responsiveness to issues that came up in my early beta testing, and so I am willing to bet on their continued support. Likewise, SourceGear, the maker of Vault Professional, has proven itself to me as well, and so the combination of SQL Source Control with Vault Professional is the new standard for my development team.