GitLab - 维基百科，自由的百科全书

GitLab


网站类型	Git仓库托管服务 DevOps平台^[1]
语言	英语
股票代号	NASDAQ：GTLB^[2]
业务范围	全世界
持有者	GitLab Inc.
创立者	Sid Sijbrandij Dmitriy Zaporozhets Valery Sizov
代表人物	Sid Sijbrandij (CEO) Dmitriy Zaporozhets (CTO)
产业	软件行业
营业额	▲ 1.522亿美元 (2021年)^[3]
员工	1,765^[4]（截至2022年4月 (2022-04)^[update]）
网址	gitlab.com
商业性质	是
注册	可选
推出时间	2011年，13年前（2011）
现状	在线
编程语言	Ruby、Go和Vue.js

GitLab Application
当前版本	17.6.1（2024年11月26日；稳定版本）^[6]
原始码库	gitlab.com/gitlab-org/gitlab
编程语言	Ruby、Go和JavaScript
操作系统	跨平台
平台	x86-64和ARMhf
许可协议	MIT许可证 (社群版)^[7]/商业许可 (商业版)
网站	商业版（包括专有组件）：about.gitlab.com 社群版（不含专有组件）：gitlab.com/gitlab-org/gitlab

GitLab是由GitLab公司开发的、基于Git的集成软件开发平台。^[8]^[9]另外，GitLab且具有wiki以及在线编辑、issue跟踪功能、CI/CD等功能。在2018年，GitLab被认为是一家部分是乌克兰的独角兽企业。^[10]^[11]

CI/CD

GitLab CI/CD是GitLab内建的一款工具，用于通过持续方法论（页面存档备份，存于互联网档案馆）（continuous methodologies）的软件开发。该持续方法论包含三个部分：持续集成、持续交付、持续部署。^[12]^[13]

持续集成（Continuous Integration，简称CI），每次在上传代码块到基于Git仓库时，持续集成会运行脚本去构建、测试、校验代码，这些操作是在合并到默认分支之前进行的。
持续交付（Continuous Delivery，简称CD），在持续集成之后（即合并到默认分支之后），持续交付将进行手动部署应用。
持续部署（Continuous Deployment，简称CD），在持续集成之后（即合并到默认分支之后），持续部署将进行自动部署应用。

原理

当开发者配置了GitLab CI/CD，那么当开发者使用Git提交（commit），那么就会触发CI/CD相关的一系列操作。这一系列操作由GitLab Runner执行，相关配置记载于.gitlab-ci.yml文件中，执行的结果将在GitLab页面中展示。^[14] 每一次的提交（commit）将会触发一条流水线（pipeline），流水线是不同阶段（Stage）的任务（Job）的一个集合。^[14] 阶段（Stage）用于逻辑切割，同一阶段的任务以并行方式执行，阶段间是顺序执行，上一个阶段执行失败，下一个阶段将不会执行。^[15] .pre 为第一阶段（译为：之前）和 .post 最后阶段（译为：提交时），这两个阶段不需要被定义，也无法被修改。^[16]

示例如下：

stages:
  - build
  - test
  - deploy

job 0:
  stage: .pre
  script: make something useful before build stage

job 1:
  stage: build
  script: make build dependencies

job 2:
  stage: build
  script: make build artifacts

job 3:
  stage: test
  script: make test

job 4:
  stage: deploy
  script: make deploy

job 5:
  stage: .post
  script: make something useful at the end of pipeline

任务（Job）可以构建Artifacts ，提供用户下载。^[14] 利用场景如下：在Android项目中，当配置了自动化构建Artifacts后，每次提交（push）代码后，GitLab CI/CD 将自动构建 APK文件，并在GitLab的页面上提供下载按钮。任务（Job）可以自动部署文件到外部伺服器，并通过 GitLab 页面查看该伺服器现今部署的状态，以及进行重新部署（re-deploy）等操作。通过使用设定 environment 的 name 和 url ，还可以在GitLab页面上直接查看网站。^[17]^[18] 通过该操作可以达到持续部署的目的。^[18]

deploy_staging:
  stage: deploy
  script:
    - echo "Deploy to staging server"
  environment:
    name: staging
    url: http://172.23.0.2:5000/
  only:
  - master
  tags:
    - Runner名称

GitLab Runner

GitLab Runner 是一项开源项目，用于执行任务（Job），并将执行结果传输回GitLab。^[19]

Runner 可安装在操作系统，也可以通过Docker的方式安装。当 Runner 安装后，需要将其注册在 GitLab 中，方可使用。Runner 有若干种执executor可供使用，如：Docker、Shell、SSH。^[19] Runner 默认使用Shell，Shell模式下，所有构建都会发生在Runner安装的机器中，操作十分简单，但是缺点很多。^[20]^[21]

.gitlab-ci.ym 文件中通过 tags 关键词选择Runner。^[22]Runner 的相关配置在 config.toml 文件中记载。^[23]

与Docker集成

对基于Docker的项目进行构建和测试，有几种方式。一种方式是，使用shell executor进行Docker CLI命令操作。另一种方式就是使用Docker executor进行操作，它是官方推荐的操作，executor通过在Docker中使用 Docker-in-Docker （页面存档备份，存于互联网档案馆）镜像进行Job相关操作。^[24]

事件

GitLab于2017年1月31日发布一系列紧急通告称，位于荷兰的系统管理员因操作失误而删除了包含310GB产品资料的文件夹，在取消删除操作后仅剩下4.5GB。运维人员之后检查发现，网站宣称和配备的多项备份措施均未正常运作或难以利用。GitLab在YouTube直播了恢复资料的过程^[25]。网站最终丢失了最后 6 小时的数据库数据（包括问题、合并请求、评论、片段等，不含代码库）^[26]。