首頁 > 科技 > 正文

為何Google、微軟、華為將億級源代碼放一個倉庫?

更新日期:2019-10-23 15:56:50

作者 | 夕顏

編輯 | Just

出品 | AI 科技大本營(ID:rgznai100)

【導讀】2017 年,在當時微軟的一篇官方博客中,時任微軟云開發服務副總裁的 Brian Harry 表示微軟內部代碼開始向 Git 遷移,宣布推出針對大規模 repo 的“Git虛擬文件系統”GVFS(后更名為 VFS For Git)。他激動地分享了微軟公司 4000 名工程師采用這個代碼管理倉庫后三個月的運行良好狀況,稱其解決了很多 Git 存在的問題。

時隔兩年之后,這篇文章中對 VFS For Git 代碼管理技術思路的介紹仍然值得借鑒。

大型科技公司本身擁有龐大的代碼數據,并且每天都在產生數量巨大的新代碼,如何管理代碼和版本成為備受關注的問題。很多公司會選擇將代碼托管于 Git 等第三方代碼托管平臺,但近年來,將代碼管理交給公司自己開發的統一倉庫成為一種趨勢。如微軟的 VFS For Git 就是一個典型案例。

大公司應該如何進行代碼管理?微軟研發并采用 VFS For Git 的過程和這個系統本身有哪些可以借鑒的地方?為了更深入了解 VFS For Git 和代碼管理相關問題,AI科技大本營(ID:rgznai100)采訪了微軟亞洲研究院首席研發經理鄒欣,他對這些問題進行了解答。

為什么要做 VFS For Git?

鄒欣回憶,在將代碼遷移到 GVFS 前,微軟曾使用多個主要的代碼管理平臺,包括 SLM, Source Depot (上世紀 90 年代開始)、TFS 的源代碼控制 TFVC (2006 年開始)。直到 2017 年,微軟用三個月的時間完成代碼遷移到 Git,并推出了 Git 的變種,針對特大 repo 的 GVFS,并沿用至今。

GVFS 是一個 Git 虛擬文件系統,全稱為 Git Virtual File System,允許 Git 處理 TB 規模的代碼庫,比如 270 GB 的 Windows 代碼庫。GVFS 的 V 就是 Virtual(虛擬),它解決了Git 原來的設計缺陷(每個客戶端都有所有版本的代碼),而是用虛擬文件來代替那些本地用不著的文件, 大大減少了文件傳輸和本地機器存儲的壓力,讓微軟內部技術人員可以進行高效協作。

一段小插曲是,GVFS 從發布之初就引起了爭議,原因是 GNOME 項目的虛擬文件系統也叫 GVfs,而 GNOME 的 GVfs 最早發布于 2006 年,之后的教程、文檔、論壇都沿用這個名字。在微軟的 GVfs 項目發布后,很快超過了 Gnome GVfs 項目的搜索排名,且由于二者都與虛擬文件系統有關,導致用戶在查找信息時容易出現混淆。于是,很多開發者要求微軟改名,經過一番周折后,微軟終于在 2018 年將 "GVFS" 項目的名字改為 "VFS For Git"。

鄒欣表示,當時微軟將代碼遷移到 Git 主要是為了統一微軟百花齊放的內部工具,并沒有一個絕對好的選擇,領導團隊選擇了 Git, 但從現在的結果來看,這是一個比較好的選擇。如今,微軟仍然在對 Git 系列的工具做改進,也把改進回饋到 Git 社區。

現在,VFS For Git 已經是微軟內部統一的工具,同時被其他大型企業采用:https://vfsforgit.org/

VFS For Git 在 GitHub 上也已開源:

GitHub開源地址:https://github.com/microsoft/VFSForGit

單一自研代碼管理倉庫是最好的選擇嗎?

除了微軟,我們發現,很多大公司的代碼托管已經向自己內部開發的版本控制系統遷移,比如 Google 就把使用不同語言編寫的超過 10 億文件,近百 TB 源代碼都存放在自行開發的版本管理系統 Piper 中,只當項目開源且需要外部協作時,才會使用業界流行的 Git。(詳見文章《為何Google將幾十億行源代碼放在一個倉庫?》)

再如華為的內源(Inner Source)平臺,承載著華為 1100 億源代碼、60 萬+ 代碼倉庫、每天 60 T 的下載容量、1 萬次/秒的高峰并發下載。

這是否說明在大公司中流行的單一倉庫就是最好的做法?這些公司在選擇采用代碼托管方式時需要考慮哪些不同的問題?

鄒欣解釋,在他看來,用 GVFS 也可以創建各種獨立的倉庫。用一套工具有利于公司內部進行代碼共享,讓人員流動、代碼復審、改進工具變得更簡單,效率提高。

其次,大公司有很大量的代碼,很長的歷史和很多工具,如果貿然選擇一個新工具就會出現以下問題:

a) 一些市面上的工具并不是為大規模代碼設計的,處理不了大量代碼, 我們以前用第三方的代碼分析工具, 結果處理 Office 的代碼的時候,自己崩潰了,因為 Office 的代碼量太大,這個工具的開發者沒有為如此大的代碼設計軟件。

b) 很多工具在歷史中不斷演化, 有自己獨特的特點,很多和企業內部的某些特殊需求有關,外部工具很難都實現這樣的功能。

很多工具聯合在一起,會形成了一個工具的生態,但如果只改變一個工具,讓其他的工具變得不兼容, 那整個團隊的很多工作流就會出現問題。

此外,鄒欣表示,代碼托管與 AI 結合是未來發展方向。例如,這種結合會告訴你昨天晚上簽入代碼有問題, 或者簽入代碼和某個其他團隊的代碼相似,建議重用。或者告訴你簽入的代碼是從網上拷貝來的, 而且把原來代碼中的 bug 也拷貝過來了。

最后,AI 科技大本營引用此前微軟云開發服務副總裁 Brian Harry 于 2017 年發表的一篇博文內容,在微軟推出 VFS For Git 三個月后,他分享了該平臺的更多細節及其未來目標,包括擴大開放源代碼并改善其在 Microsoft 上的運行表現,想要了解 VFS For Git 更詳細的信息,不妨仔細研讀一下這篇文章:

用 Git 管理 Windows

在過去三個月中,我們已經基本完成了向 Microsoft Windows 團隊推出 Git/GVFS 的工作。

Windows 代碼庫大約有 350 萬個文件,當遷入 Git 版本庫時將產生 300GB 的存儲量。此外,Windows 團隊約有 4000 名工程師,這個龐大的工程師系統每天都要處理成千上萬次驗證請求,在 440 個分支里進行 1760 次實驗性變更。在所有的三個維度(文件計數、版本庫大小和活動)都是令人生畏的擴展挑戰,這些因素夾雜在一起使得這個工作變得異常困難。在遷移到 Git 之前,這些數據儲存在 40 多個不同的倉庫里,我們需要跨越多個庫進行操作。

在我三個月前撰寫文本的時候,我們將所有代碼都儲存在一個 Git 版本庫里,幾百名工程師在很小一部分日常構建(<10%)中使用并對它進行了測試,自此我們在整個工程團隊里掀起了波瀾。

第一次也是最大的一次事件發生在 3 月 22 日,當時我們向擁有約 2000 名工程師的 Windows OneCore 團隊推廣了 Git。他們周五在 Source Deport 上工作,周末回家,然后周一上班時體驗 Git 的效果。我們團隊中的每個人在周末時都屏住呼吸,祈禱周一上班時不會被一幫丟了代碼的暴怒工程師圍毆。但事實上,Windows 團隊在備份方案方面做的非常出色,也謝天謝地我們并沒有使用到這些方案。

老實說我對于事情進行的那么順利還是很驚訝的。毫無疑問我們遇到了一些問題,由于龐大的團隊規模和工作性質的問題,Windows 通常會在各個分支部門之間進行大合并,導致每個小變更都會引發多個部門的共同改動。第一周時我們發現我們提出需求和解決矛盾的 UI 根本無法應對這么大規模的共同變動。我們手忙腳亂地把列表虛擬化并逐步獲取數據,以便 UI 不至于忙到掛起。我們在幾天之后解決了這個問題,總體來說,這周的體驗比我們想象的要好得多。

我們衡量成功的方法之一是在工程師團隊中進行滿意度調查。除了核心問題“你對它滿意嗎?“,我們還提出了一些小問題。兩周之后我們第一次調查結果如下:

從上往下分別為:非常滿意,還算滿意,不太滿意,非常不滿意

我們沒有為這個調查結果開個派對慶祝,但作為一個歷經千難萬險不斷學習新技術的開發團隊,我們對這個進步還是非常開心的。2000 個人的團隊只有 251 個人回復了我們的調查,我們歡迎更多的人給予我們評價。

另外一個衡量成功與否的方法是查看“工程活動”以調查工程師們是否完成工作。例如,我們計算了官方分支的使用“簽到數”,團隊中有一半工程師使用 Source Depot ,另一半遷移到了 Git 上,因此我們對一段時間內的綜合活動進行了研究。在下面的圖表中,Source Depot 的簽到數大幅下降,而從 Git 輸出的請求大幅躍升,但兩者的綜合保持相對一致,我們認為該數據表明這個系統正在無阻運行。

每日檢出量

4 月 22 日,我們邀請新一批約 1000 名工程師加入測試隊伍,5 月 12 日我們又邀請了 300-400 名。每一批新加入的工程師都差不是相同的工作模式,目前 Git 上有 3500-4000 名微軟工程師。其余的小組正在按時完成工作并計算遷移計劃的最佳時間點,我預測接下來的幾個月里應該能完成整個工程師團隊的遷移。

整個系統的規模令人驚訝,讓我們看一些數字...

- 過去 4 個月里,有超過 250000 個可以追溯的 commit

- 平均每天 8421 次 push

- 平均每個工作日 2500 次 pull 請求和 6600 個回復的人

- 4352 個活躍主題分支

- 每天 1760 個由官方搭建(build)的測試

如你所見,這個巨大的版本庫里正在進行著大量的活動。

GVFS 的大規模性能

在滿意度調查里,有部分工程師對這個系統表示不滿。我們有大量數據來解釋原因—-從部分工具尚不支持 Git 到學習新知識的沮喪感。但我想深入研究一個首要問題:Git 本身的性能。我們知道當我們推出 Git 時還有很多工作尚未完成,還有很多新東西不斷加入。我們跟蹤一些Git關鍵操作的表現。以下是遙測系統從大約 3500 名工程師里收集到的 GVFS 使用數據。

表中的目標代表最糟糕的情況,如果系統的運行時間高于此值則無法使用,這并不是“我們希望系統在這個范圍”的值。對比前7天和后7天在80%位點上的變化量,所有的數值都在變慢。

如果在工作開始之前使用 “Vanilla Git”,許多指令可能需要30分鐘到幾個小時都無法完成。為了一個只需要20秒的指令等待10-15秒是一個很糟糕的事情。

當我們第一次推出它時,結果要好得多。事實證明,隨著時間流逝,工程師從代碼庫里學習的越來越多,從而導致了我們稱為“過度飽和”的問題。最終工程師只是獲得了一堆偶爾使用、不再進行修改的廢文件。這導致了性能的逐漸下降。人們可以將這些文件加入清理,但這很麻煩,也很少人這么做,久而久之系統越來越慢。

這啟發了我們開始另一輪稱為“O(modified)”的性能優化,它將許多關鍵指令更改為與用戶修改過的文件數量成正比。我們將在下周把這些修改推廣到團隊里,所以目前還沒有統計數據,但參加早期測試的用戶普遍反映良好。

我沒有全部數據,但我從上個表格中選擇了一些事例并把表現結果復制到“O 飽和(hydrated)列”,使用下周將要推出的性能增強后得到的執行結果列為“O 改動(Modified)”。所有數字都以秒為單位。從表中我們可以看到性能有了全面提升—有些很小,有些大約2倍,狀態快了將近5倍。我們非常樂觀,這些改動將提高用戶體驗。雖然我永遠不會滿足(直到狀態低于1秒我才會滿意),但這個進步還是讓我開心。

影響表現的關鍵因素還有分布式團隊。Windows 的工程師遍布全世界—美國、歐洲、中東、印度和中國等。長距離大范圍拉取數據是一個問題。為了解決這個問題,我們花大力氣構建了一個用于 GVFS 的 Git 代理解決方案,該方案讓我們能夠“在邊緣”緩存 Git 數據。我們還在高峰負載期使用 Visual Studio 團隊服務分擔了大量流量,避免損害用戶體驗。總的來說,我們在全球范圍內有 20 個 Git 代理。

讓我舉個例子,Windows 團隊服務賬戶位于美國西海岸的 Azure 數據中心。在這個地方,Windows 工程師克隆速度的 80% 位點為 127 秒。這是由于我們大部分微軟工程師都在Redmond,這個數據主要是由他們主導。我們在北卡羅萊那州的辦公室(距離我們很遠并且寬帶較低)進行了測試。不使用代理服務器的情況下,從北卡羅來納州進行克隆需要25分鐘,而在配置了代理服務器并保持更新的狀態下,該過程僅花費了 70 秒(比 Redmond 更快,因為 Redmond 團隊比使用代理服務器,他們必須通過網絡跨越數百英里到達 Azure 數據中心)。從 70 秒到 25 分鐘,性能提升了將近 95%。

總體來說,搭載 GVFS 的 Git 完全可以在大規模情況下有效地被使用。同時,我們做了大量工作使工程師們對它的表現表示“滿意”,但在我們完成整個項目前,我們仍然有很多可以改進的地方。

開發者試用 GVFS

GVFS 是一個開源項目,任何人都歡迎來嘗試一下。你只需要下載和安裝,創建一個帶有 Git 版本庫的 Visual Studio 團隊服務賬號就可以開始使用。自從我們最初發布 GVFS 以來,我們已經取得了很多不錯的進步,一些主要的改進包括:

我們對已經發布的代碼庫進行定期更新—正朝著“公共開發”邁進。截至目前,我們所有的最新變動(包括O 改動(modified)的改進)均已發布到公共庫里,我們將定期對其進行更新。

GVFS 依賴于名為 GVFIt 的 Windows 文件驅動系統。目前為止,我們提供的該驅動程序還正式試用(因為還有很多進行中的工作),顯然這導致很多測試沖突。今天我們發布了簽名版本的 GVFIt 并消除了這個問題(例如用戶不再需要禁用 BitLocker 后才能安裝它)。盡管我們有試用的 GVFIt 驅動程序,但這并不是一個可維持的交付方式,我們希望這個功能可以組合進未來的 Windows 發行版里。

從我們在 Git Merge 的演講開始,我們針對 Git 和 GVFS 擴展問題與更廣泛的Git社區進行了互動。在與其他大型科技公司(例如谷歌和 Facebook )進行了對話時,我們發現他們也面臨著類似的挑戰,所以向他們分享了經驗與方法。我們還與一些熱門的 Git 客戶合作,以確保他們在 GVFS 上的順暢體驗,包括 Atlassian Source Tree、Tower Git 團隊、Visual Studio、Git for Windows 等。

總結

我們將繼續努力把 Git 擴展到足以支持大型團隊的代碼庫,從第一次記錄這些工作已經過去了三個月,這期間發生了很多事,我們團隊已經...

- 成功將其推廣給3000個微軟工程師

- 進行了一些重大的性能改進并引入了 Git 代理

- 用最新代碼更新了開源項目,并開始歡迎外部幫助

- 提供了簽名版本的 GVFIt 驅動并降低了它的使用難度

- 與社區合作,為熱門工具(SourceTree、Tower、Visual Studio等)提供支持

- 發表了一些文章分享我們對 Git 和 GVFS 使用技術的更多見解

不論對微軟團隊還是我的團隊,這都是一個激動人心的改變。這是一個極具挑戰的項目,我為進步歡呼,也為剩下的工作頭疼。目前,Visual Studio 團隊服務是唯一支持 GVFS 協議增強功能的后端實現。如果市場反應夠強,我們會與 Team Foundation 服務器和其他 Git 服務洽談添加支持。

https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/

【END】


相關:

鄭愷邀大學同學游丹麥 彌補缺席畢業旅行遺憾  中新網10月23日電 明星旅行電影式慢綜藝《慢游全世界》上周播至第二期,迪麗熱巴希臘之旅引發熱議,節目再次收獲好評。本周,鄭愷將邀請大學同學王文娜、張殿倫,畢業十年后遠赴丹麥,彌補十年前遺憾缺席的畢..

第32屆電影金雞獎提名揭曉 《過昭關》獲四項提名  中新網10月23日電 22日,第32屆中國電影金雞獎提名名單揭曉。由青年導演霍猛執導的電影《過昭關》喜獲第32屆中國電影金雞獎四項重要提名,分別是最佳中小成本故事片、最佳導演、最佳男主角、最佳男配角。 《..

黑龍江截獲首例越南入境檢疫性有害生物番石榴果實蠅  中新網哈爾濱10月23日電(騫壯 姜輝)23日,哈爾濱海關發布消息,哈爾濱海關所屬哈爾濱太平機場海關截獲中國東北三省及內蒙古地區首例由越南入境檢疫性有害生物番石榴果實蠅。   據哈爾濱太平機場海關旅檢三..

相關熱詞搜索:封條模板 封狼居胥 封神傳奇 網游之傳奇再現 網游之演技一流網游之金庸奇俠傳

上一篇: 電信運營商威瑞森將為其用戶免費提供一年的Disney+
下一篇: 《財富》2019全球未來50強排行榜:順豐排名第9

258竞彩手机彩票网