簡單幾步 優化網站的發佈流程

「下班了,走不走?」   「你先走吧,今晚上線。。。」      「。。。。」html

上線又是上線,上線這個大問題,幾乎每一個程序員天天都會執行不少次的機械操做。測試環境、仿真環境,預上線環境,生產環境;互聯網思惟的「快速迭代」,「小步快跑」;強調用戶體驗 的快速用戶反饋響應 等這些大環境,再到開發時間倉促、開發人員的配合狀況、測試的嚴格程度、線下環境線上環境的差別等等因素,小到頁面文字的修改,大到性能問題、架構問題的大幅調整,就算是生產環境,都不得不無時無刻面對着強大的上線壓力。前端

 

那麼咱們是怎麼上線呢?

1,藉助VS的發佈把網站發佈到本地;git

2,從tfs裏查看,從上次發佈以後開發人員簽入的歷史記錄,識別出須要更新哪一個dll、哪一個頁面或view、樣式、腳本等,按網站的目錄結構製做一個上線的增量更新包;程序員

3,若是有配置修改,複製一個線上的web.config到更新包,再加上或修改相應的配置;若是有文件壓縮任務的,執行壓縮;等等的修改完善增量包使之符合上線要求;github

4,找一個合適的時機覆蓋線上網站目錄,若是有多臺實際服務器,就執行屢次;或者大家有跳板機,而且有相應的文件的同步機制;再或者先更新預上線環境,測試以後,線上直接切換站點到預上線。web

 

好,一次上線完成了。這只是我正在經歷而且一直在重複的上線流程,固然其中會通過多個環境的測試不說了,熟練以後整個上線過程能夠在10幾分鐘內完成。而且我要告訴你的是,全部的線上服務器,咱們都是上一臺測試一臺沒有大問題以後再上另外一臺。能夠說這個過程雖然麻煩點,但基本作到無痛更新,也算是穩定高效的,^_^ 。。。typescript

固然上面說的最見的小幅更新或打補丁或增長新功能,有時候你會碰到破壞式的更新,須要數據庫的變更而且修改不能兼容如今的生產環境,那麼恭喜你,發個網站公告,高掛休戰牌,找個半夜,速度更新吧,而網站更新流程基本和上邊差很少。shell

 

有什麼不妥嗎

若是以目的爲衡量,流程徹底能夠啊;可是,整個流程各個步驟全手動,全手動,全手動啊,最不靠譜的就是手動,常言說:常在河邊走,哪有不手抖;手抖把線上數據給全刪了,手抖覆蓋錯網站目錄了。。。;怎麼避免手抖啊,健身。。。來罐紅牛。。。C,怎麼辦,好,用工具替代。數據庫

 

如何改進

1,靜態文件的處理自動化

專職作前端的都會了解grunt或gulp,這些工具把前端發佈的壓縮、合併、模糊等全都以代碼的方式作到流程化、自動化,看得讓VS開發者着急啊。npm

使人欣喜的是,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.aspxhttp://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發佈,打增量包或者不打,上傳到服務器一個文件夾,打開同步工具,選擇這個站點的同步設置,執行所有同步或單個逐步執行。整個過程不再怕手抖了,^_^

 

後記

作爲一個資深碼農,寫的一篇技術文,居然只有幾行不算代碼的配置代碼,水分太大。。。

加油

相關文章
相關標籤/搜索