我们如何改造Gitlab庄表伟课件

我们如何改造Gitlab?我们如何改造Gitlab?1背景介绍Aboutme2005：开始接触RubyonRails2006~2009：担任印客网技术总监，开始在商业环境中使用Rails2009~2012：加入盛大创新院，基于Redmine，搭建Teamhost开源平台2013-11：加入华为，负责华为内源平台项目，担任架构师AbouttheprojectiSource：华为内部开源平台（InnerSource）2014-09-11：上线运营至今，注册用户数，超过11万基于Gitlab：在Gitlab上进行了长达3年的深度开发，走过弯路，也大有收获背景介绍AboutmeAbouttheproject2技术决策的来龙去脉如何平衡需求与目标之间的差异？如何平衡效率与品质之间的矛盾？如何平衡习惯与创新之间的冲突？技术决策的来龙去脉如何平衡需求与目标之间的差异？3最初的技术选型为啥我们会选择这条艰难的道路？最初的技术选型为啥我们会选择这条艰难的道路？4我们需要一个轻量级、分布式、可定制的项目托管平台GithubEnterprise完全自研基于开源项目二次开发RedmineGitlab采购一个商业产品+源代码已经进行了分布式改造包含一些我们需要的扩展特性：积分体系、CMS、Groups附带合同，能够有熟悉Gitlab的开发力量投入GerritOpenGrok这是一个正确的决策吗？我们需要一个轻量级、分布式、可定制的项目托管平台Github5多中心架构改造多仓工作流改造改进CodeReview插件化改造更多探索我们对Gitlab的改造多中心架构改造我们对Gitlab的改造6多中心架构改造被逼出来的业界领先🔨多中心架构改造被逼出来的业界领先🔨7从单中心到多中心从单中心到多中心8华为公司在全球有几十家研究机构，研发人员遍布世界各地一个大型项目的研发人员，数量超过2K，同样全球分布深圳本地研发人员，下载深圳数据中心的代码：每秒8~10M，非常满意西安当地研发人员，下载深圳数据中心的代码：每秒200~500K，欲哭无泪大型项目的仓库大小，甚至超过50G……多数据中心架构改造，迫在眉睫！仅仅单中心分布式是不够的华为公司在全球有几十家研究机构，研发人员遍布世界各地仅仅单9从单中心到多中心从单中心到多中心10多仓工作流改造单仓50G！这样下去不行啊……🔨多仓工作流改造单仓50G！这样下去不行啊……🔨11基于Fork的Git工作流

服务器端的存储压力：一开始还好，后面的问题会越来越多

客户端的操作复杂度：fork一个仓库，还算比较方便。假如要同时fork一百个仓库呢？

分仓联动：最初基于Submodule的尝试●自动同步fork●自动同步创建新的分支●自动同步发起MergeRequest

●自动同步合入/关闭MergeRequest●复杂得没完没了……基于Fork的Git工作流服务器端的存储压力：一开始还好，12GerritOMEGAGerritOMEGA13Gerritvs.OMEGAGerritvs.OMEGA14🔨改进CodeReview继续向Gerrit学习🔨改进CodeReview继续向Gerrit学习15最早走过的弯路基于Gitlab，集成Gerrit，从MergeRequest到GerritChange

在服务器端复制一份git仓库

在服务器端构造Change-Id

将Gitlab的权限体系，映射到Gerrit

自动更新changeset

回填Gerrit结果最早走过的弯路基于Gitlab，集成Gerrit，从Mer16引入Gerrit的核心价值►Nofork、Nofeaturebranch、Multi-repo◦已经通过OMEGA得以继承

►围绕CodeReview建立的工作流

◦工具检查、人工审核、Committer批准

◦评分机制：+2/+1/0/-1/-2►需要在iSource实现类似的评分机制

◦开放API，允许工具评分

◦改造界面，实现打分

◦增加项目设定，设置合入MR的最低得分引入Gerrit的核心价值►Nofork、Nofe17🔨如何改好开源项目？破解每个团队都会困扰的难题🔨如何改好开源项目？破解每个团队都会困扰的难题18Gitlab发布频率

从2015-09-22发布8.0.0到2017-09-06发布9.5.4，一共发布248个正式版本！

平均三天不到，发布一个小版本

平均24天，发布一个大版本：x.x.0充满活力的开源社区，对于打算二次开发的团队而言，是一项巨大的挑战！跟着走：累！不跟：眼馋！Gitlab发布频率从2015-09-22发布8.0.019iSource的早期策略►以我为主，兼容并蓄◦大量的特性，外部开源社区，不会去做◦分布式架构改造，已经让我们离Gitlab越来越远了◦Gitlab的发展路线，相当随意，没啥章法◦我们看过Gitlab的源代码，感觉水平很一般►围绕Gitlab改动的内容◦按照游戏化管理的思路，建立了一套积分体系◦增强的权限管理体系◦增强的分支管理模式◦增强的issue处理流程◦增强的CodeReview流程iSource的早期策略►以我为主，兼容并蓄20向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文件向Redmine学习添加config/initialize21基于插件机制的自动化升级脚本创建独立的gitlab_plus项目执行build.sh-v9.5.2下载指定版本代码修改指定位置的代码CopyPlugins

Codedockerbuild最新版的gitlab（修改后的Dockerfile）docker-composeup任何时候gitlab新出，可以实现一键升级，并合入最新代码基于插件机制的自动化升级脚本创建独立的gitlab_plus22Gitlab插件化的价值以尽可能无损的方式，随时追踪Gitlab最新版本通过调整插件，可以同时开发适应内外不同需求的版本争取将这个架构，贡献到社区向Eclipse学习Gitlab插件化的价值以尽可能无损的方式，随时追踪Git23更多探索以及可能的发展方向更多探索以及可能的发展方向24基于浏览器插件的扩展方案目前只开发Chrome版本的插件基于FireBreath，支持其他浏览器也很简单在浏览器端，可以动态修改web页面，添加页面元素例如：直接调用BeyondCompare比较代码Github也在做类似的事情基于浏览器插件的扩展方案目前只开发Chrome版本的插件25基于MS-GVFS的探索/Microsoft/GVFS/zhuangbiaowei/grack-with-gvfs基于MS-GVFS的探索26Gitlab将会走向何方？从模仿走向创新从小型企业

中型企业大型企业从单一代码托管走向上下游通吃我们的选择是……帮助它更好的成长！Gitlab将会走向何方？从模仿走向创新27Thanks!Anyquestions?Thanks!Anyquestions?28多说一句……多说一句……29我们如何改造Gitlab?我们如何改造Gitlab?30背景介绍Aboutme2005：开始接触RubyonRails2006~2009：担任印客网技术总监，开始在商业环境中使用Rails2009~2012：加入盛大创新院，基于Redmine，搭建Teamhost开源平台2013-11：加入华为，负责华为内源平台项目，担任架构师AbouttheprojectiSource：华为内部开源平台（InnerSource）2014-09-11：上线运营至今，注册用户数，超过11万基于Gitlab：在Gitlab上进行了长达3年的深度开发，走过弯路，也大有收获背景介绍AboutmeAbouttheproject31技术决策的来龙去脉如何平衡需求与目标之间的差异？如何平衡效率与品质之间的矛盾？如何平衡习惯与创新之间的冲突？技术决策的来龙去脉如何平衡需求与目标之间的差异？32最初的技术选型为啥我们会选择这条艰难的道路？最初的技术选型为啥我们会选择这条艰难的道路？33我们需要一个轻量级、分布式、可定制的项目托管平台GithubEnterprise完全自研基于开源项目二次开发RedmineGitlab采购一个商业产品+源代码已经进行了分布式改造包含一些我们需要的扩展特性：积分体系、CMS、Groups附带合同，能够有熟悉Gitlab的开发力量投入GerritOpenGrok这是一个正确的决策吗？我们需要一个轻量级、分布式、可定制的项目托管平台Github34多中心架构改造多仓工作流改造改进CodeReview插件化改造更多探索我们对Gitlab的改造多中心架构改造我们对Gitlab的改造35多中心架构改造被逼出来的业界领先🔨多中心架构改造被逼出来的业界领先🔨36从单中心到多中心从单中心到多中心37华为公司在全球有几十家研究机构，研发人员遍布世界各地一个大型项目的研发人员，数量超过2K，同样全球分布深圳本地研发人员，下载深圳数据中心的代码：每秒8~10M，非常满意西安当地研发人员，下载深圳数据中心的代码：每秒200~500K，欲哭无泪大型项目的仓库大小，甚至超过50G……多数据中心架构改造，迫在眉睫！仅仅单中心分布式是不够的华为公司在全球有几十家研究机构，研发人员遍布世界各地仅仅单38从单中心到多中心从单中心到多中心39多仓工作流改造单仓50G！这样下去不行啊……🔨多仓工作流改造单仓50G！这样下去不行啊……🔨40基于Fork的Git工作流

服务器端的存储压力：一开始还好，后面的问题会越来越多

客户端的操作复杂度：fork一个仓库，还算比较方便。假如要同时fork一百个仓库呢？

分仓联动：最初基于Submodule的尝试●自动同步fork●自动同步创建新的分支●自动同步发起MergeRequest

●自动同步合入/关闭MergeRequest●复杂得没完没了……基于Fork的Git工作流服务器端的存储压力：一开始还好，41GerritOMEGAGerritOMEGA42Gerritvs.OMEGAGerritvs.OMEGA43🔨改进CodeReview继续向Gerrit学习🔨改进CodeReview继续向Gerrit学习44最早走过的弯路基于Gitlab，集成Gerrit，从MergeRequest到GerritChange

在服务器端复制一份git仓库

在服务器端构造Change-Id

将Gitlab的权限体系，映射到Gerrit

自动更新changeset

回填Gerrit结果最早走过的弯路基于Gitlab，集成Gerrit，从Mer45引入Gerrit的核心价值►Nofork、Nofeaturebranch、Multi-repo◦已经通过OMEGA得以继承

►围绕CodeReview建立的工作流

◦工具检查、人工审核、Committer批准

◦评分机制：+2/+1/0/-1/-2►需要在iSource实现类似的评分机制

◦开放API，允许工具评分

◦改造界面，实现打分

◦增加项目设定，设置合入MR的最低得分引入Gerrit的核心价值►Nofork、Nofe46🔨如何改好开源项目？破解每个团队都会困扰的难题🔨如何改好开源项目？破解每个团队都会困扰的难题47Gitlab发布频率

从2015-09-22发布8.0.0到2017-09-06发布9.5.4，一共发布248个正式版本！

平均三天不到，发布一个小版本

平均24天，发布一个大版本：x.x.0充满活力的开源社区，对于打算二次开发的团队而言，是一项巨大的挑战！跟着走：累！不跟：眼馋！Gitlab发布频率从2015-09-22发布8.0.048iSource的早期策略►以我为主，兼容并蓄◦大量的特性，外部开源社区，不会去做◦分布式架构改造，已经让我们离Gitlab越来越远了◦Gitlab的发展路线，相当随意，没啥章法◦我们看过Gitlab的源代码，感觉水平很一般►围绕Gitlab改动的内容◦按照游戏化管理的思路，建立了一套积分体系◦增强的权限管理体系◦增强的分支管理模式◦增强的issue处理流程◦增强的CodeReview流程iSource的早期策略►以我为主，兼容并蓄49向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文件向Redmine学习添加config/initialize50基于插件机制的自动化升级脚本创建独立的gitlab_plus项目执行build.sh-v9.5.2下载指定版本代码修改指