Visual studio public & web.config transforms features

I work in an development group in an enterprise, where we strive to seperate business units and their responsibilities. So for example, I am in the development group and we are responsible for all tasks related to developing applications. We have other roles such as dbas, or operational roles that are outside of our group and are responsible for things like deployment, server maintenance, etc.

I'm looking at features in VS such as the publish web app feature and the web.config transform feature and reading about them in blogs and various other places. Based on the majority of what I read it always seems that the writer is assuming that the developer is managing things like connection strings, user names, passwords for the different environments in web config transforms, then publishing to a remove server in some kind of production environment (be it live, or test or staging, etc).

An example is here. In our environment, and I assume others too, the scenario is somewhat more complex than is usually portrayed. The development group may not k开发者_Python百科now where any of what they've developed is deployed. And administrators may move servers,databases etc and update configuration as characteristics of the environment dictate. So in these cases, how does web.config transforms help? Publish can still potentially be used locally to build artifacts for a deployment package but even you'd probably want to use some automated build manager instead.

So is publish and transforms really more suited for more rudimentary development processes where the barrier between development and operations is very grey? Or am I missing something? It just seems that a lot of things I've reading about this kind of thing have good intentions but are somewhat superficial in the context of a more defined development process.

Interested to know others opinions and experiences on this.

You can use configuration transformations in different ways. You are right; most samples you find address some kind of instant deployment through a developer and administrator in one person. But you can also use them with MSBUILD in a more sophisticated environment.

Look here

I find the same problem too. My opinion is that the development group should really only care about environments close to it, which could mean: development, validation testing, integration testing and maybe some pre-production one.

I think that one thing that should be a responsibility of the development team is to provide the delivery teams with appropriate application installers that allow them deploying customised configurations easily. One important part of these packages are updates and avoiding overwriting existing configurations.

There are many products out there to ease that development, but I'm not closely familiar to any of them, though I've heard good things about Wix (and it's free).