将 web.config 文件更改部署到现有网站
我正在审查我的公司部署网站的方式，并尝试确定是否需要更新我们的方法。我的具体问题是针对我们处理 web.config 文件的方式。目前，当我们部署时，我们不会覆盖服务器上的 web.config 文件。我们手动重现开发过程中所做的任何更改。原因是
1) 我们不想让开发人员有责任记住在部署期间将正确的 web.config（生产配置）部署到服务器
2) 我们也不希望让开发人员承担任何人的风险团队意外更改（甚至不必要地看到）
某些项目的生产 web.config 3)，还有其他团队有权修改 web.config（例如连接字符串设置），但我们不想覆盖他们的更改
我遇到过 web.config但我们当前的方法似乎更适合我们的特定情况。我希望有人能给我一个新的视角，如果确实有的话，可能会帮助我找到更好的方法。
I'm reviewing the way my company deploys websites and trying to determine if we need to update our methods. My particular question is geared towards the way we handle the web.config file. Currently, when we deploy, we do not override the web.config file that's on the server. We manually reproduce whatever changes were made during development. The reason is
1) we do not want to give developers the responsibility of remembering to deploy the right web.config (the production one) to the server during deployment
2) we also don't want to run the risk of anyone on the dev team accidentally changing (or even unnecessarily seeing) the production web.config
3) on some projects, there are other teams that have the power to modify the web.config (like connection string settings) and we don't want to override their changes
I've come across web.config transformations but it seems that our current methods are a better fit for our particular circumstance. I'm hoping for someone to give me a fresh perspective and probably help me see a better way if there indeed is one.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在一个开发团队（即 UI 设计师、程序员、SQL 开发人员）中，你的策略看起来相当正确，但需要准确的协调。您可以采用的另一种方法是告诉所有部门 web.config 的各个部分以及他们关心的部分。另外，请在 web.config 文件中进行注释，告知哪些部分与哪个团队相关。这样他们就可以自己处理配置文件，而不必摆弄他们不关心的部分。
您还可以借助 VCS（版本控制系统）来跟踪哪些用户在何时进行了哪些更改。
In a team of developers (i.e. UI designers, programmers, SQL developers), your strategy seems pretty right but it needs accurate co-ordination. The other way you can go is to tell all your departments about various parts of the web.config and the part which they are concerned with. Also, do commenting in the web.config file telling which parts are concerned with which team. This way they can handle the config file on their own by not fiddling with the parts they aren't concerned with.
You can also take help of VCS (version control systems) to keep track of what changes are made at what time and by which users.