PS：概要、背景、結語都是日常“裝X”，可以跳過直接看自動發布
環境：阿里雲SLB、阿里雲ECS、IIS7.0、Jenkins、Spring.Net
概要
公司一個項目從無到有，不僅僅是系統從無到有的過程，也是項目管理流程、運維流程逐步完善的過程，今天主要說說運維方面的，從人肉運維到自動運維，我們搭建了運維平台來實現。運維平台在很多人理解應該是運維來做，不過就像前面文章說過，在很多公司，資源有限的情況下，研發往往是“萬能”的，需要承擔更多的責任，本文我們主要講關於Asp.Net自動發布這一塊。
背景
1、新進入一個公司，往往系統已經初具規模，已有成型的框架，但往往由於前期為了趕項目進度或者系統架構規划問題，隨着系統功能的不斷增加，一些運維方面的問題會越來越突顯出來，如：配置管理混亂、站點特殊內容太多且無記錄、發布純人工操作等，發布風險很高，每次發布都提心吊膽，如臨大敵；
2、作為一名想“偷懶”的程序員，自從走向管理崗，就開始為運維自動化的投入爭取資源，公司的運維平台搭建基本都是自己做產品經理或者研發。目前我們實現了日志管理、調度管理、站點管理、ECS管理、負載均衡管理、配置管理（目前只是實現了配置分離，下一步會實現配置動態生效）、發布申請管理、自動發布管理、MQ消息隊列管理，監控主要是用阿里雲自帶的，業務異常監控應該算目前比較缺失的一塊，以及其他很多都需要完善，但對公司最緊急的基本都已經實現；
3、在當前Java風行，其他新興語言慢慢崛起，並且微軟自身也推出.Net Core的情況下，.Net的市場份額越來越小，很多公司都開始轉Java，包括我目前所在的公司新系統也開始使用Java了。但就算轉Java，以前的系統還是需要維護，對於公司來說花最小的代價達到優化的效果就行，轉語言不是目的。對於程序員來說，掌握哪一種編程語言本身並不重要，更重要的是編程的思想、系統架構的思維，編程語言只是一種表現形式（作為一名.Net的老兵，最近在准備做Java的容器化，優化Java架構）。
自動發布
從我加入公司到現在，關於.Net的IIS站點發布大概經歷了以下3個階段：一、手工發布；二、半自動發布；三、系統自動發布；
一、手工發布
該階段缺點：
1、運維人員需要記住相應的代碼路徑、解決方案、項目名稱，站點新建沒有標准，導致不同的站點有一些特殊的設置或操作，導致新入職的運維人員需要很長時間才能上手；
2、需要登錄每台服務器修改配置，以及切換IIS站點路徑，重啟站點，且無法驗證是否發布正常，發布工作量巨大，發布效率低，發布風險很高，把問題的發現拋給了用戶，每次發布都提心吊膽；
3、沒有統一的平台管理各類信息，導致大部分信息都記錄在相應的研發或運維人員腦袋里，每次關鍵人員離職都是“大地震”，信息孤島嚴重；
4、大部分工作都壓在運維人員身上，且大多數時間都在做一些簡單重復的工作，不利於運維人員自身的成長，難以留存人員。
二、半自動發布
該階段優化內容：
1、制定IIS站點規范（如：配置與應用分離、增加發布成功測試頁、規定特殊項的范圍）；
2、運維平台實現IIS站點信息及配置管理（維護站點基本信息、配置信息、特殊項）；
3、運維平台實現阿里雲SLB的管理（同步基本信息、添加/移除/刷新ECS狀態）；
4、搭建Jenkins持續集成平台，實現預發布環境的站點發布（獲取最新代碼、生成打包、上傳服務器、覆蓋文件、重啟站點）。
該階段缺點：
1、投產站點發布還是需要運維人員登錄到每台服務器里面進行操作，發布工作量大，且人工發布雖然有信息記錄，但因為不同運維人員的能力不同，導致發布風險還是很高；
2、發布准備以及操作發布的時間都比較長，導致發布的前置時間比較長，不利於系統的快速迭代。
三、系統自動發布
該階段優化內容：
1、利於IIS的FTP實現發布文件分發到IIS站點的各服務器，並復制到相應的站點目錄下；
2、利於C#類庫Microsoft.Web.Administration.dll，實現對IIS的站點管理，如：切換路徑、站點重啟等，相關代碼見：IIS站點管理-IIS站點以管理員身份或指定用戶運行；
3、實現IIS站點發布的批量操作，如：從SLB移除ECS、發布配置、發布站點、瀏覽測試頁、從SLB添加ECS、直至成功標記為已發布。
自動發布相關截圖：
1、創建發布申請：
2、發布操作頁面
3、單個站點一鍵發布
4、批量發布組1同時移除組2
結語
.Net的份額確實是在逐年下降，微軟自己開始主推.Net Core，不過對於公司已有的系統，有些並不一定要去花時間重構，能花最小的代價達到能接受的效果對公司才是最划算的；以上很多只是提供了思路，以及關鍵的實現，如果大家真的需要應用到自己公司的系統，還是需要結合自己公司的情況進行處理。