Originally, I looked into database source control as a means of making sure that the database schema would always be available regardless of the catastrophe. I wanted to have a plan for the worst case scenario. There may come a time where I need to get the applications up and running even if the primary backups were destroyed, and the offsite backups were corrupt.
My original goal for having the databases in source control was for disaster recovery, but I discovered additional benefits. As part of my script reviews, I could compare stored procedures or tables to previous versions and easily identify what was changed. If a deployment required a rollback, the previous state of the database could be restored from version history in source control.
Having source control allows the database schema to be deployed consistently across servers and time. Getting the buy-in to get our databases into source control was easy. Adding a database to source control is a straightforward process. However, I soon found that automating a deployment from source control was more complicated than I anticipated.