Sabrie, thank you for your reply. Unfortunately, the process outlined in your documentation falls short in our multi-developer, multi-environment situation. Our environments include production, testing, and development; and local development for each developer. In an ideal world, a deployment would consist of backing up / restoring the database, copying the project files, and updating <add connectionString ...> in DataConfig.config. However, each of our environments has additional unique settings such as the STS setting for <federatedAuthentication> in web.config, the STS settings for <securityTokenIssuers> and <relyingParties> in SecurityConfig.config, <smtpSettings> in SystemConfig.config, <add defaultSenderEmailAddress ...> in NotificationsConfig.config, etc. -- not to mention the headache of config file tracking, versioning, and merging that's required as multiple developers promote their local changes to the central development environment and then up to the other environments.
SiteSync does not work for us because it does not work with HTTPS login, I could not get it to authenticate with our LDAP, it only syncs one way, etc.
In my opinion, if we're going to work with config files we need to have config files for each environment -- but the config files need to be versioned and easily merged, which Visual Studio and a versioning tool can do. And if we're not going to put all the configurations in web.config so that we can use the standard transformation functionality in Visual Studio, a solution like SlowCheetah is needed to produce environmental versions of those config files.