Stored procedures/DB schema in source control

Question

Do you guys keep track of stored procedures and database schema in your source control system of choice?

When you make a change (add a table, update an stored proc,

Answer 1

In past experiences, I've kept database changes source controlled in such a way that for each release of the product any database changes were always scripted out and stored in the release that we're working on. The build process in place would automatically bring the database up to the current version based on a table in the database that stored the current version for each "application". A custom .net utility application we wrote would then run and determine the current version of the database, and run any new scripts against it in order of the prefix numbers of the scripts. Then we'd run unit tests to make sure everything was all good.

We'd store the scripts in source control as follows (folder structure below):

I'm a little rusty on current naming conventions on tables and stored procedures so bare with my example...

[root]
    [application]
        [version]
            [script]

\scripts
    MyApplication\
        1.2.1\
            001.MyTable.Create.sql
            002.MyOtherTable.Create.sql
            100.dbo.usp.MyTable.GetAllNewStuff.sql

With the use of a Versions table that would take into account the Application and Version the application would restore the weekly production backup, and run all the scripts needed against the database since the current version. By using .net we were easily able to package this into a transaction and if anything failed we would rollback, and send emails out, so we knew that release had bad scripts.

So, all developers would make sure to maintain this in source control so the coordinated release would make sure that all the scripts we plan to run against the database would run successfully.

This is probably more information than you were looking for, but it worked very well for us and given the structure it was easy to get all developers on board.

When release day came around the operations team would follow the release notes and pick up the scripts from source control and run the package against the database with the .net application we used during the nightly build process which would automatically package the scripts in transactions so if something failed it would automatically roll back and no impact to the database was made.