I’m curious about how various people are handling source control in their environment for the database? SSIS, SSRS, etc are all easy. They plug directly into the normal source control providers. But how do you handle SQL object changes like table changes, and stored procedure changes?
I’ve used a couple of different methods these days.
At one company we had a separate file in source control for each object in the database. As objects were changed the changes to the database objects were tagged with the same tag that was used on the client changes and website changes so when a release was done they did a build to the client, and on the database side we would get all the SQL files with the correct TAG and push all the changes to the database.
At my current company we put all our changes for each bug, release, etc into a single release file. Then when we move from Dev to QA, everything that hasn’t been deployed we push, then when we go to production we push all the files that we pushed to QA into Production.
Then there was my favorite. We didn’t really use any change control; but that was in the early 00s and we were a privately held company.
I look forward to your feedback. (Sorry, but you do have to register on the site to post a comment, its not my site, I don’t make the rules.)
Thanks,
Denny
One Response
I received a couple of responses on Twitter that I wanted to share with you.
[A href=”http://facility9.com”]Jeremiah Peschka[/A] uses VSS for source control, and uses TOAD to generate CREATE/ALTER statements to sync schemas between environments.
At [A href=”http://twitter.com/RobPaller”]Rob Paller[/A] current client uses PVCS for source control of DDL and SQL Scripts.