Development has come a long way over the last several decades. One of the biggest advancements is Source control. But its not just for developers.

Why?

When working as a team on a development project, the best thing you can do is source control your code. This allows multiple people to work on a project without stepping on each other’s toes. It also lets you easily deploy changes and rollback if necessary. Even if you don’t work on a development project as a team, every project should be source controlled. This provides extra protection from losing all your work.

Source control is a method to keep a historical audit of all the changes. It tracks changes not only at the file level, but also across multiple files. You can “check out” the file(s). This action signals to others that you are currently working on this piece of the project. You then “check in” the file(s) when you are done with your change(s). Others can update their working copy of the files you changed. This way, they will have the newly updated version of the project. You can check in/out your database changes with your procedural code. This keeps your database up to date with your application code. This process allows for easier deployments, rollbacks, and hot fixes.

Source control is not only good for developers. I would highly recommend it for DBAs, as well. This holds true even if you are the sole DBA at your company! Every DBA should have a “DBATools” database on every server where they store their procedures, tables, etc in order to do maintenance or just recurring work. This DBATools DB should be source controlled so you can easily deploy it to new servers, deploy changes to all the servers across your environment, or roll back changes if something goes haywire. To the observant reader, yes, these are all the same exact reasons as developers should use source control. And finally, as your team grows, source control allows the DBAs to not step on each other’s toes, as well.

How?

There are many different options for you to source control your objects to — TFS, SVN, Git, etc. You can now get an account on GitHub with unlimited private repositories. You can also get a free account and have unlimited public repositories. Although, I’d only do this for any code you want to share with the world (who knows, maybe the next Brent Ozar or Ola Hallegren is reading this!)

To source control your DB objects, you need to script the objects out as create statements. Then, manually check them in and out of your repository. This process can be difficult. But, if you rarely make changes to your DBATools DB, this is a possible solution.

If you want something that is built into SSMS, you can roll a free native SSMS source control tool. Those who have developed in Visual Studio will be right at home with the Team menu. Some DBAs have never dabbled in VS, so there may be a steep learning curve. If you have the budget, you may want to go with a 3rd party tool. If you have a team of 3 DBAs, you can apply for 3 licenses of Apex Source Control for free. You just need to fill out a survey. Another tool that I’ve used and highly recommend is Red Gate’s Source Control. It costs $495 per license. This is a great investment if your team does a lot of development.

But the most important take away here is to start source controlling your work. It will be invaluable as you move ahead and your team/company grows. And, who knows, it may just save your bacon a time or two.

Do you currently source control your database objects? If so, leave a comment below with what you use or what recommendations I may have missed!