我们如何改造GItlab

2020-02-27 704浏览

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