在 Day03 提到了最基本的 .gitlab-ci.yml，而 GitLab CI 可遠不止可以完成一個一個的 Job 它至少還可以做些什麼呢？在今天的內容中我們將繼續往下談，談怎麼設定 GitLab CI 的工作流程。

一個包含驗證、測試、打包、釋出工作流程長怎麼樣？

在 GitLab 官方的手冊上，有底下的這一張 CI/CD basic workflow 的範例圖示，如果我們要在 .gitlab-ci.yml 描述如這範例中的流程，應該要怎麼做呢？

首先，從圖中可以看到其主要有 Verify、Package、Release 等三個階段，在 Verify 階段中主要完成原始碼的品質分析、效能測試、單元測試、相依性掃描等等工作，在 Package 階段中主要把如 Node Package、Docker image 等打包後置入各自對應的 Registry，或將可釋出的產品打包為「成品(artifact)」，Release 階段則是把打包後的成品如：各種品只檢測報告、原始碼等發布或部署到設定的位置，如圖片中的 Release 程序，就作了像是 GitLab Pages、Canary (金絲雀部署) 等等的工作。

分析後的工作流程階段及工作如何對應到 .gitlab-ci.yml

根據圖片上流程設計的分析，我們概略可以如下作分類：

• Verify
  • Code Quality
  • Performance testing
  • Unit Tests
  • …
• Package
  • Container Registry
  • NPM Registry
  • …
• Release
  • Auto Deploy
  • …

逐步設置 .gitlab-ci.yml - 設置關卡 Stage

假設分析後都已經知道每個工作(Job)在做什麼事情，那麼可以開始逐步完成 .gitlab-ci.yml 的設置。

首先是設置關卡，依據分類後的三個階段直接作為三個關卡 Verify、Package、Release，這部分在 .gitlab-ci.yml 中可以如下設定：

stages:
  - Verify
  - Package
  - Release

這部分即是宣告，我們總共有三個關卡「依序」為 Verify、Package、Release。

實務上分析後每個階段可能會再細拆為更多的關卡，像是比較快執行完的工作會放到比較前面的關卡、比較慢比較大的工作會放到比較後面的關卡，早點知道出問題可以提早停止流水線進行的工作也會放到比較前面的關卡等等的。

逐步設置 .gitlab-ci.yml - 建立工作 Job

接下來就是設置每個關卡下的每個工作，首先是 Verify 底下的工作，如 Code Quality 這個工作，假設它做的工作單純就印出自己的工作名稱。

Verify:CodeQuality:
  stage: Verify
  script:
    - echo 'Do Code Quality Job' 

在上面的原始碼中，建立的一個工作 Job，其名稱為 Verify:CodeQuality，這個命名包含了前綴關卡名稱，主要是在同一個 Git 儲存庫中，如使用一段時間後，通常會有眾多的工作執行紀錄，透過前綴關卡名稱這樣的命名法，可以相對較快速的了解其所屬的關卡。

接著，根據上面的元怎依序建立各個 Job 的描述。

建立後的完整 .gitlab-ci.yml 如下，可以在這邊看到完整的執行過程及細節。

stages:
  - Verify
  - Package
  - Release

Verify:CodeQuality:
  stage: Verify
  script:
    - echo 'Do Code Quality Job' 

Verify:PerformanceTesting:
  stage: Verify
  script:
    - echo 'Do Performance Testing Job' 

Verify:UnitTests:
  stage: Verify
  script:
    - echo 'Do Unit Tests Job'

Verify:ContainerRegistry:
  stage: Package
  script:
    - echo 'Do Build Docker Image Job'

Verify:NPMRegistry:
  stage: Package
  script:
    - echo 'Do Build NPM Package Job'

Verify:AutoDeploy:
  stage: Release
  script:
    - echo 'Do Auto Deploy Job'

Pipeline 執行的過程畫面如下：

如果有什麼 Script 是正式的 Script 執行前或執行後所有 Job 均需要完成的要怎麼設定？

在 GitLab CI 的語法中，有所謂的 before_script 以及 after_script 兩個設置值，其想要解決的就是在 script 執行前或後都必須執行的 Script。before_script 及 after_script可以單獨設定在單一個 Job 中，也可以設置在 default 這個keyword 特殊字工作內，供所有的工作一體適用。如下：

stages:
  - Verify
  - Package

default:
  before_script:
    - echo 'Before Script Executed'
  after_script:
    - echo 'After Script Executed'

Verify:CodeQuality:
  stage: Verify
  script:
    - echo 'Do Code Quality Job'
  after_script:
    - echo 'Override After Script'

Verify:PerformanceTesting:
  stage: Verify
  script:
    - echo 'Do Performance Testing Job'

Verify:ContainerRegistry:
  stage: Package
  before_script:
    - echo 'Override Before Script'
  script:
    - echo 'Do Build Docker Image Job'

在上面的這範例中，定義的三個工作(Job)，第一個工作「Verify:CodeQuality」其會覆寫 default 關卡中定義的 after_script 參數，走自己的路，第二個工作「Verify:PerformanceTesting」則會完全依據 default 設定的預設值，第三個工作「Verify:ContainerRegistry」則是覆寫 before_script 的部分。相關的執行結果此連結。

default 設置可以設定的參數還有這些。

如何初步驗證撰寫完成的 .gitlab-ci.yml 語法是否正確？

在每個專案的 Pipeline 頁面右上角，均有一個「CI Lint」的小工具，其可以協助 .gitlab-ci.yml 設置及開發的過程中，驗證現行的語法是否正確，可減少一些測試語法時的 git commit。

如下圖，將上面的 Script 執行可以得到驗證的結果

驗證後，可以初步看到每個工作的基本屬性及 before_script、script及after_script三個 Script 預計執行的內容與一些 Job 的參數。

總結

在這個章節裡，我們談到在已經有設計好一定流程的環境中，我們該怎麼逐步完成 .gitlab-ci.yml 的設計，其中介紹了 stages 的設置、before_script、script及after_script 三個 Script 的關係與 default 關卡的設置。

接下來，我們將繼續玩轉 GitLab CI，談談更多關於 .gitlab-ci.yml 的設置及語法。我是墨嗓(陳佑竹)，期待這系列的文章能夠讓人有些幫助。