TFS線上生成環境發佈歷程

繼前文

TFS在項目中Devops落地進程（上）

TFS在項目中DevOps落地進程（下）

自從以前將開發環境使用TFS進行了自動化以後，就享受在此成果中，其餘後續進度就停頓了好一段時間。

畢竟在咱們這對於開發而言，作出代碼交出發佈包事情就結束了，而咱們的TFS已經完美的將這個流程給自動化掉了。

 

本文將聚焦在TFS發佈到線上生產環境中所作的一些工做和實踐，若是隻是糾結於如何使用TFS能夠參考上面的2個連接。

 

以前的線上發佈流程

說下咱們大概的背景，咱們的程序上線流程目前仍是相對傳統一些，大致是：

①開發寫完代碼->②提交發布包->③QA拿包測試->④測試完成提交上線->⑤運維拿包進行發佈

 

根據這個流程，狹義上的開發其實到流程②就已經結束了，由於以後從嚴格意義上來講都跟開發沒有關係了（撇開出bug返工fix的逆向流程來講的話）

可是每次發佈的時候，開發又必需要留守下來，雖然並不幹什麼事情，就乾等着，但就要你留下，否則萬一出現了問題怎麼辦。

 

以前發佈都是手工發佈，發佈的時候每一個機器都要人肉將發佈包拷貝過去，覆蓋，重啓下應用程序池。

人工作這些重複而又無聊的事情會發生什麼問題就很少說了：容易出錯，枯燥，難以標準化。

並且人肉發佈的時候常常直接將站點發布，因此有些站點正在處理某個請求中的時候就強行被kill了致使」每逢發佈必報錯「。

沒錯，你想知道何時發佈，你只要看異常量冒上來的那一下就是發佈的時間點了。。。

 

後面運維團隊搞了jenkins來作自動化發佈。

首先jenkins自己是個優秀的東西，但無賴總感受咱們是沒hold住它，首先並無解決」每逢發佈必報錯「的問題，另外發布時間看起來沒有明顯減小，最後以爲獨立jenkins感受就是Dev和Ops之間的那個壁壘（信息分割）。

 

 

TFS線上發佈流程的準備

後面就計劃用tfs來進行自動化的線上發佈

 

首先，咱們在原來的Release裏，新增了若干個環境映射爲線上環境

其中咱們有一些是分業務線的（一條業務線內，全部前->中->後臺的站點均維持同一個版本避免某些用戶終端發佈的時機不匹配的問題）就經過Release的Envrionment來進行區分

 

個別Environment裏是有2個相連的狀況，是由於某些業務線比較大，機器比較多，將好比10臺機器，分紅5個一組合計2組，發完第一組以後再發第二組這樣的分組發佈

 

而後咱們線上機器使用了Nginx來作軟負載，因此要進行線上發佈的話一個正統的流程應該是

①通知Nginx讓這個機器下線，而且可能要等待一段時間（等請求處理完畢）

②更新站點

③通知Nginx讓這個機器上線 

 

其中①和③由運維那邊準備好了專門的python腳本放在每一個機器的指定目錄裏，只要再發布的時候，遠程到被部署的機器裏執行下就行了

 

這裏面遇到了2個問題：

問題1：

「遠程到被部署的機器」這個問題，首先TFS自身的步驟裏沒這個玩意，因此本身特意研究了下Powershell研究如何動態的在指定的機器裏進行Invoke-Command （不枉當年略微瞭解過Powershell）

TFS裏能夠支持調用Powershell

最後搞出經過以下命令便可實現遠程到指定機器裏調用指定的命令

[sourcecode language='powershell'  padlinenumbers='true']

$username 能夠訪問機器的帳戶名
$password能夠訪問機器的密碼
$machine = 你的機器地址
$secstr = New-Object -TypeName System.Security.SecureString
$password.ToCharArray() | ForEach-Object {$secstr.AppendChar($_)}
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username, $secstr

Invoke-Command $machine -Credential $cred -ScriptBlock { 你須要在目標機器執行的命令 }
[/sourcecode]

問題2：

每一個要發佈的機器都要執行這3個步驟，想下一個機器3個Task，10臺機器就30個Task，30臺機器就90個Task，這還有要針對Task的一些變量配置，這茫茫大的配置量。。。

因而乎咱們使用了TFS的任務組功能，所謂任務組，就是能夠將若干個Task合併爲一個Task，而後在經過變量傳參的形式各個Task共享指定的變量

如：

經過任務組將3個Task合併爲一個，裏面包含」下線->更新->上線」全流程，一個任務組就對應發佈指定的一臺機器

 

而後吭哧吭哧的咱們將這些問題解決了，就基本上配置出了基礎的線上發佈方案，而後就開始…..翻車

 

發佈中遇到的一些問題

發佈緩慢

先說下咱們實際發線上的一個流程

咱們之前（TFS之前）是QA將程序包一直測試到預發佈（預生產環境）後，而後運維將預發佈的包同步到線上

用TFS天然而然也順着這個流程來，發佈預發佈的時候將包copy到某個共享目錄下，而後線上的發佈都經過去這個共享目錄裏拿

 

可是默認tfs的每個Release它都會將發佈包下載到發佈的代理agent裏，這個過程比較緩慢，拖慢總體速度

因而乎咱們就發佈的時候跳過項目下載，實踐證實這個操做能大幅提高發布的效率

 

發佈的時候站點的文件被佔用致使發佈失敗

這個特別是在Asp.Net Core裏幾乎必定會發生，.Net Framework看具體狀況但也極可能會遇到

通常而言的解決方案能夠經過勾選IIS發佈的時候Task App Offline解決（咱們經過這個解決了99%的問題）

但實際上咱們遇到了更變態的狀況（剩下的1%），有一個站點使用了別人家的COM組件致使用這招依然會有文件佔用的問題，這個能夠經過發佈的時候經過中止應用程序池搞定

 

折騰後的效果

經過上述修改，咱們基本線上的發佈透過TFS能跑的相對穩一點了

目前發佈的效果是：發佈期間站點性能有所降低，可是報錯量整體不會發生太大變化

起碼脫離了每逢發佈必報錯的時候了

 

因爲最近一直在測試線上TFS發佈（折騰了蠻久了）以前發佈的數據沒有了，不過看最近的一次發佈結果，基本沒發生報錯

有箭頭的位置就是發佈的時候（這個稍後會說是如何實現的）

紅色的是異常的數量

能夠看到最近的發佈裏，基本沒有紅色的了

 

附加值：與Dev的相關整合

因爲如今發佈使用上了TFS，而咱們Dev也是在TFS上的，因此如今咱們你們都在同一個工具平臺下了。

起碼能帶來一個顯而易見的效果是，有沒有發佈，和發佈完了沒，咱們你們直接透過TFS的面板就能看到了而不用跑過去問運維了。

 

另外說2個因爲發佈走TFS後跟咱們Dev整合的一些附加值

①自動拉備份分支

之前咱們已經就有這個機制，不過由於之前發佈不是走TFS，因此咱們是在發佈到預發佈的時候（預發佈歸QA管，以前作自動發佈流程時候就將預發佈之前所有搞好了）就自動拉

可是預發佈畢竟不是線上，到了預發佈也可能fix bug，因此不少時候備份分支特別多特別亂

而如今就是真正發佈到線上的時候纔會去拉備份分支，備份分支的備份就顯得更加的「真」了

 

②發佈的時候給監控系統打標記

上面異常量的那個圖裏看到的那幾個小箭頭

是每次自動發佈到線上的時候，TFS會跟Application Insights（咱們用的監控產品）說，我如今對某站點進行代號爲XXX（TFS內的發佈編號）發佈拉，給我打個標記）

Application Insights就會說，好的，收到了，箭頭已經打上，關聯上你給個人信息了

一切經過插件 Release Annotations for Azure Application Insights 來實現便可

而後我就能經過咱們的Application Insights的監控裏看到何時發生了什麼樣的版本變更

這個信息有什麼用呢？

好比你看到以下的圖的時候會聯想到什麼？（某接口的響應時間）

 

是否是瞬間就能看出來，是由於某次發佈致使某個接口的效率急劇變慢，不用猜，不用想，看圖說話。