华为 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

创作场景

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