Environments Question RRS feed

  • Question

  • From watching the "Walkthrough" web cast and what I understand - when I have a DB solution set up with CTP6

    • Use local instance of SQL for dev - deploy changed scripts here and test
    • When if comes to deciding what to promote (Dev to Test) - If I understood video correctly - I do a Schema compare of my DEV DB and TEST DB and will get a script file to either save or run

    My questions are:

    1. If there are 2 to many developers, every day I should get latest from VSS from inside Vis Studio project - can I really trust that everything I'm getting should be part of the update to my local DB?  Isn't it possible even myself I could have written test function that works for what I needed it to do but didn't really mean it to be part of solution nor other folks?
    2. How does the DBA role fit into this as far as doing Production drops - do one of the developers do a schema compare from one environment below Production (either Test or Pre-Prod) and hand off the scripts to the DBA to execute - or is best practive for the DBA to open the solution and do this compare himself?
    Wednesday, October 25, 2006 3:54 PM


  • Joe -

    You might also want to take a look at the Managing Database Change overview - http://msdn2.microsoft.com/en-us/library/aa833404.aspx and perhaps the introductory product walkthroughs in the docs (though they don't address the DBA role in depth) - http://msdn2.microsoft.com/en-us/library/aa833196.aspx.

    With respect to your questions:

    1 - This really depends on your team culture. If your team only adds to the database project and related unit test project the things that should be part of the database, then absolutely. If you want to have other test functions that are not shared with the team, you could set up additional test projects to avoid modifying the team unit tests. A key aspect of Team Edition for Database Professionals is that all team members are working against the same copy of "the truth" of the database schema. If you have unit tests in place, any breaks by an individual developer should be caught prior to checkin, assuming everyone runs their unit tests before they check in.

    2 - While I'm sure the exact process will vary from location to location, a common scenario would be that the DBA would sync to a labelled "good" version of the database that's checked in to version control. He (or she) would build and deploy that version to a staging server, and would then run the matching set of unit tests. Once any kinks were worked out, he (or she) would then manually deploy that build script into production. This keeps the developers working in their isolated environments, never having to touch the production server, and reducing risks of breaks.


    Thursday, November 2, 2006 6:58 PM