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]。