.NET Configuration Hell
Modify the configuration files every time you deploy in a new environment. This is a task often performed by the operations department and is time consuming and error prone. We tried to regain control on the situation by documenting this process thoroughly. Although our effort helped with the communication between the development team and the operations department to be more effective, the overall result is not what we hoped for. Eventually the operations department ends up with maintaining separate copies of configuration files in different locations on the staging servers. This means configuration knowledge is kept outside of the source control system. The side effect of this is that when you make changes, you need to make changes to every file in every location. We also tried to maintain separate files with different names such as development.config, test.config, acceptance.config, production.config. What brought us a step closer in the right direction is to split the configuration files in aspect areas such as developmentData.config, testData.config etc and although making changes is now less intrusive this does not solve the maintenance burden for the operations department. Certainly we experimented with the Enterprise Library configuration block and build our own plug-ins for the configuration tool.
Where do we stand today with configuration management? With over four hundred applications in production not to mention the number of projects in staging at the moment, operations department is struggling to stay on top of things.
How does your organization cope with the configuration associated with .NET? What are your experiences? Do you use tools?