极狐GitLab、GitLab、GitHub、Gitee 都是市面上常见的与代码托管有关的平台,但是这四种产品还是有所差异的。下面会做一个对比分析。
极狐GitLab:是一个一体化的 DevOps 平台。关于极狐GitLab 和 GitLab 的关系,可以查看为什么选择极狐GitLab?中极狐GitLab 与 GitLab 的协作模式章节。
GitLab:是一个一体化的 DevOps 平台。提供覆盖软件全开发生命周期的管理功能。提高企业 DevOps 能力。
GitHub:是一个开发者平台。目前是开源项目的主要集散地。
Gitee:是一个代码托管平台。
GitLab 是采取“核心开放”的开源模式(即核心代码开源,企业版代码源码可见),采用的是 MIT license ;极狐GitLab 和 GitLab 采取同样的核心开放模式,但是使用的是极狐 license,详细内容可以查看关于极狐GitLab版本说明中许可证模式章节。 GitHub 和 Gitee 是代码托管平台,但本身产品是闭源的。
极狐GitLab、GitLab、GitHub 都有很完整、详细的文档,能够帮助用户快速理解、使用产品。而 Gitee 的完备情况不如前述的三种产品,仅有部分帮助文档。
文档的完备是一个优秀的项目或者产品的必备因素。
GitLab 和 极狐GitLab 都支持私有化部署,用户可以在各自的官方下载页面下载安装包,安装部署即可完成私有化部署。这也是极狐GitLab 和 GitLab 受用户欢迎的重要原因之一。而 GitHub 和 Gitee 不支持私有化部署。
极狐GitLab/GitLab 的私有部署可以通过多种方式来实现,比如通过安装包(针对不同系统,如 Debian、Ubuntu、CentOS)、docker、Helm Chart等方式进行。安装也非常简单,“一键式”即可完成。详细的安装指导可以查看极狐GitLab 官网安装教程。
上述的私有化部署指真正的私有化部署,也就是说用户可以在不借助产品团队的指导或者特性化开发的前提下完成自主私有化部署。
极狐GitLab/GitLab 的 Geo 是一种高可用架构,能够在多地域部署(尤其符合现在常见的两地三中心场景)。Geo 有两个实例,主实例 primary 和第二实例 secondary。通过 Geo 可以提升极狐GitLab/GitLab 实例的高可用性,当主实例出现问题的时候,第二个实例可以切换过来当作主实例用,不会导致服务不可用。Geo 还有其他很多功能,诸如在两个实例之间实现负载均衡;让只读操作在第二个实例进行,写操作在主实例进行,这样能够提升代码的上传、拉去等效率,同时不影响团队成员通过极狐GitLab/GitLab 来进行协作;还可以为其他区域”研发中心“就某些操作(诸如拉取或克隆)提供就近加速访问,极大的提升效率。Geo 是极狐GitLab/GitLab 一个非常重要,也是被众多企业用户看重的特性。私有部署配合 Geo 就能够打造高可用的自建极狐GitLab/GitLab 平台来供团队使用了。
GitHub 也有高可用服务,但是却不支持私有部署,对于用户来说意义不大,只需要 GitHub 自身保持足够的高可用性即可。对于 Gitee 目前没看到提供有类似的服务,加之 Gitee 和 GitHub 一样,不支持私有部署,所以在高可用 & 多地域部署上,极狐GitLab/GitLab 利用其 Geo 获得了用户和市场的认可。
由于极狐GitLab 可以理解为 GitLab 在国内的发行版,所以从 GitLab 向极狐GitLab 的迁移是百分百可行且非常平滑,极狐GitLab 的支持团队拥有丰富的经验完成这种迁移。而对于 GitLab 向 GitHub 或 Gitee 的迁移都是需要花费一番功夫的。
极狐GitLab 和 GitLab 具有项目管理功能——利用自身的一些功能特性实现,诸如 Epic、Board、Roadmap、Milestone 等,能够展示出当前项目的进展情况,方便及时发现瓶颈点。GitHub、Gitee 则没有类似的功能。
极狐GitLab 和 GitLab 均提供开箱即用的镜像仓库服务,仓库使用方式比较灵活而且 API 丰富,能够满足用户的多种需求。关于极狐GitLab 的镜像仓库使用可以参考博客极狐GitLab 镜像仓库的使用技巧。此外,极狐GitLab、GitLab 还内置 Package Registry,同时支持 maven、npm、Helm 等多种包的存储。GitHub 在 2019 年也推出了 Packages 的服务,用于为用户提供 Container Registry & Package 服务。GitHub 也提供镜像和包管理功能,使用方法和极狐GitLab/GitLab 的类似。但是Gitee 目前为止还没有提供类似的服务,如果用户需要存储镜像,则需要借助第三方镜像仓库服务。
镜像在云原生时代扮演着重要的角色,其存储对于整个软件开发生命周期和软件供应链安全都是非常重要的。镜像仓库应是一个优秀的 DevOps 平台不可或缺的能力。
这四种产品推出 CI/CD 功能的时间不一样:
所以,极狐GitLab/GitLab 已经在 CI/CD 领域沉淀了多年,而且每月迭代版本都会有关于 CI/CD 相关的特性发布,目前功能比较强大,使用方式也很灵活。此外,极狐GitLab/GitLab/GitHub 都使用 Runner 来实现 CI/CD Pipeline 的执行,Runner 可以使用产品默认提供的,也可以自主安装到用户自己所在的服务器上。而 Gitee 推出 CI/CD 功能较晚,目前没有类似的功能实现 CI/CD Pipeline 的灵活执行。
此外,GitHub Action 采用了 Marketplace 的策略来方便用户灵活构建自己的 CI/CD Pipeline,但是由于 Marketplace 缺乏安全保证机制,使用 Marketplace 上面的组件需要保持安全警惕。
GitOps 是云原生应用程序部署和管理的新模式,能够极大的简化云原生应用程序的部署,提高开发人员和运维人员之间的协作效率。极狐GitLab 和 GitLab 在 13.x 版本中引入了对 GitOps workflow 的支持。详细的内容可以查看博客文章极狐GitLab Kubernetes Agent 是如何支持 GitOps workflow 的?。而 GitHub、Gitee 暂时没有对 GitOps 的支持能力。
从 Anchore 2021 年软件供应链安全报告中可以看出,安全将会是众多公司或者组织的首要工作,与软件供应链是否安全密切相关。在安全方面,极狐GitLab 和 GitLab 有七大安全利剑:容器镜像扫描、静态应用安全测试 (SAST)、动态应用安全扫描(DAST)、密钥检测、License合规、依赖项扫描以及模糊测试。DevSecOps 能力覆盖整个软件开发生命周期的各个阶段。GitHub 的安全能力是通过 Advanced Security [5] 来提供的,包含 Code scanning、Secret scanning、Dependency review等,但并不是覆盖软件开发全生命周期的。而 Gitee 仅仅通过 Gitee Scan [6] 来对代码缺陷、代码规范等做一些扫描,安全能力同样不是覆盖软件开发生命周期的。
极狐GitLab、GitLab 提供很多内置的第三方集成(诸如 Jenkins、Slack、Jira 等),而 GitHub 不提供内置的第三方集成,都是第三方提供对 GitHub 的集成。 Gitee 介于 极狐GitLab、GitLab 和 GitHub 之间,有少量的内置集成(如 Jenkins)。
极狐GitLab/GtiLab 均支持云原生的安装方式(Docker/Helm/Operator),而且均有官方的镜像和 Chart,能够方便用户在云原生的环境中运行极狐GitLab/GitLab 实例。GitHub 与 Gitee 由于不支持自主私有化,目前并不提供相关的镜像、Chart、Operator。
极狐GitLab/GitLab 已经和 Gitpod [7] 做了集成,能够帮助开发者快速构建云上的开发环境,提升开发效率和开发体验。GitHub 也可以与 Gitpod 完成集成,同时 GitHub 在被微软收购后也和自家的产品 Visual Studio Code 在融合,为开发者提供云开发环境。而 Gitee 到目前为止,没看到类似的功能特性。
GitHub 维基百科链接: https://en.wikipedia.org/wiki/GitHub;
GitLab 发展历史链接: https://about.gitlab.com/company/history/;
Gitee 维基百科链接: https://zh.wikipedia.org/wiki/Gitee;
极狐GitLab 官宣成立链接: https://mp.weixin.qq.com/s/r-f7JmK0Jt0dUu31_bXiWg
GitHub Advanced Security: https://docs.github.com/en/get-started/learning-about-github/about-github-advanced-security
Gitee Code Scan: https://gitee.com/CodeGenerates/CodeGenerate/gitee_scans
Gitpod 链接: https://www.gitpod.io/
GitHub Package 功能: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry