谷歌的代码管理

作者: 阮一峰

日期: 2016年7月 2日

谷歌和 Facebook 都只有一个代码仓库,全公司的代码都放在这个库里。

我一直很困惑,为什么要这样做,不同语言的项目放在一个库有什么好处?

最新一期的《ACM通信》(59卷第7期)有一篇论文《为什么 Google 要把几十亿行代码放在一个库?》,作者是谷歌基础设施小组的工程师,可以看作官方对这个问题的详细解答。我读后感到收获很大,下面就是摘录。

一、概况

谷歌最早使用 CVS 进行代码管理,1999年改为 Perforce。那时是一台 Perforce 主机,加上各种缓存机。

当时,全公司的代码就在一个仓库里面,后来一直沿用这种做法。由于规模不断增长,Perforce 已经无法满足需求,谷歌就开始使用自己开发的版本管理系统 Piper。

Piper 架设在谷歌自己的分布式数据库系统(以前叫 Bigtable,现在改名 Spanner)之上,分布在全世界10个数据中心,保证世界各地的谷歌员工都有良好的访问速度。

目前,这个代码仓库包含10亿个文件、3500万次提交记录,大小为86TB,用户达到几万人。工作日每秒有50万次请求,高峰时80万次,大部分来自自动构建和测试系统。

谷歌90%以上的代码,放在 Piper 里面。对于那些开源的、需要外部协作的项目,代码放在 Git,主要是 Android 项目和 Chrome 项目。Git 的特点是,所有历史记录都会复制到用户的本地机器,所以不适合大型项目,必须拆分成更小的库。以 Android 为例,该项目一共包含800多个独立的仓库。

二、Piper 的设计

2.1 结构

整个仓库采用树状结构。每个团队有自己的目录。目录路径就是代码的命名空间。每个目录都有负责人(owner),他负责批准该目录的文件变动。

2.2 权限控制

Piper 支持文件级别的权限控制。99% 的代码对所有用户可见,只有少部分重要的配置文件和机密的关键业务,设有访问限制。

如果机密信息不小心放上了 Piper,文件可以被快速清除。并且,所有的读写都有日志,管理员能够查到谁读过这个文件。

2.3 工作流

Piper 的工作流(workflow)如下图。

开发者先创建文件的本地拷贝,这叫做"工作区"(workspace)。完成开发后,工作区的快照共享给其他开发者进行代码评审。只有通过了评审,代码才能合并到中央仓库。

2.4 客户端

大多数开发者通过一个叫做 CitC 的客户端,访问 Piper。

开发者通过 CitC 浏览和同步 Piper 上的文件,但是编辑和修改是在自己工作区,里面只保存有变动的文件(一个工作区一般不超过10个文件)。CitC 带有云储存机制,每个工作区就是云上的一个目录。通过代码评审以后,这些文件才从 Citc 合并进 Piper。

不使用 CitC 也是允许的,所有代码保存在本地,最终用 Git 客户端提交到 Piper。不过,由于 CitC 提供更多的功能,目前使用率达到 80% 。

2.5 主干开发

Google 采用"主干开发"(trunk-based development)。代码一般提交到主干的头部。这样保证了所有用户看到的都是同一份代码的最新版本。

"主干开发"避免了合并分支时的麻烦。谷歌一般不采用分支开发,分支只用来发布。大多数时候,发布分支是主干某个时点的快照。以后的除错和功能增强,都是提交到主干,必要时 cherry-pick 到发布分支。与主干长期并行的开发分支,在谷歌极少见。

由于不采用"分支开发",谷歌引入新功能,一般在代码中使用开关控制。这避免了另起一个分支,也使得通过配置切换功能变得容易,一旦新功能发生故障,很容易切换回旧功能。等到新功能稳定,再彻底删除旧代码。谷歌有类似A/B测试的路由算法,评估代码的表现,由于存在配置开关,这种测试很容易实现。

2.6 代码评审

所有代码合并进仓库之前,都必须进行代码评审。大部分评审对所有人开放,任何谷歌员工都可以对代码提意见或者提交变动。

代码评审的依据是《Google 代码风格指南》。谷歌有一个叫做 Critique 的工具,可以查看每一行代码的历史演变。

2.7 自动测试

评审完成后,会自动运行测试。通过测试以后,代码就合并进了 Piper 仓库,整个过程不需要人工干预。

三、优点

单一代码仓库主要有以下优点。

(1)统一的版本

整个公司的代码,有统一的版本和路径,不存在找不到文件的最新版本这样的问题。

(2)广泛的代码共享和复用

任何人都可以浏览和使用全公司的代码,这大大促进了代码的共享和复用。

(3)简化的依赖管理

如果你是库文件或者 API 的作者,因为所有人的代码都在一个库里面,所以很容易找到依赖你的所有下游代码。

每当代码变动,所有依赖你的代码都会自动构建。如果有大量的构建失败,那么系统会自动撤销这次提交。这样也保证了所有代码依赖的都是最新版本,避免依赖不同的版本所导致的冲突。

另外,由于代码的边界很清楚,所以不会发生循环依赖。而且,API的作者也很容易发现,别人怎么使用他的API。

(4)原子性变动

由于每次代码变动所导致的影响,都在一个仓库里面,所以都属于原子性的变动。因此,很容易撤销,或者预先测试它所造成的影响。

为了防止错误提交,谷歌引入了"预提交"(即在提交之前,先分析一下依赖它的代码是否会构建失败)。

(5)大规模代码析构

单一代码仓库为查找和分析代码,提供了巨大的方便。

Google的静态分析引擎 Tricorder 定时运行,对代码进行分析。比如,C++ 11 标准公布以后,很容易找到所有需要改进的变量声明语句,进行性能优化。该引擎还对许多错误提供"一键修正"的功能,同时产出大量的统计数据。

此外,编译器团队也会对不同语言的所有代码进行分析,找出不合理的代码和过时的API。

四、缺点

单一代码仓库的主要缺点是,所有工具都必须自己写,因为市场上没有能够管理这种规模的代码仓库的软件。

五、总结

单一代码仓库,适合提倡透明开放的大型软件公司,不适合小公司和有大量私密代码的公司。

(完)

留言(30条)

估计也只有大公司能这么搞……小公司完全没精力和能力

“主干开发”和“开关策略”,一直在纠结如何用好git的分支来做版本管理,但目前觉得“主干开发”更适合我的需求。

对商业公司的代码管理来说,权限控制太重要了,相反git完全没有权限控制,所以更适合开源项目。

引用Loyalsoldier的发言:

估计也只有大公司能这么搞……小公司完全没精力和能力

看明白了, google 也是从小公司发展起来的,
只是从一开始就定了代码的流程, 并坚持到今天,
只是不得不用越来越NB 的工具来替代了传统的通用版本管理工具而已.

一峰说的 不合适其实已经给出了为什么中国多数公司/团队用不了这种仓库结构....

重点不是团队规模, 而是秘密代码太多...
并不一定是敏感信息, 而是各个组的机密项目,
根本就不能给其它组看到...

这种规模的代码,即使偷了,也很难实现,更不用说个人根本没办法全部拷贝走了。
另外完善的专利法律也是代码保护的后盾。

内部工具对项目研发和效率提升极其重要
自己三个公司的体验对比
1.之前在微软外包的时间,在VisualStudio组,微软的内部也有一套瀑布的测试流程,内部自动化工具很完善,
我们当时负责的vs自动化用例,
代码完成后提交,不是立即到代码库,而是会先发起一些自动化扫描,
扫描通过后自动发起CR(必须有人CR后才可以往下走),CR通过后会触发运行,
在核心用例一个都通过和总用例失败不低于一定的指数,才会合并到代码库
这一套机制的背后是内部很完善的自动化工具,
2.在T工作过1年多(时间不多,了解的不清楚),接触过的2个部门,内部工具都是服务于各自部门的,大范围推广的不多,而且定制化的比较多,创新不是很多,
3.目前在A工作,从开始小部门内部工具,到现在各个部门划分比较清晰,工具目前看已经产品化、服务化、集成化,目前还有很多不足,但是总体上已经开始服务于全部公司,效率提升不少,(稳定化、大量的咨询是大痛点)

果然很强大

当前公司使用的就是“主干开发”模式,使用开关控制新功能的发布。
看了本文,更加深入理解了这个模式的真谛。thanks~

我非常想知道“开关控制”是怎么玩的?有没有机会讲解一下,还是说直接能 Google 到?

引用夜幕下的猫的发言:

我非常想知道“开关控制”是怎么玩的?有没有机会讲解一下,还是说直接能 Google 到?

我理解的应该是引入一个bool的配置变量,当为true开启某个(新的/旧的)功能,false关闭某个功能。

引用夜幕下的猫的发言:

我非常想知道“开关控制”是怎么玩的?有没有机会讲解一下,还是说直接能 Google 到?

https://en.wikipedia.org/wiki/Feature_toggle

其实嵌入式年代的宏开关也是类似效果,但总归没有Web领域这么容易解耦。

如果是快速开发的产品线 迭代非常快 同时间可能并行3个版本在开发 他们的差别支持发布时间上的差异 那么怎么处理呢?

不太理解,这一个库的意思,难道工程师要把整个库下载下来?单独项目开发的时候要怎么管理代码?

引用Mingfei的发言:

不太理解,这一个库的意思,难道工程师要把整个库下载下来?单独项目开发的时候要怎么管理代码?

文中有说明:"开发者通过 CitC 浏览和同步 Piper 上的文件,但是编辑和修改是在自己工作区,里面只保存有变动的文件(一个工作区一般不超过10个文件)。CitC 带有云储存机制,每个工作区就是云上的一个目录。"

是一个库,但不需要全下载到本地,直接在云上工作。这和git不同。

阮老师要是能有一个所有文章的目录就好了~~

”一个工作区一般不超过10个文件“这个貌似并不准确。

如果你说的工作区是指workspace的话,每个workspace可以创建一个或多个CL(change list,相当于一个pull request), 一个CL很多时候都会超过10个文件,特别是如果像公司级别的dependency发生改变的话,可能要将需要批处理的几百个调用这个dependency的文件放在一个CL里边,修改之后一并提交。

好久不见,阮老师

看完之后觉得Google的开发流程受到最初使用perforce的影响不小。piper看起来就是一个大规模集群化的perforce 。

除了这个,从Android的AOSP源码管理工具repo还有chrome的代码管理工具也是概念上很类似的。

引用pfchai的发言:

对商业公司的代码管理来说,权限控制太重要了,相反git完全没有权限控制,所以更适合开源项目。

可以公司内部搭建自己的Git服务器,服务器运维控制权限分发

git “主干开发”模式,使用开关控制新功能的发布 这个开关是什么,这个开关要再哪里设置?有人能解答一下吗?谢谢。

引用pfchai的发言:

对商业公司的代码管理来说,权限控制太重要了,相反git完全没有权限控制,所以更适合开源项目。

自己在公司内部搭建GitLab服务器,有很完善的权限控制。

我们部门也是Git和云端管理代码,但达到Google规模的代码库还是不大可能的,感谢大神翻译并分享心得

我不太相信这个数据,算下来,一天有400亿次版本控制服务的请求?就算Google再多员工,再多产品线,再多的集成测试和部署,一天400亿?每秒50万?我极度怀疑这个数据啊。

Piper听起来很像ClearCase的用法

引用jdxyw的发言:

我不太相信这个数据,算下来,一天有400亿次版本控制服务的请求?就算Google再多员工,再多产品线,再多的集成测试和部署,一天400亿?每秒50万?我极度怀疑这个数据啊。

可能一次访问N个文件,算N次

我们小团队就直接用github或者是github的私有仓库

哈哈 google 这种集中管理方式效率很高,不是哔哩哔哩那种单一仓库(偷笑),不过对于我们还是 git + 自建仓库就足够了。

引用jdxyw的发言:

我不太相信这个数据,算下来,一天有400亿次版本控制服务的请求?就算Google再多员工,再多产品线,再多的集成测试和部署,一天400亿?每秒50万?我极度怀疑这个数据啊。

应该还有很多次是自动化用例之类的,比如一次访问提交会触发10+个测试用例?

引用jdxyw的发言:

我不太相信这个数据,算下来,一天有400亿次版本控制服务的请求?就算Google再多员工,再多产品线,再多的集成测试和部署,一天400亿?每秒50万?我极度怀疑这个数据啊。

人为的不多,主要是自动化(持续测试),每天跑N次自动化,每次都需要从仓库拉代码,然后跑自动化

会导致一次提交全公司构建吗

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接