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