How many times have you heard “it worked before the last release”?  How many of those times was it due to a database change?  Probably more times than you would like to admit.  Source control can change your life.

Source control implies storage and version control of your code.  The proper use and management of source control is beyond the scope of this post, however standards and management of source control is just as important as standards and management of application code so I encourage you to research this further.  If you aren’t already using source control for your code today, imagine the benefits of a central, consolidated, secure, and reliable source of managed code.  With source control you can very easily and quickly compare different code bases/versions and see who made what changes, when those changes were checked in, who performed the code review, and what comments were provided when the developers checked in changes.  Having this information readily available is invaluable – especially for those “it worked before the release” scenarios.

I can’t tell you how many times I have wanted to go back in time to a different version of a stored procedure or view.  Sure, there may be comments in the code, but how reliable are those comments?  Do existing comments add value or clutter?  My experience tells me that you cannot rely on each developer to add reliable comments for their database changes – you are lucky to get a date with initials.  What about being able to go back in time?  Comments are great, but how can I easily compare two or more versions of a stored procedure to see exactly what changed from version to version?  Ok, you may be able to trace DDL events (if you set your database up to trace DDL events easily) to go back to a previous version of an object, but I can count on one hand the number of databases I have seen that have reliable DDL tacking.  The funny thing about comments is if you look thru application code you will almost always find some comments, regardless of quality.  On the flip side, if you look thru database code you will rarely find a comment.  Developers generally send scripts to the DBA for production changes and that’s the end of it.  (If your developers can make DDL changes in a production environment then you’ve got one foot in the grave and the other on a banana peel.)

Source control also gives you the ability to hold your development team accountable for changes (and you since you approved the change).

I will discuss database source control products in another post, but be thinking about uninterrupted vacation time.