Continuous Integration with SQL Server DBMS's

  • Has anyone had any experience with setting up continuous integration with a database? I need to pick someone's brain a bit.

  • Welcome to my personal little slice of hell. What's up Rich?


    - Craig Farrell

    Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

    For better assistance in answering your questions[/url] | Forum Netiquette
    For index/tuning help, follow these directions.[/url] |Tally Tables[/url]

    Twitter: @AnyWayDBA

  • Hi Kraig - This is more research that I am doing for a colleague. He may give me some details to share, or just jump right in here in a moment. Thank you for such a quick response, and stand by...

  • Hi again Kraig...He basically described the following...

    "Basically trying figure out the pitfalls when working with four nonproduction environments and managing changes..."

    If this leads down too many Rabbit holes, just let me know, and I will seek more specifics.

    Thank you again

  • The entire process is a rabbit hole. Imagine having all of your code looking like this in source safe:

    If not exists (table)

    Create table (15 columns)

    If not exists (select column2 from sys.syscolumns)

    ALTER TABLE ADD column2

    if not exists (select column 3 from sys.syscolumns)

    ALTER TABLE ADD column 3

    ....

    ...

    ...

    You get the drift. If you don't hard version the code, you need to be able to have it run from any point.

    Now, imagine trying to figure out your correct rollBACK script from that tragedy. I'll leave it to you to understand it's a damned mess once you get a chance to think it through. 🙂

    Next, do some serious data alterations. Remember, each one of those add columns is a unique statement. Take your 2billion row table that has 5 columns coming in for a new deployment, and then split the pages/add information in 5 separate passes.

    Kabang.

    Now, you're trying to trace an error, and you've traced it to script logic. Your 'current' version of any proc is the always active version. You can't know which version of any particular proc was in play in *production* at any one time, because they don't hard-version the deployment, so it could have been any one of a dozen possibilities. Can you narrow those possibilities down? Sure. Completely? Only if you're lucky.

    Soft versioning the hard-storage system is just one royal pain in the *** unless you simply treat it as a data-store, and not a data-engine.

    EDIT: I cut it off there because this was quickly going to become a rant. There is only ONE good reason to CI the database layer, and that's ORM. Since I consider ORM to be demonspawn, there are no good reasons to CI the database layer.


    - Craig Farrell

    Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

    For better assistance in answering your questions[/url] | Forum Netiquette
    For index/tuning help, follow these directions.[/url] |Tally Tables[/url]

    Twitter: @AnyWayDBA

  • Kraig, thank you for sharing this. I'm sure my guys who are working on this are going to be thrilled!

    😛

  • Rich Yarger (9/19/2011)


    Kraig, thank you for sharing this. I'm sure my guys who are working on this are going to be thrilled!

    😛

    My pleasure... kinda. Every time I the project that uses CI at my current installation boots up a complex process that they need me involved in I cry a little inside. The impact of the process is just lost, because the concept of irreversable data and schema corruption doesn't really apply when you can reload the same front end object a few hundred times.

    I understand the concept and I've been trying to figure out a way that the soft-versioning (at BEST, if they'll even give you that) will work reasonably with the Database Engine's Tier, but so far I haven't come up with a solution that doesn't shoot me in the back of the head when's noone's looking.

    If I do, I'll probably become the 'next big thing'. In the meanwhile... goood luuuuuck.


    - Craig Farrell

    Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

    For better assistance in answering your questions[/url] | Forum Netiquette
    For index/tuning help, follow these directions.[/url] |Tally Tables[/url]

    Twitter: @AnyWayDBA

  • Rich Yarger (9/19/2011)


    Has anyone had any experience with setting up continuous integration with a database? I need to pick someone's brain a bit.

    Hi Rich,

    I've very recently put together a Best Practices document for database continuous integration using Red Gate tools. Please let me know if you're interested in a copy. You can contact me at David dot Atkinson at Red-Gate.com

    I'd be keen to get your feedback before it is published.

    EDIT: This now exists linked off www.red-gate.com/ci

    I've had a lot of interest in this topic which has inspired me to start a blog at www.geekswithblogs.net/SQLDev

    David Atkinson

    Red Gate

    PS If anyone else is interested in this, just drop me an email!

Viewing 8 posts - 1 through 7 (of 7 total)

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