在Azure DevOps Server（TFS系統）中部署回退/回滾方案（Rollback)

概述

Azure DevOps Server（以前名TFS）是微軟公司實現軟件研發、測試和部署一體化的全流程解決方案。在近幾年的研發過程當中，Azure DevOps Server 大幅加強了軟件部署過程的自動化功能。對於系統運維人員而言，確保軟件的穩定運行，是本身的第一工做目標。可是，在信息技術飛速發展的今天，信息系統的升級變動已經成了屢見不鮮。每週升級、天天升級、甚至一天升級數次，都已經見怪不怪。

爲了提升軟件的變動效率和質量，許多運維部門都使用部署腳本，實現系統升級的自動化。在軟件升級過程當中，爲了確保信息系統正常運轉，最大程度的下降由於升級致使系統宕機的風險，運維人員首先考慮的是回退（Rollback）方案。即，在系統升級過程當中，萬一出現因爲升級致使的異常情況，爲了最快恢復系統的正常運行，回退到部署前的版本，是一個運維人員恢復系統正常的首選方案。

在下面的內容中，咱們介紹在使用Azure DevOps Server實現部署過程當中，如何應用回退方案。

回退方案

在軟件部署過程當中，咱們能夠選擇多種回退方案：

1. 基於虛擬機的快照技術

在升級變動以前，爲即將發生變動的服務器建立快照，當系統部署失敗時，直接將虛擬機退回到建立快照時的狀態。

目前Azure DevOps Server支持包括VMware, SCVMM(Hyper-V）等多種虛擬化平臺。若是微軟原生的技術支持，通常虛擬化平臺都提供快照的API，能夠將API經過PowerShell、Shell等方式集成到發佈流水線中。下圖是在Azure DevOps中使用VMware和SCVMM的截圖：

圖1：Azure DevOps Server流水線中的SCVMM任務

圖2：Azure DevOps Server流水線中的vCenter任務

基於虛擬機快照的回退方案，簡單粗暴，可是卻很是適用。在手動部署過程當中，這種方案就是運維人員經常使用的方式。

可是虛擬機的快照並非萬能的，它存在許多不足，例如快照會消耗大量的磁盤存儲；若是是域環境中運行的虛擬機，快照還原可能出現脫域的問題；快照合併的時間較長等問題。在選擇使用快照技術做爲回退方案時，須要重複考慮快照還原對系統形成的影響。

2. 從新部署上一個版本

在Azure DevOps Server中，從新部署上一個版本，是最爲簡單和快速的方式。

Azure DevOps Server 最大的特色，是完整地保留了軟件研發運維過程當中的全部日誌、交付物數據，而且保護交付物數據的各類版本，其中就包括部署部署過程當中的每個版本。單本次部署失敗時，咱們能夠從上一次的部署中，選擇從新部署按鈕，實現一鍵回退功能。

例如，在下圖中，因爲四次部署是上一次成功的部署，而且系統運行正常，我選中從新部署，就能夠重複運行上一次部署的全部任務，而且在部署過程當中，使用上一次部署的升級包、環境變量等數據。

圖3：在Azure DevOps Server 中從新部署

若是你熟悉IBM UrbanCode Deploy，會發現Azure DevOps Server的從新部署功能與它的「Replace with Last Deployed」有殊途同歸之妙。經過從新部署上一次的版本實現回退，簡單快速。可是，問題也顯而易見，不必定可以實現系統回退的效果。這種方案只適合獨立運行的信息系統。

例如，當系統依賴與第三方系統運行，須要和第三方系統同步升級時，從新部署只能將本身的系統回退到了上一個版本，可是並不能將系統恢復到健康狀態，由於此時第三方系統已經完成了升級，可能第三方系統不能兼容你的上一個版本。一樣，若是當前版本對應的數據庫結構已經完成了升級，從新部署也不能恢復系統的健康狀態。

3. 中止自動部署，手動修復問題

程序員和運維工程師不是萬能的，相反，這是一羣最容易犯錯誤的人，由於他們實現的大部分需求，都沒有能夠照搬的方案。都是在開發過程當中，不斷試錯，實現信息系統的增量發展。一樣，在部署過程當中，每次都存在許多不肯定因素。當發現部署問題時，分析緣由找到解決方案，並修復問題，將當前環境恢復到健康狀態。同事，將解決方案集成到系統源代碼或者部署腳本中，做爲下一個版本的部署內容。

固然，做爲程序員，咱們能夠提高系統部署智能化，提升部署過程當中錯誤探測和解決的自動化水平，這也是後面要重點介紹的方案。

4. 在流水線中部署回退腳本

在Azure DevOps Server 中，發佈流水線由一個一個的任務組合而成。在發佈過程當中，系統按照流水線中配置的順序，執行每個階段中的任務。當發佈流水線中的中的任何任務失敗時，對應環境的部署可能會失敗。爲了讓環境恢復正常，咱們能夠執行一個回滾腳本Shell (on Linux)或PowerShell(on windows)。腳本自己須要具如下要求:

• 當部署工做流中的任何任務失敗時，對環境的部署可能會失敗。爲了讓環境恢復正常，咱們將執行一個回滾腳本。即便在另外一個任務失敗時，腳本自己也會爲環境執行腳本。經過Azure DevOps的發佈管理，您可使用PowerShell或shell任務來實現此目的，並將其標記爲「始終運行」。這樣，不管部署成功或失敗，腳本都將始終獲得執行。
• 若是前一個任務失敗，則應跳過未標記爲「始終運行」的任何任務，但將執行始終運行的任務。根據部署失敗的任務對環境進行選擇性更改。執行腳本只是任務的一半。爲了不破壞任何不須要的東西，咱們須要瞭解更多內容。首先，咱們須要檢測是否有故障。若是失敗了，那麼什麼任務失敗了。目前，腳本中沒有一種方法能夠了解這些內容。咱們須要在腳本中查詢這些版本。幸運的是，Azure DevOps 的市場（https://marketplace.visualstudio.com）中擴展插件「Release Management Utility tasks」（https://marketplace.visualstudio.com/items?itemName=ms-devlabs.utilitytasks），其中包含了一個任務「Powershell to rollback」，這個任務能夠協助咱們，使回退腳本變得更加簡便。若是你想驗證下面的腳本，須要將這個擴展安裝在你的Azure DevOps Server中。

下面咱們來演示如何實現這個功能：

首先，編寫回退腳本，並將其推送到代碼庫中，例如個人回退腳本以下：

echo $env:Release_Tasks

try

{

$jsonobject = ConvertFrom-Json $env:Release_Tasks

}

catch

{

Write-Verbose -Verbose "Error parsing Release_Tasks environment variable"

Write-Verbose -Verbose $Error

}

foreach ($task in $jsonobject | Get-Member -MemberType NoteProperty)

{

$taskproperty = $jsonobject.$($task.Name) | ConvertFrom-Json

echo "task name: $($taskproperty.Name)"

echo "task rank: $($task.Name)"

echo "task status: $($taskproperty.Status)"

echo "Task $($taskproperty.Name) with rank $($task.Name) has status $($taskproperty.Status)"

$task_status=$taskproperty.Status

if($task_status -eq "failed")

{

Write-Warning "This is a error generated in a PowerShell script"

}

}

而後，在發佈流水線中添加回退任務。注意須要將其標記爲老是運行「即便上一任務已失敗，即便已經取消部署」：

最後，咱們看一下回退腳本運行的結果：

在上圖中，能夠看到回退腳本順利運行，下圖是回退腳本的輸出：

在上面第4個方案中，咱們只是介紹了基於Azure DevOps Server 的回退機制，而具體的回退腳本，須要根據系統部署的內容來定。須要開發人員或者運維人員根據本次變動的具體內容編寫腳本。例如文件的變更，則須要編輯將備份文件覆蓋回來；若是數據結構的變更，則須要更改數據庫。

微軟DevOps MVP 張洪君 http://www.cnblogs.com/danzhang

--End--