我们如何改造Gitlab庄表伟

About the project
iSource：华为内部开源平台 （Inner Source）
2014-09-11：上线运营至今， 注册用户数，超过11万
基于Gitlab：在Gitlab上进行了 长达3年的深度开发，走过弯路， 也大有收获
技术决策的来龙去脉
如何平衡需求与目标之间的差异？ 如何平衡效率与品质之间的矛盾？ 如何平衡习惯与创新之间的冲突？
◇ 华为公司在全球有几十家研究机构，研发人员遍布世 界各地 ◇ 一个大型项目的研发人员，数量超过2K，同样全球分 布 ◇ 深圳本地研发人员，下载深圳数据中心的代码：每秒 8~10M，非常满意 ◇ 西安当地研发人员，下载深圳数据中心的代码：每秒 200~500K，欲哭无泪 ◇ 大型项目的仓库大小，甚至超过50G…… ◇ 多数据中心架构改造，迫在眉睫！
iSource的早期策略
► 以我为主，兼容并蓄 ◦ 大量的特性，外部开源社区，不会去做 ◦ 分布式架构改造，已经让我们离Gitlab越来越远
了 ◦ Gitlab的发展路线，相当随意，没啥章法 ◦ 我们看过Gitlab的源代码，感觉水平很一般
► 围绕Gitlab改动的内容
◦ 按照游戏化管理的思路，建立了一套积分体系 ◦ 增强的权限管理体系 ◦ 增强的分支管理模式 ◦ 增强的issue处理流程 ◦ 增强的Code Review流程
基于插件机制的自动化升级脚本
◇ 创建独立的gitlab_plus项目 ◇ 执行 build.sh -v 9.5.2 ◇ 下载指定版本代码 ◇ 修改指定位置的代码 ◇ Copy Plugins Code ◇ docker build 最新版的gitlab（修改后的Dockerfile） ◇ docker-compose up ◇ 任何时候gitlab新出，可以实现一键升级，并合入最新代
最初的技术选型
为啥我们会选择这条艰难的道路？
Github Enterprise
Gerrit
Redmine
我们需要一个轻量 级、分布式、可定 制的项目托管平台
基于开源项 目二次开发
完全自研
采购一个商业 产品+源代码
Gitlab
OpenGrok
这是一个正确 的决策吗？
• 已经进行了分布式改造 • 包含一些我们需要的扩
Gerrit OMEGA
Gerrit vs. OMEGA
���
改进Code Review
继续向Gerrit学习
最早走过的弯路
◇ 基于Gitlab，集成Gerrit，从Merge Request到Gerrit Change ◇ 在服务器端复制一份git仓库 ◇ 在服务器端构造Change-Id ◇ 将Gitlab的权限体系，映射到Gerrit ◇ 自动更新change set ◇ 回填Gerrit结果
引入Gerrit 的核心价值
► No fork、No feature branch、Multi-repo ◦ 已经通过OMEGA得以继承
► 围绕Code Review建立的工作流 ◦ 工具检查、人工审核、Committer批准 ◦ 评分机制：+2/+1/0/-1/-2
► 需要在iSource实现类似的评分机制 ◦ 开放API，允许工具评分 ◦ 改造界面，实现打分 ◦ 增加项目设定，设置合入MR的最低得分
向Redmine学习
◇ 添加 config/initializers/0_plugins.rb ◇ 添加 lib/gitlab/plugin.rb ◇ 添加 lib/task/plugin.rb ◇ 修改config/initializers/assets.rb ◇ 修改 config/routes.rb ◇ 修改Gemfile ◇ 添加plugins/下的N个插件目录，放置init.rb文件
我们如何改造 Gitlab?
背景介绍
About me 2005：开始接触Ruby on Rails 2006~2009：担任印客网技 术总监，开始在商业环境中使 用Rails 2009~2012：加入盛大创新 院，基于Redmine，搭建 Teamhost开源平台 2013-11：加入华为，负责华 为内源平台项目，担任架构师
���
如何改好开源项目？
破解每个团队都会困扰的难题
Gitlab 发布频率
◇ 从2015-09-22发布8.0.0到2017-09-06发布9.5.4，一共发布 248个正式版本！
◇ 平均三天不到，发布一个小版本 ◇ 平均24天，发布一个大版本：x.x.0 充满活力的开源社区，对于打算二次开发的团队而言，是一项巨大 的挑战！ ◇ 跟着走：累！ ◇ 不跟：眼馋！
从单中心到多中心
���
多仓工作流改造
单仓50G！这样下去不行啊……
基于Fork的Git工作流
◇ 服务器端的存储压力：一开始还好，后面的问题会越来越多 ◇ 客户端的操作复杂度：fork一个仓库，还算比较方便。假如要 同时fork一百个仓库呢？ ◇ 分仓联动：最初基于Submodule的尝试
● 自动同步fork ● 自动同步创建新的分支 ● 自动同步发起Merge Request ● 自动同步合入/关闭Merge Request ● 复杂得没完没了……
展特性：积分体系、 CMS、Groups • 附带合同，能够有熟悉 Gitlab的开发力量投入
我们对Gitlab的改造
多中心架构改造 多仓工作流改造 改进Code Review 插件化改造 更多探索
���
多中心架构改造
被逼出来的业界领先
从单中心到多中心
仅仅单中心分布式是不够的
码பைடு நூலகம்
Gitlab 插件化的价值
◇ 以尽可能无损的方式，随时追踪Gitlab最新版本 ◇ 通过调整插件，可以同时开发适应内外不同需求的版本 ◇ 争取将这个架构，贡献到社区 ◇ 向Eclipse学习
更多探索
以及可能的发展方向
基于浏览器插件的扩展方案
◇ 目前只开发Chrome版本的插件 ◇ 基于FireBreath，支持其他浏览器也很简单 ◇ 在浏览器端，可以动态修改web页面，添加页面元素
￭ 例如：直接调用 BeyondCompare 比较代码 ◇ Github也在做类似的事情