前言

在軟體開發過程中，經常需要不斷進行測試和程式更新。然而，面對需求變更甚至新功能的開發，如何讓工程師能夠更專注於「coding」，並節省測試和人工部署的時間呢？因此，近年來軟體業界提出了「CI / CD」的概念，透過自動化的方式來減少開發過程中的成本，降低人工操作的負擔。本篇文章將介紹如何使用「GitLab-CI」作為自動化工具，並撰寫 GitLab-CI 腳本，在每次 Push Commit 時觸發 CI 事件，實現網頁服務的自動建置與部署。

GitLab 簡介

GitLab 是一個整合了版本控制、CI/CD、自動化部署和專案管理的開源平台。它不僅提供 Git 儲存庫功能，還包括強大的協作工具，適合開發者和團隊進行軟體開發和交付的全流程管理。許多知名的開源專案都在 GitLab 上託管，例如 Inkscape，這是一款開源的向量圖形編輯器，支援 SVG 格式，廣泛應用於設計和插畫領域，深受設計師社群的喜愛。

GitLab 提供了靈活的工作流程，使開發者能夠在同一平台上進行從程式碼管理到產品交付的所有操作。

何謂 CI / CD？

CI（持續整合，Continuous Integration）與 CD（持續交付/持續部署，Continuous Delivery/Continuous Deployment）是現代軟體開發流程中重要的自動化概念。

• CI（持續整合）：指的是開發者頻繁地將程式碼變更整合到主分支中，並且每次整合後都會自動進行測試。這樣可以及時發現並解決程式碼中的問題，確保每次提交的程式碼都保持高品質並可順利運行。
• CD 有兩種形式：
  • 持續交付（Continuous Delivery）：在這個過程中，經過測試和驗證的程式碼變更會被自動準備好部署，但仍需要手動確認或批准後才進行部署。
  • 持續部署（Continuous Deployment）：相比之下，持續部署會將每個通過測試的程式碼變更自動部署到生產環境中，完全不需要手動干預。

CI / CD 透過自動化的流程，減少人工操作的風險，縮短軟體的發布周期，讓開發團隊可以更快、更可靠地將新的功能或修正推送至使用者端。

常見的 CI 工具

選擇適合的 CI 工具應該根據團隊的開發環境、所使用的語言、專案規模以及對自動化流程的需求來決定。對於已經使用 GitLab 或 GitHub 進行版本控制的團隊，內建的 CI 工具（如 GitLab CI/CD、GitHub Actions）可能是最佳選擇。而對於大規模、複雜的專案，Jenkins 可能提供最靈活的擴展性。此外，如果團隊對於 CI/CD 流程的效能有高需求，CircleCI 也是值得考慮的選擇。

• Jenkins 是一個開源的 CI 工具，以高度擴展性著稱，支援多種語言和自動化流程，適合需要客製化的大型專案。
• GitLab CI/CD 與 GitLab 完美整合，內建於平台中，適合使用 GitLab 進行版本控制的團隊，支援簡單的自動化腳本撰寫。
• GitHub Actions 是 GitHub 提供的 CI/CD 工具，深度整合 GitHub，可自動化工作流程，適合使用 GitHub 的開發團隊。
• CircleCI 是雲端化的 CI/CD 工具，以高效能和易於配置著稱，適合容器化開發的團隊，支援 Docker 與 Kubernetes。
• Travis CI 與 GitHub 深度整合，設定簡單，適合開源專案與小型專案，提供免費計劃。

GitLab CI/CD 流程簡介

持續整合 CI(下圖左側)

專案處於開發階段時，代碼被存放在 GitLab 的 Repository 中。開發人員每天推送新的程式碼，GitLab 的持續整合 CI 會自動依照設定的腳本進行建構與測試，減少錯誤發生的可能性。這種自動化流程稱為持續整合，針對每次提交或開發分支的變更，系統會自動進行建構和測試，確保新變更符合專案的測試要求。

持續部署 CD(下圖右側)

持續部署讓專案的部署過程自動化，不再需要手動操作，完全無需人工干預。這不僅加快了部署速度，還大幅減少了人為錯誤的發生。透過這種方式，開發團隊能更專注於編寫程式碼，提升工作效率，並確保每次更新都能順利且無縫地推送到生產環境。

What is .gitlab-ci.yml?

.gitlab-ci.yml 是 GitLab CI/CD 的配置檔案，放置在專案的根目錄，用來決定 GitLab CI 的工作內容。當你每次推送專案時，GitLab 會自動讀取此檔案，並使用 GitLab Runner 來執行 pipeline。這個檔案使用 YAML 語言來定義執行的階段、規則與任務，類似 Python 的縮排代表層級關係。

.gitlab-ci.yml 檔案結構

stages:
    - stage_1
    - stage_2
		
image: alpine:latest

• stages：定義 Pipeline 中的階段與執行順序。
• image：指定執行環境，這裡使用輕量化的 Linux 映像檔（Alpine）。

job_A:
    stage: stage_1
    script:
        - touch hello.txt
        - echo 'Hello world!' > hello.txt
    artifacts:
        paths:
            - hello.txt

• script：設定此 Job 的執行內容。 artifacts: 當 stage 結束時會保留的檔案，以便別的 job 取用。

job_B:
    stage: stage_1
    script:
        - exit 1
    allow_failure: true

• allow_failure：允許此 Job 失敗，後續階段仍會執行。

exit 1 強制設定 job 為 failed (0 為 success)

其他參數

Cache vs Artifacts

一個完整的 .gitlab-ci.yml 撰寫

GitLab CI/CD 的運作原理是，在專案根目錄中新增一個名為 .gitlab-ci.yml 的文件，這是設定建構、測試和部署流程的腳本。該文件可以定義執行命令的順序、部署位置、以及是否自動或手動觸發等規則。當這個文件被放入 Repository 後，GitLab 會自動啟動 GitLab Runner 工具，依照腳本來執行指定流程。接下來，我們將介紹 .gitlab-ci.yml 文件的基本編寫方式與運行流程。

stages:
  - build
  - test
  - deploy

cache:
  paths:
    - config/

build-job:
  stage: build
  script:
    - echo "Hello, $GITLAB_USER_LOGIN!"

test-job1:
  stage: test
  script:
    - echo "This job tests something"

test-job2:
  stage: test
  before_script:
    - echo "This job tests something, but takes more time than test-job1."
  script:
    - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
    - echo "which simulates a test that runs 20 seconds longer than test-job1"
    - sleep 20

deploy-prod:
  stage: deploy
  script:
    - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."

這份 .gitlab-ci.yml 檔案定義了 CI/CD 的多個階段和工作：

• stages：設定了三個階段：build、test 和 deploy。這是 CI/CD 流程中的主要步驟。
• cache：將 config/ 路徑下的文件緩存，避免每次重新構建都重新下載或處理同一批文件，節省時間。
• build-job：屬於 build 階段，執行腳本會顯示訊息 "Hello, $GITLAB_USER_LOGIN!"，其中 $GITLAB_USER_LOGIN 是變數，顯示推送者的名稱。
• test-job1：屬於 test 階段，執行簡單的測試，顯示訊息 "This job tests something"。
• test-job2：也是 test 階段，但相較於 test-job1，增加了 before_script，執行前的設定指令，並且增加了延遲 20 秒的測試模擬。
• deploy-prod：屬於 deploy 階段，負責將來自特定分支的內容部署，顯示訊息 "This job deploys something from the $CI_COMMIT_BRANCH branch."，其中 $CI_COMMIT_BRANCH 代表當前分支。
• before_script：這部分用來執行需要在主要指令前運行的指令，通常用來進行環境設定或安裝依賴項目。
• script：主要指令區塊，這裡會執行實際的腳本，通常包含多行指令，依序執行。

在 GitLab CI/CD 的設定中，stages 和 job 名稱可以任意命名。

當我們將 .gitlab-ci.yml 文件與專案一同推送到 GitLab 後，系統會自動開始執行其中所寫的腳本，並顯示整個執行過程的詳細狀況。

GitLab CI Runner

GitLab CI Runner 是 GitLab CI/CD 用來執行工作任務的工具。當 GitLab CI 要執行腳本時，Runner 會負責在指定的環境中執行這些指令。根據需求，GitLab 提供兩種 Runner：

• 共享 Runner (Shared Runners)：由 GitLab 提供，所有專案可共享使用，適合一般開發需求。
• 自架 Runner (Specific Runners)：由使用者自行架設，只能用於特定專案，適合需要自訂環境或資源的情境。

共享 Runner (Shared Runners)

由 GitLab 提供的 Runner，適用於整個 GitLab 平台上的所有專案。這些 Runner 由 GitLab 主動管理和維護，用戶無需自行設置或配置。它們非常適合於快速上手、或小型專案，不需要專屬的執行環境。共享 Runner 可以自動調度，當有多個專案需要使用時，GitLab 會負責資源分配與執行，不過因為是共用資源，可能會有排隊等待的情況。可以在 repository Settings → CI / CD → Runners 中找到。

自架 Runner (Specific Runners)

是由使用者自行設置的 GitLab Runner，專門用於特定的專案或群組。當公司自行架設 GitLab 時，除了 GitLab Server，還需要額外配置一台電腦或伺服器作為 Runner 來執行 CI/CD 任務。自架 Runner 提供了更高的靈活性，可以針對特定的硬體需求、軟體環境或資源進行最佳化設定，適合需要自訂 CI/CD 流程的企業或大型專案。這使得專案執行更具控制性和效率。

詳細自建 Runner 可以參考: GitLab Runner 開始跑吧! Windows自價 Runner 可以參考 如何使用 GitLab CI 也推薦觀看高見龍系列的教學為你自己學 GitLab CI/CD

Reference

• 如何從頭打造專屬的 GitLab CI/CD
• GitLab CI / CD 實踐
• GitLab CI系列文

版主10在2020年首次開設YouTube頻道，嘗試拍攝程式教學。想要了解更多的朋友歡迎關注我的頻道，您的訂閱就是最大的支持～如果想學其他什麼內容也歡迎許願XD
https://www.youtube.com/channel/UCSNPCGvMYEV-yIXAVt3FA5A