從一個小Bug，到Azure DevOps

2021 年 11 月 27 日
筆記
Azure DevOps, DevOps

1. 一個小Bug

最近和同事提起一個幾年前的 Bug，那是一個很小很小的 Bug，沒什麼技術含量。那時候我剛入職，正好公司賣了一款儀器到某個國家，但是那邊說配套的軟體運行不起來，一打開就報錯。經過排查發現出錯的程式碼很簡單，大致是這樣：

public static int GetSecond(DateTime time)
{
    return Convert.ToInt32(time.ToString().Split(":")[2]);
}

當時真是哭笑不得。這段程式碼應該是從舊語言遷移過來，如果只在中國完全沒問題，但放到國外就可能報錯，因為不同地區和語言會有不同的時間格式，例如加拿大的時間顯示格式就不一樣，秒的後面還帶了表示上午/下午的 a.m/p.m.，這一點可以通過在程式碼中更改 Thread.CurrentThread.CurrentCulture 來驗證：

var time = new DateTime(2000, 1, 20, 1, 2, 3);
Console.WriteLine(time); \\ 輸出 2000-01-20 1:02:03
Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-CA");
Console.WriteLine(time); \\ 輸出 2000-01-20 1:02:03 a.m.

至於測試人員，可以通過將系統設置中的「時間和語言- > 語言&區域」中的區域格式為英語(加拿大)來驗證：

可是無論開發人員還是測試人員都沒有發現有問題，當時這個離譜的 Bug 就這樣插著翅膀，飛越高山和大海，飛到了國外客戶的手上。整個團隊上上下下由開發到測試都沒發現整個 Bug，也許團隊在技術和流程上都有問題，讓我不得不懷疑我進了個大坑。

吃一塹就要長一智。雖然只是一個小 Bug，但也反映了團隊技術和程式碼流程的欠缺。為了避免再發生這種情況，需要從團隊培養及流程改善兩個方面著手。團隊培養是另一個話題，這篇文章只說說流程改善。當時我們已經在使用 TFS（Azure DevOps 的前身），不過只用於程式碼管理，很多功能都沒有用到。後來 Azure DevOps 不斷改善，我們也使用了它更多的功能來幫助我們改進產品品質。這篇文章以文章開頭的那個小 Bug 為例，簡單講解 Azure DevOps 處理它的流程。

2. 在 Azure DevOps 上記錄並開始處理這個 Bug

首先假設我已經在 Azure DevOps 管理程式碼，並且配置好 Pipeline 等基礎設施，我現在只需要處理這個 Bug。

第一步，添加一個 Bug。除了Bug 的標題，Bug 的詳細內容里還可以添加重現步驟、系統資訊等，如果有錯誤日誌的話還可以作為附件添加到這個 Bug 里。

當團隊理解並同意了這個 Bug 的內容後，在 Boards 中將它從 New 拖動到 Approved，並在 ··· 的下拉菜單中選中 Add Task 和 Add Test 分別添加任務和測試用例。

我隨意添加了兩個任務以及一個測試用例。

3. 在 Visual Studio 中修復 Bug 並添加單元測試

之後輪到團隊中負責處理這個 Bug 的開發人員接手工作。打開 VisualStudio 新建分支，修復這個 Bug，並根據單元測試 Arrange、Act、Assert 的方式添加一個對應的單元測試：

[TestMethod]
public void GetSecond_DifferentCultureInfo_Succeed()
{
    var time = new DateTime(2000, 1, 20, 1, 2, 3);
    Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-CA");
    var second = DateTimeUtils.GetSecond(time);
    Assert.AreEqual(second, time.Second);

    Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("zh-CN");
    second = DateTimeUtils.GetSecond(time);
    Assert.AreEqual(second, time.Second);
}

運行單元測試，確保所有單元測試都通過後在 Git 更改 面板提交這個 Bug 的資訊，並且輸入關聯的工作項的 ID，然後點擊 全部提交並推送。

推送成功後回到程式碼編輯器，可以看到被修改的函數上的 CodeLens 有一個待變單元測試通過的綠色圖標，滑鼠放上去可以顯示它被哪些單元測試驗證過。

在被修改的函數及相關的單元測試的 CodeLens 最右邊顯示「4個工作項」，滑鼠放上去可以看到之前提交程式碼時關聯的工作項。

4. 在 Pull Request 中驗收程式碼

接下來的操作需要回到 Azure DevOps。新的程式碼不能隨隨便便就簽進去主分支，需要創建一個 PullRequest 通知相關人員這個程式碼變動，並在這個 Pull Request 里記錄關聯的工作項，經過修改的程式碼，需要誰來 Code Review 等。聽起來很多，其實提交程式碼的開發人員只需要點擊創建 Pull Request，選擇要合併的分支，然後點擊創建，其它內容幾乎都由 Azure DevOps 自動填充。

Pull Request 最起碼需要兩道把關，一個是自動運行的單元測試，它需要程式碼里所有單元測試都運行並且通過。另一個是 Code Review，Azure DevOps 可以設置各種 Code Review 策略，包括最少的 Code Review 人數、當有變更時重置所有審核等。Code Review 除了保證簽入的程式碼品質，還是程式碼集體所有的一個體現。程式碼集體所有是敏捷中一個重要的要素，它確保團隊中知識的傳承，並促進能力的提升。

下圖是一個已完成的 Pull Request，可以看到幾個綠色的代表通過的圖標，代表它通過了多少道「工序」。還可以看到它關聯的工作項，由誰創建，由哪個分支合併到哪裡等資訊。

切換到 Files 選項卡，可以看到具體的程式碼變更：

5. 測試驗證與測試用例

完成上面的步驟後將 Bug 從 Approved 拖動到 Committed，並且將關聯的兩個 Task 設為完成。程式碼合併到 master 後 Azure Pipeline 將自動編譯並部署好最新的程式碼，然後通過郵件或 Teams 通知給相關測試人員。測試人員在收到通知後打開 Board，當它看到這個 Bug 的全部 Task 都已經完成（黃色圖標旁邊的 2/2），他就知道應該開始進行測試驗收。完成測試後在測試用例右邊的 ··· 下拉菜單中選擇測試結果，順利的話選擇 Pass test，並且把這個 Bug 拖到 Done。

到這一步 Bug 的處理已經完成。為防止錯誤再次發生，開發人員添加了單元測試，並且所有相關人員都通過這個流程分享了經驗，無論是程式碼或是團隊都變得更加強大。但這還不是結束，這個 Bug 里包含的測試用例是它留下的另一份寶貴財產，需要謹慎對待。打開這個 Bug，可以在右下角 Tested By 部分看到它的測試用例。

點擊這個測試用例查看詳細資訊，可以看到它的 Steps（這裡我懶得寫），以及各種關聯的工作項。

Azure DevOps 提供了 Test Plans 模組，用於管理測試用例和測試計劃。在開發過程中產生的各種測試用例最終彙集成測試計劃，由測試人員確保曾經正確運行過的功能不會再次出錯。不過這部分只開放給收費用戶，有機會再詳細介紹它的各種功能。

6. 最後

現在公司的程式碼已經在 Azure DevOps 上安了家，一系列流程都運作得很暢順（雖然還有很多很多可以改進的地方），儘管軟體功能膨脹了幾倍但售後回饋的問題反而更少。回過頭來看看幾年前那個 Bug，當時的程式碼生產方式和程式碼品質與現在真的有天壤之別，這其中 Azure DevOps 功不可沒。

最後提醒一下，如果想嘗試 Azure DevOps 可以不依照我寫的流程。這篇文章介紹的流程只是個簡化版本，實際工作起來稍微不同，而且應該根據自己團隊的實際情況靈活改變，打造屬於自己和自己團隊的流程（幸好 Azure DevOps 可以做到相當靈活）。

關於 Azure DevOps 的更多內容請參考官方文檔：

Azure DevOps documentation _ Microsoft Docs

Tags: Azure DevOps DevOps