If everyone else thinks like me, automated database builds are the holy grail of continuous integration tasks. If you're a .NET-ish shop like this one, your DBAs are attached at the hip and aren't some nebulous/grumpy/ponytailed group that exists solely to shoot down your ideas because "[insert anything but MSSSQL] doesn't think that way." So, they write code just like you.
And, just like you, their code breaks. Only, because they hold the lifeblood (the data) in their purview, they also have the unique ability of completely screwing you over with a simple mistake. So, their code must be solid.
So, the thesis: just because it's DDL, why can't I treat it just like compileable, and therefore, unit-testable, code?
Fortunately, you can do this with TFS. It's a pain because of several known issues all nicely detailed here by Buck.
After a little haggling over infrastructure to pay for another license for Team Edition and a mess of horrifically complex build scripting (see post title), merges to our database code now automagically kick off a test battery and deploy to our staging environment.
The best part is, once our DBA(s) got wind of my plan, they put in their ideas and now are so excited to write unit tests. Bless their hearts. I'm excited that they're suddenly light years ahead of most database developers.
I just pretend to not care so they won't ask for a raise ;-)
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment