A Practical Approach to Version Control


Chances are, your team has several point-in-time backups for your databases. After all, they’re essential for recovering the system in an emergency. And, chances are, you’ve got a version control system (VCS) to provide the same capabilities for your applications.

But what about version control for the database, too?

Come to this session to see how you can create a more efficient database development platform by integrating your VCS with SQL Server. In real-time, you’ll see how versioning, branching, merging, and the other manual tasks you hate can fade away with just a few tips, tricks, and tools.

Level: 200


I’ve built these demos:

  • Connecting your database to a version control system. I use Git here, but can use SVN (or TFS online with connectivity)
  • History and Changes – Getting a few of the changes made over time, tracking to a user, undoing changes.
  • Object Locking – Using Redgate’s SQL Source Control, but explaining how a semaphore is needed
  • Branching – A look at creating a branch in Git and then working with a second database.


Powerpoint: SITC15_SteveJonesPracticalVCS.pptx

Get Away from the Heat and Learn some Database Version Control

I have enjoyed the trips I’ve made to New Orleans and Baton Rouge in the past. It’s a good getaway, stopping in the French Quarter for a few minutes before an easy drive up the road. However it’s warm, and I can’t ever get my wife or kids to come with me. For some reason, they don’t seem to enjoy the warm, August Baton Rouge weather. I, however, am looking forward to a jog around University Lake.

LSU University Lake at BREC Milford Wampold Park

This might be the best time to run, but I’ll likely be going around when it’s sunnier, and a touch warmer.

However if you want to get out of the heat, perhaps you’d like to come learn about Database Version Control with Ike Ellis and me? Redgate Software has partnered with Crafting Bytes to deliver our workshop in Baton Rouge. We’ve put the workshops on sale, and only $100 for a full day of training.

What will we cover?

We’ll show you how to get your database in a Version Control System (VCS). We use Redgate’s tools, but the idea of using version control can be done in other ways. I’m running the labs, and you’ll see how you can keep track of all of your database DDL code, including Lookup data!

2015-07-23 18_45_53-DLM-Workshop-2015-02-19-1708-export-i-fg1k1eq0 - VMware Workstation

We are also covering some advanced features that the Redgate tools make easier. Things like branching, merging, and deployments. How many of you would love to know that development is done and we can deploy our changes like this:

2015-07-23 17_14_22-Schema Compare_Deploy - Microsoft SQL Server Management Studio

I’ll show you how you can deploy your changes right from inside SSMS.

This is an in-depth workshop, covering way more than I could ever do at a SQL Saturday or conference. What’s more, we provide you with a VM and let you actually work through the skills we teach you. You will get real practice during the day to give you the confidence and practice for your own environment back at the office.

I hope to see you at either the workshop or SQL Saturday #423 in Baton Rouge.

Starting with Git for Database Development

One of the tools that Red Gate Software makes is SQL Source Control. It’s a plug in to SSMS that allows you to hook your database up to version control. I’ve used it a few times in the past in conjunction with Subversion to demo the product. However I hadn’t really used it for my own scripts since it’s primarily a single server system and not distributed. My own demos were on VMs with limited connectivity to the world.

A few weeks back, I was flipping through the https://www.simple-talk.com/Simple Talk newsletter, and saw an article on Continuous Integration for SQL Server using Red Gate Tools, Atlassian Bamboo, and Github. I’ve had many people over the last few years ask me about Git support for SQL Source Control and I was curious to see how well we supported things. I read the article and started downloading things.

The first thing I downloaded was GitHub for Windows. I installed it and wasn’t thrilled to see it not working. However what was unclear in the article and the installation was that this is just a GUI for your Git installation. Since I hadn’t installed Git, I needed to do that. Once I had done that, and set up a Github account, things worked fine.

I have numerous databases that I use for talks, but I usually create and destroy them with scripts during the talks. Not quite the way that SQL Source Control is designed to work. It works with objects, not scripts. However I wanted to test things, so I decided to build a database with the objects in it already. I wasn’t sure this would work for demos, but it would be a good test.


As you can see above, there are a few objects in my database.

My next step was to pick a place on my local drive where I could store my Git data. Since I do a lot from Management Studio, and use quite a few VMs, I wanted a standard location I could use easily and chose a folder under my SSMS installation.


Once this was setup, I created a new repository on my drive.


This was the place I’d keep all my code. With a free GitHub account, you can’t keep your code private, but that’s OK for this project since I give all my code away after talks.

Once I’d created this, Git put the folder on my drive.


Inside the folder was nothing, just a few Git files.


And in my Github interface, there was nothing to commit.


The next step was to link this with Git. After selecting my database in the Object Explorer, I switched over to the SQL Source Control tab to link my database to source control. I entered the path of my Git folder (from above) and selected Git as my VCS.


I chose a dedicated database, meaning this is just my database. The Shared database model can work, but I don’t like it for teams, or even solo.

Once this was done, I could see my database linked in SSMS.


I clicked the “Commit Changes” tab, and could see my three objects listed there as new items to commit.


If you have an existing database, this is the situation you’ll find yourself in most of the time. You link it, and commit all the changes. Once you enter a comment (please enter real comments you’ll understand), and press Commit, the objects are added to your folder. If I look at the folder, I see more stuff:


Only a few folders have objects, and those contain the .sql files for those objects.


If I look at Github, I see my comment and the changes are committed, but unsynced. If I press the “publish” button at the top, these are sent to Github.


That’s it. Any changes I make to objects, which I’ll show in another post, will commit to Git, and I can sync them to GitHub.

Come learn more about these topics on the SQL in the City 2013 tour.