• Peter Schott (3/4/2015)


    Gary Varga (3/4/2015)


    These issues are no different from those for non-database code.

    I think I'd disagree with that to an extent. If I'm modifying table structures or doing refactoring, there are a lot of other things going on behind the scenes. I know I've been hit hard before with what should have been a "rename" operation, but looked like a "drop/add" situation. There's also no data to maintain with most non-database code. You drop a new file, you're good to go. If you change something in the database, your new stored proc may not work or may not work as expected because of data changes.

    I'd also say that the order matters a bit more w/ database ops because I might need to refactor in a certain order where each step preceding is needed for the end result to work. That's a bit different from being able to just drop the end files where they should go. I may have done some data manipulation along the way from step 1 to step 10 so can't just drop the changed proc/table in step 10.

    The issues may be similar, but I've found that DB changes tend to be a bit different because the state of the database matters a lot more than the version of the executable and isn't quite as easy to change overall.

    I get all that and agree with your points about the difficulties in the scripts to deploy but I was referring to deployment of only part of the code set worked on in a sprint. Merging and branching of code is the same, in my opinion, regardless of it being SQL or C# say.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!