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

阅读数:2 2020 年 3 月 23 日 17:00

华为云 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 的仓库速度会差异很大。

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

iSource 数据中心内集群方案
i

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

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

iiSource 多数据中心方案
i

同时, 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

评论

发布