I'm wondering how other developers are handling source code conflicts for config files when system admins modify them in production. For example, if a system admin updates a appsettings key on the production server and then my team publishes out a project, it will overwrite that key.
How do you handle config file updates in your organization?
We don't let sys-admin take control of the web.config. It shouldn't ever be allowed. Only a build manager or a team-lead should have access to actual production web.config. What purpose do you see for a sys-admin to access the web.config ?
Personally I use machine.config file and never store any environment related setting in app/web.config. This allows me to deploy the exact same application on all environments.
In my opinion, this is a sign of the process flow breaking down.
The only time that a production file should be changed is if it is critical (performance, critical to business needs, etc). Other than that, everything should go through a predefined flow. The process is bigger and more important than any member in it - including admins.
Part of that flow is that the most recent version in version control is the "definitive copy". Changes applied to production should also be made to a version in SC. Preferably, the SC version should be changed so that uncontrolled files are not floating around.
If admins need to change an AppSetting, then I would move that value to a database table instead and give them a UI to modify it. As everyone else has said, the config files should be stored in source control.
I think my answer is it depends. Perhaps it is a non-critical application and it was designed with some parameters that need to be changed from time to time. Instead of creating a database with a table and a GUI interface for a couple of parameter changes or have an external text file or xml file, train the admins to open the web.config and change an appsetting parameter. As long as there is some way to manage the process, I can perhaps see a use for this.