华为云 DevCloud 在大规模团队 Git 协作的探索

华为 2019 的 001 号文件中提到，“华为今年全面提升软件工程能力与实践，打造可信的高质量产品”。

可信的软件开发为未来的软件工程指出了发展方向。追求可信的道路上，需要软件研发水平提升，保障从产品研发到交付全流程的高质量，同时需要软件管理与维护方法与时俱进。

如何做好代码仓库的版本控制，保障软件开发过程可控性？日前，华为云 DevCloud 的 iSource 代码平台专家在 Qcon 和 DevOps 社区年会上，对外分享了华为云 DevCloud 在大规模团队 Git 协作上的探索。

华为内部使用 Git 进行软件开发协作遇到的挑战

华为内部 Git 协作遇到的挑战来自多个方面：

首先华为目前的产品涉及众多领域，每个领域下，从硬件到驱动，到系统模块，到上层应用，相关组件与代码仓库非常繁多。代码仓库数 60 万+，注册用户数 21.5 万，源代码总行数 1100 亿+，每天提交次数 9 万+…

其次历史仓库非常多，从 2014 年开始建设内源平台，逐渐把各领域的产品代码迁移到内源平台开源，发现各个产品原先的代码托管服务差异很大，产品的仓库存在如下特点:

• 派生出来的仓库特别多

• 特性分支，维护分支，补丁分支特别多

• 历史发布的产品版本对应的仓库，依然会参与构建与发布

那么，华为云 DevCloud 的 iSource 代码平台面对如此多的产品仓库，并且华为的产品仓库每天都会被大量的 CI 工程下载，在峰值能够达到 1 万次下载/每秒。这首先对服务器的压力是非常大的，对代码托管团队的技术挑战是极其严峻的。

iSource 代码平台 进行大量架构上的重构和优化

2014 年，iSource 代码平台经过选型，确定基于 Gitlab 的社区版本进行演进。

2015 年 4 月，上线了 iSource 第一代的分布式架构，通过仓库路由做到存储 IO 能负载到不同后端服务器上。不过华为内部的研发团队是分布在不同地域的，在国内华为研究所有深圳、北京、杭州、上海、西安、成都等，不同地域访问 iSource 的仓库速度会差异很大。

iSource 数据中心内集群方案

2015 年底，为了解决不同研究所远程下载 Git 速度慢的问题，在公司各地域数据中心建立了节点，实现了多中心分布式架构。各个中心间的同步采用异步同步，虽然不能保证数据的强一致性，但是通过远程代理等手段实现了用户体验上的一致性。

iiSource 多数据中心方案

同时， Gitlab 的架构也发生了变化。Gitlab 9.0 版本有了巨大的改进，也增加了分片（Sharding）、RPC（Gitaly）的能力。2018 年我们也基于 Gitlab 9.0 开始了下一代的 iSource 架构调整。

工作模式创新 进行 OMEGA 集中式仓库开发模式

在解决了研发团队不同地域的访问与下载速度上的问题后，仍然不能避免一个问题，就是华为产品的仓库多，派生多的问题。

每个产品会面临众多仓库要开发和维护，就需要解决如下问题：

• 多仓库关联问题，如何解决多个源码仓库之前的版本关联

• 派生仓库的管理问题，仓库派生后相关配置会在派生仓库失去管控

• 上游同步复杂，派生仓库与上游仓库同步困难，会消耗大量工作量

• 磁盘消耗太快，派生仓库在使用过程中，会产生大量冗余存储

华为云 Devloud 的 iSource 代码平台团队经过了很多尝试和对比后，最终选择对标 Gerrit 平台的开发模式。华为内部在架构、功能性、用户体验上进行了很多工作。难度最大，影响最为深远的，就是基于 Gitlab 的内核，开发了 OMEGA (One-stop MultipurposE Git Access) 代码仓库集中式开发模式。

OMEGA 开发模式有如下特点:

• 开发人员不再需要派生仓库

• 服务器上的 Git 仓库不需要开发人员的开发分支存在，分支大量减少

• 使用 xml 文件来描述仓库关联关系，没有 submodule 存在的子仓库冲突问题，可配置化，更容易维护

• 通过客户端工具能够一键推送修改并创建 Merge Request，加快代码提交速度

本文转载自 华为云产品与解决方案 公众号。

原文链接：hhttps://mp.weixin.qq.com/s/_fpSqkILNJHl_AePcn1lpw