1、我们如何改造Gitlab?背景介绍About me2005：开始接触Ruby on Rails20062009：担任印客网技术总监，开始在商业环境中使用Rails20092012：加入盛大创新院，基于Redmine，搭建Teamhost开源平台2013-11：加入华为，负责华为内源平台项目，担任架构师About the projectiSource：华为内部开源平台（Inner Source）2014-09-11：上线运营至今，注册用户数，超过11万基于Gitlab：在Gitlab上进行了长达3年的深度开发，走过弯路，也大有收获技术决策的来龙去脉 如何平衡需求与目标之间的差异？ 如何平衡效率与
2、品质之间的矛盾？ 如何平衡习惯与创新之间的冲突？最初的技术选型为啥我们会选择这条艰难的道路？我们需要一个轻量级、分布式、可定制的项目托管平台GithubEnterprise完全自研基于开源项目二次开发RedmineGitlab采购一个商业产品+源代码已经进行了分布式改造包含一些我们需要的扩展特性：积分体系、CMS、Groups附带合同，能够有熟悉Gitlab的开发力量投入GerritOpenGrok这是一个正确的决策吗？n 多中心架构改造n 多仓工作流改造n 改进Code Reviewn 插件化改造n 更多探索我们对Gitlab的改造多中心架构改造被逼出来的业界领先从单中心到多中心 华为公司在
3、全球有几十家研究机构，研发人员遍布世界各地 一个大型项目的研发人员，数量超过2K，同样全球分布 深圳本地研发人员，下载深圳数据中心的代码：每秒810M，非常满意 西安当地研发人员，下载深圳数据中心的代码：每秒200500K，欲哭无泪 大型项目的仓库大小，甚至超过50G 多数据中心架构改造，迫在眉睫！仅仅单中心分布式是不够的从单中心到多中心多仓工作流改造单仓50G！这样下去不行啊基于Fork的Git工作流 服务器端的存储压力：一开始还好，后面的问题会越来越多 客户端的操作复杂度：fork一个仓库，还算比较方便。假如要同时fork一百个仓库呢？ 分仓联动：最初基于Submodule的尝试 自动同步
4、fork 自动同步创建新的分支 自动同步发起Merge Request 自动同步合入/关闭Merge Request 复杂得没完没了Gerrit OMEGAGerrit 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-
5、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充满活力的开源社区，对于打算二次开发的团队而言，是一项巨大的挑战！ 跟着走：累！
6、 不跟：眼馋！iSource的早期策略 以我为主，兼容并蓄 大量的特性，外部开源社区，不会去做 分布式架构改造，已经让我们离Gitlab越来越远了 Gitlab的发展路线，相当随意，没啥章法 我们看过Gitlab的源代码，感觉水平很一般 围绕Gitlab改动的内容 按照游戏化管理的思路，建立了一套积分体系 增强的权限管理体系 增强的分支管理模式 增强的issue处理流程 增强的Code Review流程向Redmine学习 添加 config/initializers/0_plugins.rb 添加 lib/gitlab/plugin.rb 添加 lib/task/plugin.rb 修改co
7、nfig/initializers/assets.rb 修改 config/routes.rb 修改Gemfile 添加plugins/下的N个插件目录，放置init.rb文件基于插件机制的自动化升级脚本 创建独立的gitlab_plus项目 执行 build.sh -v 9.5.2 下载指定版本代码 修改指定位置的代码 Copy Plugins Code docker build 最新版的gitlab（修改后的Dockerfile） docker-compose up 任何时候gitlab新出，可以实现一键升级，并合入最新代码Gitlab 插件化的价值 以尽可能无损的方式，随时追踪Gitla
8、b最新版本 通过调整插件，可以同时开发适应内外不同需求的版本 争取将这个架构，贡献到社区 向Eclipse学习更多探索以及可能的发展方向基于浏览器插件的扩展方案 目前只开发Chrome版本的插件 基于FireBreath，支持其他浏览器也很简单 在浏览器端，可以动态修改web页面，添加页面元素 例如：直接调用 BeyondCompare 比较代码 Github也在做类似的事情基于MS-GVFS的探索 https:/ https:/ 从模仿走向创新 从小型企业 中型企业 大型企业 从单一代码托管走向上下游通吃 我们的选择是帮助它更好的成长！Thanks!Any questions?Any questions?多说一句
