GitLab CI

GitLab Runner 是什麼#

GitLab CI 的執行引擎稱為 Runner——它是實際跑你 CI/CD Job 的代理程式。
Runner 獨立於 GitLab 伺服器，可以安裝在任何機器上。

Runner 的兩種註冊方式：

Executor 決定了 Job 在什麼環境中執行，這是架設 Runner 時最重要的選擇：

Executor	適用場景	隔離性	效能
Shell	快速試用、簡單任務	低（直接在主機執行）	高
Docker	多數場景的最佳選擇	中（容器隔離）	中
Docker Machine	自動擴縮容量	中	依雲端資源
Kubernetes	K8s 環境，大規模並行	高（Pod 隔離）	依叢集資源

Docker Executor 是大多數團隊的最佳起點。
它提供足夠的隔離性，且 Job 之間不會互相污染環境。
Shell Executor 雖然簡單，但多個 Job 共用主機環境容易產生難以追蹤的問題。

GitLab CI 的設定全部寫在專案根目錄的 .gitlab-ci.yml：

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Building..."

.gitlab-ci.yml 支援 include 語法，
可以將共用的 Pipeline 定義抽到獨立檔案或其他專案中，實現跨專案的 Pipeline 模板共享。

書中涵蓋了主流的分支策略：

沒有「最好的」分支策略，只有最適合你團隊的。
如果你的產品是 SaaS 持續部署，GitHub Flow 或 GitLab Flow 就夠了。
如果是需要維護多版本的套件，Git Flow 較合適。

常見的 CI 問題與排查方向：

Pipeline 沒有被觸發：檢查 .gitlab-ci.yml 語法、Runner 是否在線、分支是否匹配 only/except 或 rules 條件
Runner 連不上：確認 Runner 的 registration token 是否正確、網路是否可達 GitLab 伺服器
Service 容器無法連線：確認 services 區塊的 alias 設定與程式碼中的連線位址是否一致

當 CI 出問題時，第一步永遠是查看 Job Log。
GitLab 的 CI Log 通常會清楚指出錯誤原因，不要急著改設定重跑。

進階用法：

排程 Pipeline 是自動化的好幫手。
常見用途包括：每日凌晨跑完整測試套件、每週執行依賴更新檢查、定期建構最新的 Docker Image。