Joe -
If you haven't taken a look at the overview product documentation, you might find it helpful, particularly the "Managing Database Change" topic. To quicky summarize, the idea is that there are typically several copies of a database in use:
- a Production database, access to which is controlled carefully in most enterprise environments.
- a Staging database, which is used as the final test before you deploy changes into production
- one or more isolated development environment databases. These are private copies of the database that each developer (or tester) uses to work on changes.
Team Edition for Database Professionals is primarily focused at making it easy to work with the third sort (isolated development environments). The typical iterative development task being to check out the parts of the schema that you need to change, deploy them to your local isolated development environment, test those changes, then check them in when you're done.
At some point, a version of the checked in files is labelled, someone syncs to that label and generates the build script that will be deployed to the staging server where it can be tested. It may be necessary to iterate on that deployment script, either by tweaking the database project, or by making modifications to the build script directly. When everything looks good, the deployment script will be deployed into production.
You could use TEDP to deploy directly to production, but that's not the process that we advocate or that we expect folks to use. And when you're deploying to your isolated development environment, you definitely want to deploy your local (not-yet-checked-in) changes, so you can test them.
Let us know if that addresses your concerns or if you have additional questions or feedback.
thanks,
|