# Outline
一、前言
二、概述
三、GitLab Runner
四、Job
五、Stage
六、Pipeline

# TL;DR
此篇文章是本系列文的導讀，會介紹文章的結構與常出現的資訊樣板；另外還有範例專案的使用方式；最後則是建議的閱讀順序，這部分會一直更新到本系列文結束為止。

在雙十連假前，此系列文每天的發文時都會以最簡陳述為主，以求在繁忙的日常中，至少能先維持挑戰鐵人賽的進度，並且逐漸拓展思路與系列結構。預期會在國慶連假將本篇文章論述完整。

一、前言

GitLab 是企業自行架設 Git Server 的主流選擇之一，而 GitLab 內建整合的 GitLab CI 與 Operations 的功能在現在講求持續整合與交付的環境中更是一大魅力。今天就先讓我們來了解一下 GitLab CI 的基本概念吧！

二、概述

GitLab CI 把執行指令的最小單位稱作為 Job，在 Job 裡面可以放一到多筆指令腳本，並且設定這個腳本執行的環境。而每一個 Job 都會被所謂的 GitLab Runner 執行，GitLab Runner 可以說是依照 Job 設定所建立出來的執行環境。而每個 Job 都會屬於一個 Stage，一個 Stage 中可以有多個 Job，在同一個 Stage 裡的 Job 在 Runner 足夠多的情況下，可以同時執行。通常一個 Stage 的 Jobs 都完成後才會進入下一個 Stage。而多個 Stage 串起來的執行流程就稱作 Pipeline。

三、GitLab Runner

GitLab Runner 可以說是執行 Job 的環境介面，這個介面有許多實作，這些實作就是所謂的 Executors。GitLab Runner 提供多種 Executor 實作，分別有 SSH、Shell、VirtualBox、Parallels、Docker、Kubernetes、Custom。每種 Executor 所能提供的功能與隔離程度都不太一樣，最常見的就是 Shell Executor 和 Docker Executor。

Shell Executor 是最好設定的 Executor，因為它其實就是讓 Job 在安裝該 Executor 的環境直接執行，所以若我們是使用自己的工作用電腦或是租用的 VPS 安裝這類 Executor，就必須注意環境污染以及安全的議題。

Docker Executor 則是會依照 Job 所指定的 image 去建立對應的 container 執行 Job，所以擁有較好的隔離性與安全性。

四、Job

如概述所說，Job 可以說是 GitLab CI 執行指令的最小單位，也可以說是腳本的容器。一個 Job 可以擁有三種腳本，分別是前置 (before scripts)、主要 (scripts)、後製腳本 (after script)，如其名就是依照這樣的順序去執行。會有這樣的設計和 Job 的另外一個特點有關，就是繼承。所以我可以為同一類 Job 在父類 Job 設置相同的前、後置腳本，然後只有主要腳本有所不同。

此外 Job 也可以指定環境變數、觸發條件、相依關係等等，讓腳本在執行上可以透過這些設定去客製化環境。而每個 Job 都會有一個對應的 Stage，讓 GitLab 知道該在哪一個 Stage 去執行。

五、Stage

GitLab CI 可以去設定該次 Pipeline 有多少個 Stages，Stages 是一個有順序的執行關係。只有前一個 Stages 沒有失敗，才會接續下一個 Stage。

六、Pipeline

一份 GitLab CI 設定檔所描繪的就是一個 Pipeline，而一個 Pipeline 可以說就是一次 CI/CD 的過程，其中透過各個 Job 與 Stage 完成各項整合、交付與部署。而這個 Pipeline 也會隨著 Job 不同的觸發條件而有所不同。