我正在寻找build议/ best-practices / + ve / -ve或其他想法来部署和维护IIS上的许多（50）Web服务和Web服务应用程序， ）软件。
目前我们有一个包含许多Web服务项目的解决scheme。 软件是独立开发的，稍后可以在发布时进行集成。 这涉及到集成pipe理器（不熟悉代码），将该项目添加到主要解决scheme，并确保一切正常，例如引用等不被破坏。 这意味着我们最终在IIS中有一个服务于许多Web服务的站点。
最近的另一个想法是有多个站点 – 可能将相关的Web服务分组到一个站点，但将其他Web服务保留在不同的站点中，尽pipe这增加了维护（因为有更多的站点），这意味着软件的一部分可以独立更新并由编写代码的开发人员进行testing。
可能是相关的：我们使用源代码控制代码，有许多用户（每天点击一百万左右），在工作时间内可以容忍0次停机。
目前，要更新单个Web服务，必须将应用程序服务器从群集中取出，更新，然后重新添加到群集中。
有没有一个更有效率/灵活，但仍然可维护的方法去做到这一点？
我可以分享一些新的Stack Overflow数据中心的一些想法，可能会给你一些想法。 有一个登台服务器，作为第一次testing。 登台服务器是所有生产服务器的副本。 当添加一个新站点时，在testing之后，我将使用一个简单的powershell脚本同步applicationhost.config。 为了进一步更新已经部署的站点，我们使用.NET的巡航控制，允许跨Web服务器自动构build。 我玩IIS共享configuration，但发现它有点bug。
要自动将服务器从群集中取出，您可以将负载平衡器添加到运行状况检查中，以便自动将其从群集中取出。
我喜欢你的想法，由开发人员或开发团队分组的IIS网站。 我们做类似的事情，它允许开发者拥有自己的代码。 作为pipe理员，你仍然可以拥有服务器，但不妨碍开发者。
我也刚刚听到一个关于持续部署（推动生产）的有趣的讨论，你可以在这里阅读一下。 你可能会从中得到一些想法。
最终，你必须devise什么最适合你的公司和文化。