部署許多 Web 服務
我正在尋找建議/最佳實踐/+ve/-ve 或其他關於在 IIS 上部署和維護許多 (50) Web 服務和 Web 服務應用程序的建議/最佳實踐，跨 10 台機器的面向服務的客戶端 (WinApp) ） 軟體。
目前，我們有一個包含許多 Web 服務項目的解決方案。軟體是單獨開發的，然後在準備發佈時集成。這涉及到集成經理（不熟悉程式碼），將項目添加到主解決方案並確保一切正常，例如引用等沒有損壞。這意味著我們最終會在 IIS 中使用一個站點來提供許多 Web 服務。
最近的另一種想法是擁有多個站點 - 可能將相關的 Web 服務分組到一個站點中，但將其他 Web 服務保留在不同的站點中，儘管這會增加維護（因為有更多的站點），這意味著軟體的某些部分可以單獨更新並由編寫程式碼的開發人員進行測試。
可能相關：我們對程式碼使用原始碼控制，有很多使用者（每天大約 100 萬次點擊），並且可以在工作時間容忍 0 停機時間。
目前要更新單個 Web 服務，必須將應用程序伺服器從集群中取出，更新，然後再添加回集群。
有沒有更有效/更靈活，但仍然可以維護的方式來解決這個問題？
我可以分享我們目前在新的 Stack Overflow 數據中心所做的一些想法，這些想法可能會給你一些想法。首先要建構一個登台伺服器作為測試。登台伺服器是所有生產伺服器的副本。添加新站點時，經過測試，我會將 applicationhost.config 與一個簡單的 powershell 腳本同步。對於已經部署的站點的進一步更新，我們使用 .NET 的巡航控制，它允許跨 Web 伺服器自動建構。我玩過 IIS 共享配置，但發現它有點錯誤。
要自動將伺服器從集群中取出，您可以向負載均衡器添加執行狀況檢查，這將自動將其從集群中取出。
我喜歡您按開發人員或開發團隊對 IIS 站點進行分組的想法。我們做了類似的事情，它允許開發人員擁有自己的程式碼。作為管理員，您仍然可以擁有伺服器，但不會妨礙開發人員。
我還剛剛聽到一個關於持續部署（經常推送到生產環境）的有趣討論，你可以在這裡閱讀一些內容。你或許可以從中得到一些想法。
最終，您必須設計最適合您的公司和文化的東西。