從一個小 Bug，到 Azure 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

標籤：其他

上一篇：第3屆83行代碼大賽第2關賽題官方決議

下一篇：空格字符影響字串欄位的group分組嗎？論技能重要技巧更重要