I’ve been struggling with VSTS:DB for some time; I love the idea of source controlling my development databases (right now we’re just using backups to prevent code loss), but I’ve not been able to really get my head wrapped around how VSTS:DB works. Even though I consider myself a developer, I guess I’m still a DBA at heart. Visual Studio is like a foreign language to me; I can pretty much figure out the equivelent of “where is the bathroom?”, but I wouldn’t consider myself fluent in it.
It’s obvious that VSTS:DB was designed for developers; they use VS terminology like solutions, projects, and references, but leave out common administrative tools like execution plans. The goal is to develop “off-line”, and then apply changes from source control to your development environment (so that additional application testing can be done); the model is that the source control is the truth, not the dev environment. Of course, if you’re at all remotely interested in this topic, there are better resources than I that describe this (but not many; see below).
Here’s the challenges I see with VSTS:DB
Poor documentation: I found a couple of forums, and one book that actually mentions DataDude. The online help files are OK, but help files aren’t how-to’s; they’re designed to respond to a specific question.
Reverse deployment: The product assumes a particular model of deployment; changes flow from a dev environment to source control, and are ultimately deployed to a production environment. However, in our shop, we often face the challenge that a stored procedure may need a performance tweak (such as an index hint); our datasets are so huge that the dev environment can’t always see those scenarios. A production DBA will make a change to code, but that change doesn’t get propogated back into source control, and we lose vision on it (unless we do a manual review of the change scripts and catch it).
The database-as-project metaphor: When application developers work with Visual Studio, a project represents a compiled piece of code (like a dll or an application). If they make changes, redeployment means replacement; the old dll is overwritten by the new dll. Databases obviously don’t work that way, and even though the tool seems smart enough to change CREATE scripts to ALTER scripts, I’m still not sure that’s the best way to deploy something. What if you’re working on some stored procs that aren’t ready to deploy? You can manage what gets deployed by doing a schema comparison, but it just seems klunky.
Adding features mid-release: Really not a challenge per se, but it is one of my pet peeves. Microsoft just released an RTM version of the GDR (General Redistribution Release) in November. According to the developers, it’s a “complete new release”, with several fundemental changes to the architecture. Although the official version is not out yet, it does mean that we have to be very precise when comparing what version of VSTS:DB you’re working on (are you on 2008 or 2008 GDR?).
Anyway, I hope that I can work my way through some of these challenges, and I’m sure that my perspective will change as I become more familiar with the way the VSTS works, but for now, I’m frustrated. I’m hoping that as I being detailing this journey, those frustrations will resolve themselves.
