Version Control - Migrating Objects to Production

  • Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sjones/vcspart4.asp

  • Steve - the HTML title of this is wrong I think. it is same title as #3 so when you add them to favorites this one overwrites #3 - just a note

    good series

    Brian Lockwood
    President
    ApexSQL - SQL Developer Essentials

    http://www.apexsql.com/blog

    Stand up for an Independent SQL Community - be Informed

  • Hi Steve,

    For what its worth I think your article was good.   I really like the idea of having rollback script/release, allthough for me (and Im sure most people), the headaches of trying to reliably produce it from our source code would be difficult with multiple development streams on the go, at the same time, with varying release to production schedules, hot fixes...

    I think the only way to generate the rollback reliably is for the deployment tool/script/whatever, to detect/know the code being released and automaticaly generated the rollback script/release at the time of deployment.   Yeah I know..not trivial!

    Sorry I cant provide some insightfull and novell approach, except that i agree with most of the points in your articles, and that automating release deployments is the way to go.   At least with an automated tool there is a standardisation and simplification of process, and the possibility of improving it by adding more featues. 

    A bit of background from my place (hopefully you wont cringe), we have a simple VBS script (yeah I know boring!), but it doesnt need any configuration to be used.   Just copy the scripts and DTS packages into pre-defined folders, run it (specifiying the database and SQL server), job done, with a nice little log file and a "release history" table in each database which records all releases applied to a database, when, by whom, success/failed (damned handy!).  Its not perfect, and requires the sql scripts to be full of conditional logic,  but overall it has made a massive reduction in the number of issues related to db code deployment, which we used to do using custom scripts for each release. 

    ok... think Ive been writing too much, best go...

    Take it easy, good luck.

    Kev

  • Having rollback scripts for text-based objects like stored procedures, triggers, views is one thing (relatively easy) However, having rollback scripts for scripts that change structure, rearrange data, etc is entirely another. In my career, we never do this ahead of time, but only if there is a problem in rolling out the original structure change, then we attempt to fix it from the state that the problem left it in and go from there.  -Vic

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply