查看原文
其他

为何Google、微软、华为将亿级源代码放一个仓库?

程序人生 2019-11-27

以下文章来源于AI科技大本营 ,作者CSDN App

作者 | 夕颜

编辑 | 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/

 热 文 推 荐 羡慕!支付宝招“找茬程序员”,一次最高奖励 36 万,年薪无上限!漫画:什么是狭义相对论?面试官问我:谈谈对 Java GC 的了解?回答完让我回家等消息....

全新语音 AI 芯片、两大 AI 开发者平台重磅推出,全方位解读科大讯飞全球 1024 开发者节!

欧洲为何没有牛逼的互联网公司

强大人脸检测系统MTCNN可攻破?华为提出一种可复制、可靠的攻击方法

你点的每个“在看”,我都认真当成了喜欢


    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存