IIS / Web应用程序在我工作过的商店中一直是一个棘手的问题。
一方面，IIS是内置于服务器中的一种服务（通常是由服务器pipe理员负责维护和configuration的）。 当问题出现时，他们知道需要发生的事情，或者至less可以诊断他们所说的“Web应用程序出错”，并让开发人员debugging他们的代码。
但是，服务器上的每个Web应用程序都是独一无二的，并且具有许多细微差别，根据手头的问题可能会变得复杂。
另一方面，每个Web应用程序在许多方面都是独一无二的，并且具有需要处理的具体问题，开发人员是最了解应用程序的人。 如果需要修改web.config文件以进行debugging，或者IIS开始给Web应用程序带来麻烦，开发人员应该知道问题出在哪里，并相应地进行修复，无论是由于IIS还是应用程序本身。
但是，允许开发人员自行进入和调整IIS成为一个严重的问题，因为一些设置/优化可以严重影响服务器的性能和稳定性。
那么平衡在哪里呢？ 如果服务器pipe理员是IIS大师，并处理所有这些问题，我只是通过部署发送站点文件，或者如果开发人员承担服务器和IIS问题的责任，并相应地处理它们？
听起来像你真正需要的是在篱笆两边都有专业知识的人。
根据我的经验（对于规模较小的公司），IT /系统pipe理员工没有时间，兴趣或特定于webapp的知识来正确维护IIS设置。 他们会把操作系统的东西拿走，把IIS交给开发者。
显然，我需要“不仅仅是一个编码员”才能正确地工作; 我必须意识到系统级别的问题（安全性和不安全性）。 我一直在做低级系统pipe理多年，所以我对这类任务很有信心（实际上，这些年来我已经教过专业系统pipe理员几件事）。 但是，并不是每个开发者都有这种能力。
尽pipe如此，从我看到的，有更多的开发人员与系统pipe理员技能，然后有系统pipe理员（Web应用程序）的开发技能。
一如既往，YMMV。
我个人不希望开发人员混淆IIS，特别是如果这意味着它可能会导致另一个应用程序与另一个开发人员不得不麻烦拍摄的问题。
如果存在IIS问题，请让SysAdmin查看它，如果某个应用程序出现问题，请将其发送回开发者。 如果开发人员遇到问题，请将其提交给系统pipe理员，系统pipe理员可以尝试做出明智的决定，决定是否进行更改，并确定如何影响每个人。
我们（系统pipe理员）像我们第三方供应商一样对待我们的开发人员 – 当他们希望我们部署应用程序时，如果他们希望得到支持，他们必须提供文档。 这包括常见的故障排除程序和支持升级path（正常运行时间要求与在不可接受的停机情况下logging的开发人员责任相结合）。
这显然不是黑白的，但是为了缓解开发者和pipe理员之间的紧张关系，做了很多工作。 开发人员现在意识到，他们必须提供质量与其愿意被分页的意愿成反比的软件，开发人员现在拥有工具和文档，而不需要为没有创build的工具而烦恼。
因此，在您的情况下，这意味着开发人员将在自己的IIS服务器上创build应用程序，然后提供pipe理员在生产服务器上安装的软件和文档。
如果服务器pipe理员是IIS大师，并处理所有这些问题，我只是通过部署发送站点文件，或者如果开发人员承担服务器和IIS问题的责任，并相应地处理它们？
答案：find一个人并将他们标记为“WSA”（Web服务器pipe理员） 。 他们可以是pipe理员或开发者; 这真的没关系。 但是他们需要沉浸于工作的两个方面，其余的（双方）团队都需要尊重他们的专业知识。
这与DBA如何跨越IT / dev之间的界限没有什么不同。 鉴于Web服务器在基于Web的产品的组织中的重要性，我认为这是一个至关重要且常常被忽视的angular色。
由于networking还比较年轻（与数据库相比），很难招募到这个人。 你很可能需要成长/培养一个人担任这个angular色。
随着Web部署工具 （这将成为从Visual Studio 2010开始发布Web应用程序的标准内置方式）等新的实用工具 ，微软似乎正在走向让开发人员或至less安装工程师select像IIS设置证书，应用程序池设置等）。 它们被内置到msdeploy安装包中，并在包被部署到服务器时自动应用到IIS服务器。
似乎是一个合理的妥协。 开发人员不需要手动debugging在线生产服务器上的设置，而且系统pipe理员不必具备Web应用程序特定的知识。 然而，系统pipe理员可以清楚地看到所需的IIS设置，这些系统pipe理员想要了解在安装软件包之前会发生什么情况。