Every time I hear a reference to our upcoming release of Visual Studio Team Edition for Database Professionals referred as “Datadude” I see images of surfer dudes in California with flowery board shorts waving their hand back and forth with pinky and thumb up. Can’t you hear it? “Duuuuuuuuuude”. J
Recently we’ve had some questions come up about this “personal sandbox” concept we’re advocating in this product. What’s with this sandbox anyway? Are we trying to encourage these datadudes and data dudettes to play nice? Well in short… actually… yes. J
Why? Imagine this dude(tte) running around trying to resolve changes to the database schema across several database servers in production, test and development…. The production server is typically the reference point – “the truth” – in what the schema should look like, but hey – the dev guy asked you late one night to make a change to the dev server so that he could try something out; and you can’t remember if that change – or any of the other changes people have asked for are in production or test. Meanwhile, other people are making changes to those servers for various reasons, and you may not always be in “the know”. Or perhaps you’re in the middle of writing some high priority new functionality, and you can’t wait for the dba to make changes on the dev or test server for you – you want to be able to easily grab the latest schema but you’re not even sure which server that might reside on – and you’re quite sure the dba won’t let you at any of the data either for testing. Can this simply be a datadude(ttes) bad dream? Unfortunately, from what we’ve heard from customers, this is part of the harsh reality of day to day life as a db pro. Now images turn to that poor woman in those old Calgon “Take me away!” commercials – but wait! You don’t need Calgon – you need Visual Studio Team Edition for Database Professionals (say that really fast 3 times!).
Let’s first talk about the audience for this product – is it for the dba? Db developer?
We found that there were even new role names emerging in this area in some organizations. The “datadude” role came out as a reflection of the diversity in the way organizations divide the work in this area – so rather than limiting our product to a role name that had preconceived notions associated it, we went with “datadude” as our internal reference for the role, and our final (and yes quite possibly the longest) product name is also a reflection of this.
So you’ve been “managing these changes” by using tools that do schema diffs? You can certainly continue to do schema diffs with this product – and data diffs too, but we take this a step further by bringing in best practices like SCM. What is SCM? Sounds awfully formal and complex if you read that description, but the right tools can enable this and make it a seamless process. And it’s a best practice that developers have been leveraging for years.
Datadude is about changing the way changes are “managed” today in the db world. We do this by providing seamless integration with Team Foundation (as well as SCCI providers) and enabling SCM throughout what we are referring to as “DDLC” – Database Development Lifecycle. Similar to SDLC – Software Development Lifecycle – it’s about all of the activities involved in evolving a database application.
But what does this have to do with that sandbox and playing nice?
The sandbox is each datadude(tte)’s copy of “the truth”. They have their own space in which to test out changes, run unit tests, and build database scripts. You can think of this as their “offline” copy of the database. When they’re done with these changes, they check in those changes into Team Foundation Server, identify what those changes were for, Team Foundation Server detects any conflicts in changes and helps you resolve them, and thus everyone has one central location that stores “the truth” and everyone is in “the know”. No more trampling over each other with competing changes or waiting for one person to give you what they think is the reference schema. DB Pro edition gives everyone the freedom they need to be productive and at the same time introduces the discipline of SCM to manage all of those changes.
So how does this work - do I need to have a machine that can support my large database to play in the sandbox?
When you set up your sandbox for the first time, you’ll either get a database project that’s been set up for you from version control, or if you are responsible for that project, you’ll point to your reference database and do a schema import (sometimes referred to as reverse-engineering your database). Individual scripts will be generated per object and you’ll have your own environment within Datadude to try out changes, run unit tests and even do rename refactoring. Under the covers Datadude uses SQL Server Express, but you can configure it to use SQL Developer Edition.
What does it mean to you? But you’re already taking your scripts and putting them into version control. Why should you care?
The DB Pro edition automatically runs those scripts within the sandbox to provide a running copy of the database environment, as well as tools for editing the scripts, generating test data using rules that you specify for the data generation, unit testing that can be run against that data, and rename refactoring which shows the impact of a rename before you run it. SCM – whether it’s Team Foundation Server – or some SCCI provider – is an integrated part of this environment, making it a natural extension of activities that db pro will do because it’s no longer a secondary thought, but a primary one that is easily within reach to accomplish. If you’re the person in charge of the “real” servers, you can also deploy using the version controlled copy of the schema from the DB Pro edition.
Well what about all of the versions of the database that are out there…
This is an opportunity to get all of your servers on the same version which is built from the scripts checked into Team Foundation Server. You would point to your reference of “truth” in Team Foundation Server rather than a running database server. One advantage of many is that this lets each developer pull down the reference schema from version control to test in their sandbox. If you’re using Team Foundation Server they would log requests to make changes in the schema as a workitem that the dba would complete and mark as resolved in that same central system. Another advantage is the ability to deploy databases from the version controlled database project.
Do you have to use Team Foundation Server to take advantage of this?
No – you can use version control products that support SCCI. There are many advantages to using Team Foundation Server of few of which include integrated Work Item Tracking, automated build, reporting and customizable process support. For more information go to http://msdn.microsoft.com/vstudio/teamsystem/team/ .
But Visual Studio is only for developers…
In past yes – but with the release of Visual Studio Team System, we expanded our audience to include other roles in the SDLC – architects, testers, project managers, and now database professionals. Our documentation folks put together some great initial help information which includes walk throughs. You can find it once you’ve installed our CTP by going to Start|All Programs|Microsoft Visual Studio 2005|Microsoft Visual Studio Team Edition for Database Professionals help. If you’ve never been in VS before, here’s a link with a quick tour, and more in the Datadude help to orient yourself.
Is this database project the same one that I’ve seen in Visual Studio?
If you are referring to the ones under one of the programming language nodes or “Other Project Types” in “New Project” – then no. These DB Pro projects are under the top level “Database Projects” node which appears at the same level as the programming language options (once you’ve installed the CTP).
Where can I go for more information?
http://msdn.microsoft.com/vstudio/teamsystem/dbpro where you can find links to detailed product information, articles, FAQs, On-demand webcasts, product group member blogs, the latest CTP download, etc.
