“下班了，走不走？” “你先走吧，今晚上線。。。” “。。。。”
上線又是上線，上線這個大問題，幾乎每個程序員每天都會執行很多次的機械操作。測試環境、仿真環境，預上線環境，生產環境；互聯網思維的“快速迭代”，“小步快跑”；強調用戶體驗 的快速用戶反饋響應 等這些大環境，再到開發時間倉促、開發人員的配合情況、測試的嚴格程度、線下環境線上環境的差異等等因素，小到頁面文字的修改，大到性能問題、架構問題的大幅調整，就算是生產環境，都不得不無時無刻面對着強大的上線壓力。
那么我們是怎么上線呢？
1，借助VS的發布把網站發布到本地；
2，從tfs里查看，從上次發布之后開發人員簽入的歷史記錄，識別出需要更新哪個dll、哪個頁面或view、樣式、腳本等，按網站的目錄結構制作一個上線的增量更新包；
3，如果有配置修改，復制一個線上的web.config到更新包，再加上或修改相應的配置；如果有文件壓縮任務的，執行壓縮；等等的修改完善增量包使之符合上線要求；
4，找一個合適的時機覆蓋線上網站目錄，如果有多台實際服務器，就執行多次；或者你們有跳板機，並且有相應的文件的同步機制；再或者先更新預上線環境，測試之后，線上直接切換站點到預上線。
好，一次上線完成了。這只是我正在經歷並且一直在重復的上線流程，當然其中會經過多個環境的測試不說了，熟練之后整個上線過程可以在10幾分鍾內完成。並且我要告訴你的是，所有的線上服務器，我們都是上一台測試一台沒有大問題之后再上另一台。可以說這個過程雖然麻煩點，但基本做到無痛更新，也算是穩定高效的，^_^ 。。。
當然上面說的最見的小幅更新或打補丁或增加新功能，有時候你會碰到破壞式的更新，需要數據庫的變動並且修改不能兼容現在的生產環境，那么恭喜你，發個網站公告，高掛休戰牌，找個半夜，速度更新吧，而網站更新流程基本和上邊差不多。
有什么不妥嗎
如果以目的為衡量，流程完全可以啊；但是，整個流程各個步驟全手動，全手動，全手動啊，最不靠譜的就是手動，常言說：常在河邊走，哪有不手抖；手抖把線上數據給全刪了，手抖覆蓋錯網站目錄了。。。；怎么避免手抖啊，健身。。。來罐紅牛。。。C，怎么辦，好，用工具替代。
如何改進
1，靜態文件的處理自動化
專職做前端的都會了解grunt或gulp，這些工具把前端發布的壓縮、合並、模糊等全都以代碼的方式做到流程化、自動化，看得讓VS開發者着急啊。
令人欣喜的是，VS2015已經做了足夠工作，加入了任務管理器，讓我們在發布過程中方便的加入自己的邏輯；並且可以集成grunt、gulp、npm、bower等讓我們以更現代的方式管理前端依賴、流程化、自動化；typescript、less等也有了更完美的使用方式。不得不說，vs2015在開放性這塊進步太大了，強力推薦有條件的速度升級啊。想了解15的看下這個：http://webtooling.visualstudio.com/
15之前如何完成靜態文件的自動化呢？這里推薦一個插件：Web Essentials，安裝完成后，在相應文件夾上菜單上選擇相應操作執行一次壓縮操作生成壓縮文件，之后每次編輯文件，保存時就會自動執行壓縮操作，你所要做的就是加一個配置：讓生產環境使用壓縮或合並之后的文件。
說到配置，如何避免頻繁的配置修改呢？避免上線時的手工修改配置呢？
2，Web.config 轉換
你是否對網站web.config下邊的Web.Debug.config 和 Web.Release.config 產生過興趣？他們是什么作用，嗯，我知道，無非就是debug發布模式下，會使用Web.Debug.config，相應的release發布模式下使用Web.Release.config。哈哈，恭喜你，答錯了。。。
我們知道web.config是一個XML格式的配置文件，而web.xxx.config也是一個XML文件，它不是配置，而是對web.config的配置的轉換：它定義的內容都是對web.config里配置節點的執行一個匹配和轉換的操作。
例如：我們在web.config中定義靜態文件后綴的配置：
<add key="StaticFileType" value="" />
配置為空，這樣表示使用原始文件。
而在web.release.config中：
<add key="StaticFileType" value=".min" xdt:Locator="Match(key)" xdt:Transform="Replace" />
這樣，我們在release模式下發布的網站，配置的值就會是 .min ,這樣就是我們在生產環境下使用的靜態文件的后綴。
更詳細的轉換語法描述：https://msdn.microsoft.com/zh-cn/library/dd465326(VS.100).aspx
推而廣之，我們通過這種方式，我們在開發時就做好 web.xxx.config，保證release模式下發布出來的配置一定是不經過任何人為修改就可以直接覆蓋線上環境的的配置文件。
這樣，我們就能保證release發布出來的網站包，直接就是可以覆蓋線上目錄的網站包。
但是我們怎么可能每次都全量更新啊，對我們要出增量包。
3，自動打出增量更新包
上文描述的手動打增量更新包的方式，費時費力又容易出錯，其實這個步驟是最機械重復又沒有意義的操作，但是我們就是重復並且還會一直重復，哎。怎么自動打增量包呢？確切的說，我也沒有方法。
推薦有興趣的看下這篇文章：http://www.cnblogs.com/starup/p/3831607.html
有毅力的同學可以研究下，但是想通過另外一個方式解決，大概思路就是：用新的網站發布包和上一次的網站發布包比較，把新包里與舊包里不一樣的文件按原有目錄形成一個增量更新包。
通過一痛猛找，發現在現有的工具：能做到兩個文件夾的比較，並且列出不一致的文件，但是沒有找到能把不一樣的文件自動按原有目錄結構形成增量包的功能。怎么辦，自己動手，程序員做這個小工具還不簡單嗎，最近了解了下window下的shell，powershell，就寫一個小腳本。
腳本源碼：https://github.com/fengzhbo/MySampleCode/blob/master/Code.PS/deploy.ps1
雖說是用來打增量包，其實可以用來比較任意兩個文件夾，然后按原來的目錄結構開成一個差異包。有興趣的可以使用，修改最下邊的幾個配置參數就能使用，當然並沒有嚴格測試，歡迎踴躍測試，提意見，提bug，提交代碼。
說到powershell，寫慣了正規的C#代碼，寫ps代碼，簡直是受虐，幾乎要顛覆所有對語言的正常理解。但好在靈活，並且功能強大（能使用.net的所有功能），有興趣的同學可以了解下，推薦兩個網址：https://technet.microsoft.com/en-us/library/bb978526.aspx，http://www.pstips.net/powershell-online-tutorials/ 。
好，增量包也出來了，該覆蓋了，接下來
4，減少應用程序域重啟次數
我們知道對配置和dll的任何變動，都會造成應用程序域的重啟，而在一個覆蓋過程中可能會造成應用程序域重啟數次，這對用戶來說是可能是短暫的響應延遲，而對服務器來說是連接數的快速上升，因此我們應該盡量減少避免應用程序的重啟次數。
<httpRuntime waitChangeNotification="5" maxWaitChangeNotification="20"/>
就是這兩個配置項，如上的配置：只要我們兩個引起重啟的文件變動間隔在5秒內，並且整個覆蓋過程在20秒內完成，我們可以做到一次覆蓋過程中只造成應用程序域的一次重啟。
關於這兩個項的意義，請參見：https://msdn.microsoft.com/ZH-CN/library/e1f13641
5，文件的同步與分發
這里就說到了如何把增量包發布到生產環境了。
1，切站點，可能是最理想的上線方式了。但是切站點，實施的方式就是把域名強制綁定到另外一個站點上去提供服務，因為一個域名只能綁定的同一個服務器的一個站點上，綁定過程中會造成原來站點的停止運行，在這個時間段進來的用戶就受不到正常的服務了。而直接覆蓋站點的方式造成的應用程序重啟，只會造成短暫的延遲，理想情況下不會失去服務能力。
2，自己的同步機制，也就是在把增量覆蓋到一個指定的文件里，自己的工具，會監測到哪些文件變動，然后同步到實際服務器上。這種方式安全快捷，但是缺點是幾點服務器會同時進行和重啟的進程，影響較大。如果發生有文件錯誤或同步過程出錯，整個網站全部無法訪問。
3，手動覆蓋，可以自己控制節奏，但是缺點就是怕手抖，一個大意覆蓋錯了網站目錄，影響太大了。
各有優缺點，提供另外一種方法：利用文件同步工具，推薦一個開源工具FreeFileSync，在跳板機上或者一台服務器上，定義需要同步源和目標，定義同步策略，保存設置以下次使用。靈活的控制是全部一次更新，還是更新其中任意一個，做好設置之后每次只是點點鼠標的問題了。
更為厲害的是有了這個工具，其實完全可以不需要上邊打增量包的過程，工具會比較左右文件，然后只對不同的文件進行創建或復制。
當然左邊文件也可以不是全部的網站源碼，可以只是我們上邊打出的增量包，這樣整個同步過程就不用再去比較其它不需要更新的文件，讓我們整個同步過程會更加快速，減少應用程序重啟的機率和次數。
好了，整個過程就是這樣的。利用.net自身的一些小特性和一些開源工具，或者自己的小代碼，把整個過程簡化為一次配置，以后基本自動化的地步，還是很不錯的。配置完成之后的更新流程就變成了：VS發布，打增量包或者不打，上傳到服務器一個文件夾，打開同步工具，選擇這個站點的同步設置，執行全部同步或單個逐步執行。整個過程再也不怕手抖了，^_^
后記
做為一個資深碼農，寫的一篇技術文，竟然只有幾行不算代碼的配置代碼，水分太大。。。
加油