I’ve been advocating that our company use composite projects for our deployments using the VSTSDBE GDR (Visual Studio Team System Database Edition, General Distribution Release for those not instantly geeky). In a nutshell, VSTSDBE offers two mechanisms for deployment across multiple environments. Both of these work wonderfully well for automation when you are doing a full tear-down and rebuild. When you’re doing incremental deployments, they both fail.
Option 1: Use SQL Command variables to set environment specific variables such as file location, etc., and post-deployment scripts to set security. This works. It’s the method we used prior to the GDR. Unfortunately, security and other environment specific information is hidden inside scripts rather than visible to a given configuration directly within the VS interface.
Option 2: Create a composite project. It stores the common objects, the stuff on it’s way to production, in one project, and the environment specific stuff, such as security, in a second project. Some of the Micrsoft guys are even suggesting this approach. You can then store everything inside of configurations and in project objects, visible to the VS gui, easy to maintain, easy to build…
Ah, but there’s the rub. Easy to build when you’re rebuilding every time. Incremental changes require a database comparison between the project and the database. Ah, but which project. In a composite environment, it has to deploy each project independently. What happens when a change requires a data loss? You have to create that script manually. Fine, but how do you now get it into the rest of the build in an automated fashion?
I finally punted and posted it on the MSDN Forums.