我们如何改造Gitlab.pptx

我们如何改造Gitlab? 背景介绍 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年的深度开发，走过弯路，也大有收获 技术决策的来龙去脉 如何平衡需求与目标之间的差异？ 如何平衡效率与品质之间的矛盾？ 如何平衡习惯与创新之间的冲突？ 最初的技术选型 为啥我们会选择这条艰难的道路？ 我们需要一个轻量级、分布式、可定制的项目托管平台 Github Enterprise 完全自研 基于开源项目二次开发 Redmine Gitlab 采购一个商业产品+源代码 已经进行了分布式改造 包含一些我们需要的扩展特性：积分体系、CMS、Groups 附带合同，能够有熟悉Gitlab的开发力量投入 Gerrit OpenGrok 这是一个正确的决策吗？ 多中心架构改造 多仓工作流改造 改进Code Review 插件化改造 更多探索 我们对Gitlab的改造 多中心架构改造 被逼出来的业界领先 🔨 从单中心到多中心 华为公司在全球有几十家研究机构，研发人员遍布世界各地 一个大型项目的研发人员，数量超过2K，同样全球分布 深圳本地研发人员，下载深圳数据中心的代码：每秒8~10M，非常满意 西安当地研发人员，下载深圳数据中心的代码：每秒200~500K，欲哭无泪 大型项目的仓库大小，甚至超过50G…… 多数据中心架构改造，迫在眉睫！ 仅仅单中心分布式是不够的 从单中心到多中心 多仓工作流改造 单仓50G！这样下去不行啊…… 🔨 基于Fork的Git工作流 服务器端的存储压力：一开始还好，后面的问题会越来越多 客户端的操作复杂度：fork一个仓库，还算比较方便。假如要同时fork一百个仓库呢？ 分仓联动：最初基于Submodule的尝试 ● 自动同步fork ● 自动同步创建新的分支 ● 自动同步发起Merge Request ● 自动同步合入/关闭Merge Request ● 复杂得没完没了…… 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的最低得分 🔨 如何改好开源项目？ 破解每个团队都会困扰的难题 Gitlab 发布频率 从2015-09-22发布8.0.0到2017-09-06发布9.5.4，一共发布248个正式版本！ 平均三天不到，发布一个小版本 平均24天，发布一个大版本：x.x.0 充满活力的开源社区，对于打算二次开发的团队而言，是一项巨大的挑战！ 跟着走：累！ 不跟：眼馋！ iSource的早期策略 ► 以我为主，兼容并蓄 ◦ 大量的特性，外部开源社区，不会去做 ◦ 分布式架构改造，已经让我们离Gitlab越来越远了 ◦ Gitlab的发展路线，相当随意，没啥章法 ◦ 我们看过Gitlab的源代码，感觉水平很一般 ► 围绕Gitlab改动的内容 ◦ 按照游戏化管理的思路，建立了一套积分体系 ◦ 增强的权限管理体系 ◦ 增强的分支管理模式 ◦ 增强的issue处理流程 ◦ 增强的Code Review流程 向Redmine学习 添加 config/initializers/0_plugins.rb 添加 lib/gitlab/plu