構建Windows：400萬次提交，1000萬個工作項目

微軟談到了將Windows開發移植到VSTS所做的一些工作。

微軟轉向使用Git作為Windows開發的版本控制系統已經帶來了很多挑戰。Git並不是真正為擁有350萬個文件的300GB存儲庫構建的，並且以這種方式進行Git擴展的工程設計仍在繼續。

但在採用和開發公司所稱的One Engineering System（1ES）時，Windows和設備部門（WDG）採用的不僅僅是Git; 該組織還採用了Visual Studio Team Services（VSTS），該公司的源代碼管理，項目跟蹤，集成和測試系統，以及VSTS更為集成的開發人員風格的開發方法。Git是這個的重要組成部分，但遠離整個故事。微軟今天寫了關於使用VSTS的一些經驗，包括操作規模造成的一些問題。

在WDG中採用VSTS功能和devops實踐並不統一。持續集成和持續交付對於WDG在線服務的某些部分來說是有意義的一個例子，甚至Microsoft Store中的一些應用程序也可以獲得資格 - 但它們不太適用於核心Windows操作系統本身。儘管如此，該公司一直致力於標準化每個組件所共有的實踐。

Fall Creators Update（版本1709）很好地演示了Windows的操作有多大。該更新包含大約400萬次提交，分組為50萬次pull請求，以將這些更改合併到主Windows代碼中。每個pull請求 - 一組代表新功能，bug修復或類似功能的更改組合成一個請求，將一些更改合併到主分支中，並將這些更改合併到主分支的最新版本中。如果兩個pull請求同時被接受，它們都會嘗試合併到當前的版本中，這樣一個會成功，另一個會失敗; 它將不得不針對包含已接受請求的新當前版本進行重試。天真地做，這會為每個拉取請求創造大量浪費的工作。

在具有正常數量的開發人員的典型項目中，拉請求的數量通常足夠低，以至於沒有人試圖同時合併兩個請求，所以這種情況幾乎不會發生。事實上，如果只有一個人接受拉取請求 - 這是小型開源項目的常見情況 - 這絕不會發生。但對於Windows來說，大量的pull請求和更改意味著主分支幾乎總是被更新，這使得兩個pull請求更有可能嘗試同時合併。因此，拉取請求即使在被接受後也會失敗。為了解決這個問題，微軟添加了一個排隊系統以便接受的請求被自動順序執行; 他們不會相互競爭，系統可以削減浪費的工作，這是一個天真的系統否則必須做的事情。

這對於1ES來說是一個反覆出現的問題：對於小型團隊來說很好，對於7000名開發人員和4000名設計師，項目經理以及在WDG內部工作的服務工程師而言，產品無法使用。再例如，常規VSTS使用用戶名下拉框將工作項目分配給人員。當一個項目只有少數開發者時，該系統運行良好，但微軟在VSTS中總共擁有大約80,000個帳戶，這些帳戶太多而無法在單個下拉列表中列出。

公司有很多工作項目。微軟的做法是將工作項目用於一切; 例如，錯誤和新功能都是工作項目。從歷史上看，該公司提供了廣泛的內部訪問錯誤跟蹤功能，但跟蹤新功能更加不透明，僅對於從事特定功能的團隊或部門才可見。使用1ES時，這些內容全部記錄在VSTS系統中，具有全公司範圍的可見性和總共約1,000萬個工作項目。

通過這種改進的可見性，可以創建交叉劃分依賴關係，以便例如可以將Visual Studio或Office功能設置為依賴於Windows功能。這些項目的進展情況也可以跟蹤，以確保在正確的時間發貨。在1ES之前，該公司有五種不同的方式來跟蹤這些依賴關係。

進入1ES的工作不僅涉及為Windows開發構建通用系統，還涉及這些進程的常見過程和命名。之前，不同的團隊可能會使用術語「錯誤」或「問題」或「缺陷」，並且在解決這些問題時，這些錯誤可能是「完整的」，「完成的」或「關閉的」，具有處理它們的不同工作流程。在彙集不同群體時，術語和流程正在標準化，從而實現更好的報告和更容易的數據流之間的通信。

微軟使用WDG在Git方面的經驗來對開源軟體提出修改建議，並且在過去的一年中一直致力於將這些改變融入Git本身。適用於VSTS的縮放工作也是如此。例如，WDG希望能夠創建VSTS數據檔案; 此功能通常很有用，並於2016年作為開源VSTS擴展發布，用於VSTS帳戶之間的歸檔和數據遷移。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！