GitLab CI/CD 管線建置、管理與自動化 DevOps 應用

在現代軟體開發流程中，持續整合與持續交付（CI/CD）已成為不可或缺的環節。GitLab CI/CD 提供了強大的自動化能力，能有效簡化從程式碼提交到佈署的整個流程。本文將探討 GitLab CI/CD 管線的架構，解析其運作機制，並提供實務上的組態，幫助讀者建置高效的 CI/CD 流程。首先，我們會介紹 GitLab CI/CD 管線的基本結構，包含階段、工作和命令的定義，以及如何透過 .gitlab-ci.yml 檔案進行組態。接著，會說明如何使用 Docker Image 建立一致的執行環境，確保不同階段的工作都能順利進行。此外，文章也會探討 GitLab Runner 的安裝與組態，以及如何根據專案需求選擇合適的執行器。最後，我們將整合所有知識，展示一個完整的 CI/CD 流程範例，並提供一些實務上的最佳實踐建議，讓讀者能更有效地運用 GitLab CI/CD 提升軟體開發效率。

GitLab CI/CD 構建與管理

在轉換至本地化繁體中文風格後，玄貓將以更深入且實務化的方式，探討GitLab CI/CD管線的結構及應用。

GitLab CI/CD 管線結構

玄貓首先來討論GitLab的CI/CD管線結構，這個結構能讓我們瞭解如何自動化軟體開發過程中的各個環節，包括建置、測試及佈署。每一個提交到GitLab的程式碼變更都可以觸發一個新的管線執行，這樣可以確保每次變更都能夠被自動化測試及驗證。

管線的觸發方式

GitLab管線有多種觸發方式，玄貓將重點介紹以下幾種：

分支觸發：當我們提交到某個分支時，GitLab會自動觸發該分支的管線。
標籤觸發：當我們建立或更新某個標籤時，也可以觸發相關的管線。
手動觸發：開發者可以選擇手動執行某個分支或標籤的管線。

此外，GitLab還支援暫時性合併分支（Merge Request）的管線觸發。這對於需要在合併前進行測試及驗證的情況非常有用。

省略管線的情境

有時候，我們可能需要在特定提交中省略管線，以節省時間及計算資源。這可以透過在提交訊息中加入特定關鍵字來實作。例如，當我們在提交訊息中加入[ci skip]或[skip ci]時，GitLab會跳過該提交的管線執行。

解析GitLab CI/CD 管線狀態

瞭解如何檢視及解讀GitLab CI/CD 管線狀態是非常重要的。每一個管線例項都有其狀態（pass/fail），同樣地，每一個階段（stage）及工作（job）也都有各自的狀態。以下是一些常見的狀態：

running：正在執行中。
pending：等待資源可用。
skipped：因為前一階段失敗而跳過。
canceled：使用者手動取消。

檢視管線詳細資訊

在GitLab的GUI中，我們可以透過點選不同層級的圖示來檢視各個階段及工作的詳細資訊。例如，點選某個工作圖示可以看到該工作所執行的命令及其輸出結果。這對於debug及理解問題非常有幫助。

組態GitLab CI/CD 管線

要組態GitLab CI/CD 管線，我們需要在專案倉函式庫的根目錄中建立一個 .gitlab-ci.yml 檔案。這個檔案使用YAML語法來定義各個階段、工作及命令。以下是一些基本概念：

階段（stages）：定義了管線中的各個階段，例如build、test和deploy。
工作（jobs）：每一個工作都是一組命令，通常會被分配到某個特定階段中。
命令（commands）：在每一個工作中執行的具體操作。

stages:
  - build
  - test

build_job:
  stage: build
  script:
    - echo "Building the project..."

test_job:
  stage: test
  script:
    - echo "Running tests..."

內容解密：

上述範例中：

stages：定義了兩個階段 build 和 test。
build_job：這是一個屬於 build 階段的工作，包含了一條簡單的建置指令。
test_job：這是一個屬於 test 階段的工作，包含了一條簡單的測試指令。

這樣組態後，每次提交程式碼到GitLab時，都會先執行 build 階段中的所有工作，然後再執行 test 階段中的所有工作。

Docker Image 的使用

在 .gitlab-ci.yml 中我們也可以指定 Docker Image 來執行工作。這樣可以確保所有工作都在一致的環境中執行。以下範例展示瞭如何指定 Python Docker Image：

image: python:3.10

stages:
  - build
  - test

build_job:
  stage: build
  script:
    - echo "Building the project..."

test_job:
  stage: test
  script:
    - echo "Running tests..."

內容解密：

上述範例中：

image: python:3.10：指定了所有工作都要使用 Python 3.10 的 Docker Image。
其他部分與之前相同。

這樣組態後，所有工作都會在 Python 3.10 的環境中執行，確保了環境的一致性。

已完成結構化內容重寫與完整標題處理

此圖示說明瞭CI/CD管線中的各項階段及其流程：

  graph TD;
    A[Commit] --> B{Trigger Pipeline};
    B -- Yes --> C[Run Pipeline];
    B -- No --> D[No Action];
    C --> E[Build Stage];
    E --> F[Test Stage];
    F --> G{All Tests Passed?};
    G -- Yes --> H[Deploy Stage];
    G -- No --> I[Fail Pipeline];

此圖示展示了從提交程式碼到最終佈署或失敗的一整套流程。首先是決定是否要觸發管線，然後進行建置階段和測試階段，最後根據測試結果決定是否佈署或失敗。

處理流程說明

Commit: 引發整個CI/CD過程之始點。
Trigger Pipeline: 決定是否要啟動管道流程。
Build Stage: 初步建置專案。
Test Stage: 測試專案功能與效能。
All Tests Passed?: 測試結果決定是否進行下一步驟佈署。
Deploy Stage: 若所有測試透過則佈署專案。
Fail Pipeline: 若任何測試不透過則終止流程。

GitLab CI/CD Pipeline 組態

在現代軟體開發中，持續整合（CI）與持續交付（CD）已成為不可或缺的工具，而 GitLab 提供了強大且靈活的 CI/CD 管道功能。本文將詳細介紹如何組態 GitLab CI/CD 管道，並結合具體案例和實際經驗，探討每個步驟的細節。

初探 GitLab CI/CD 管道

GitLab CI/CD 管道是一系列自動化步驟，用於在專案的 Git 儲存函式庫中執行各種操作。每個專案僅有一個管道，但根據所執行的 Git 分支或標籤，可以選擇性地執行或忽略不同的步驟。管道的「持續整合」部分主要回答的是「程式碼是否良好？」這個問題，通常包括自動化測試、安全掃描、許可證合規檢查和程式碼品品檢查。

第一個工作任務：資料型別檢查

在這個範例中，我們首先定義了一個工作任務來執行 mypy 工具。mypy 是一個用來確保 Python 原始碼正確使用資料型別的工具。這個任務可以放在建置或測試階段，但為了確保建置階段至少有一個工作任務，我們將其放在建置階段。

data-type-check:
  stage: build
  script:
    - pip install mypy
    - mypy src/hats-for-cats.py

內容解密：

工作任務名稱：data-type-check 是這個工作任務的名稱，GitLab 會根據這行的內容來識別新的工作任務。
階段分配：stage: build 指定這個工作任務屬於建置階段。
指令清單：script: 關鍵字後面接的是這個工作任務要執行的指令。
- pip install mypy：使用 pip 包管理工具來安裝 mypy 包。
- mypy src/hats-for-cats.py：對 src/ 目錄下的 Python 檔案執行 mypy 工具，檢查資料型別使用是否正確。如果發現任何問題，mypy 會使這個工作任務失敗。

自動化單元測試

接下來，我們定義一個工作任務來執行自動化單元測試：

unit-tests:
  stage: test
  script:
    - pip install pytest
    - pytest test/ --junitxml=unit_test_results.xml
  artifacts:
    reports:
      junit: unit_test_results.xml
    when: always

內容解密：

工作任務名稱：unit-tests 是這個工作任務的名稱。
階段分配：stage: test 指定這個工作任務屬於測試階段。
指令清單：
- pip install pytest：使用 pip 安裝 pytest 包。
- pytest test/ --junitxml=unit_test_results.xml：對 test/ 目錄下的單元測試執行 pytest 工具，並將測試結果輸出到 unit_test_results.xml 檔案中。
藝術品設定：
- artifacts:：告知 GitLab 需要保留這些檔案作為藝術品（artifacts）。
- reports:：指定這些藝術品包含 JUnit XML 檔案。
- when: always：即使單元測試失敗也要保留這些藝術品。

GitLab CI/CD 管道結構

瞭解 GitLab 的 CI/CD 管道結構至關重要。以下是完整的 .gitlab-ci.yml 檔案範例：

stages:
  - build
  - test

image: python:3.10

data-type-check:
  stage: build
  script:
    - pip install mypy
    - mypy src/hats-for-cats.py

unit-tests:
  stage: test
  script:
    - pip install pytest
    - pytest test/ --junitxml=unit_test_results.xml
  artifacts:
    reports:
      junit: unit_test_results.xml
    when: always

補充說明：

階段定義：stages: 告知 GitLab 有哪些階段需要執行。
映像檔：image: 指定使用 Python 的 Docker 檔案。

問答集與圖示分析

問答集：

什麼是藝術品？ 藝術品是指在工作任務完成後需要保留的檔案。任何未宣告為藝術品的檔案都會在工作任務完成後被刪除。
為什麼要保留測試結果？ 測試結果是重要的資訊，即使測試失敗了也需要檢視詳細資訊以進行修正。
如何確保所有步驟都能正確執行？ 透過分階段組態和詳細指令設定，可以確保每個步驟都能正確執行並捕捉到問題。

  graph TD;
    A[Start] --> B[Build Stage];
    B --> C{Data Type Check};
    C -- Pass --> D[Test Stage];
    C -- Fail --> E[Pipeline Fail];
    D --> F{Unit Tests};
    F -- Pass --> G[Pipeline Success];
    F -- Fail --> H[Pipeline Fail with Reports];

此圖示展示了 GitLab CI/CD 的流程：

建置階段先進行資料型別檢查。
若資料型別檢查透過，則進入測試階段進行單元測試。
若單元測試透過，則管道成功；若單元測試失敗，則會生成報告並顯示測試結果。

全面組態與實踐建議

在實際應用中，GitLab CI/CD 的組態需根據專案需求進行調整。以下是一些實踐建議：

模組化組態：將常用的組態抽象成模組化檔案，方便不同專案之間共用。
自動化佈署：除了自動化測試外，還可以加入自動化佈署流程，提高開發效率。
安全掃描：加入安全掃描步驟，確保程式碼沒有漏洞和風險。
日誌管理：妥善管理和儲存日誌，方便問題追蹤和排除。

透過以上步驟和建議，玄貓希望讀者能夠更好地理解和應用 GitLab CI/CD 流程，提升軟體開發效率和品質。

GitLab CI/CD Pipeline 結構與自動化 DevOps 階段

GitLab CI/CD Pipeline 概述

在現代軟體開發中，持續整合（CI）與持續交付/佈署（CD）是兩大關鍵流程。GitLab 的 CI/CD Pipeline 就是這些流程的核心工具，它能夠自動化執行從程式碼提交到佈署的整個過程。這些過程包括建置、測試和佈署等多個階段。

GitLab 的 CD 部分主要解決的是「應該將程式碼佈署到哪個環境」這個問題，並負責實際將程式碼佈署到該環境中。包裝程式碼以便佈署也屬於 CD 流程的一部分。這些 CD 步驟的目的是讓特性和修補程式的釋出頻繁且可預測，同時風險低。

每個專案的 Pipeline 由一個或多個階段組成，每個階段包含一組具有相似主題的任務，例如建置、測試或佈署程式碼。每個階段又由一或多個作業組成，每個作業代表一個單元工作，例如編譯 Java 類別、執行自動化單元測試或將應用程式封裝成 Docker 映像。每個作業包含一或多個命令，這些命令是人類在終端機中手動執行的殼層命令。

Pipeline 通常會在每次提交程式碼到倉函式庫時執行，這樣就能隨時掌握程式碼狀態，無論是在特性分支、修補分支還是預設分支上。Pipelines 可以對 Git 分支或 Git 標籤執行，並可以自動或手動觸發。更複雜的形式則包括執行在合併後的程式碼上。

每個 Pipeline 的執行例項都有透過/失敗狀態（或其他少見狀態），而每個階段和作業內也有相應的狀態。這些狀態都可以在 GitLab GUI 中檢視。

Pipelines 基本上可以執行任何人類在終端機中打字所能執行的任務。每個專案都會使用特定領域語言在 .gitlab-ci.yml 檔案中組態其 Pipeline 的任務。剩下的內容將介紹如何使用 GitLab Runner 作為執行 Pipeline 工作的工具。

自動化 DevOps 階段

以下章節將深入介紹如何使用 GitLab CI/CD Pipelines 自動化 DevOps 流程中的常見手動步驟。完成後，你將能夠組態 Pipeline 執行多項關鍵任務：

透過執行品質掃描和功能測試來驗證程式碼。
透過安全掃描來確保程式碼和其依賴項的安全性。
自動執行標準建置和封裝工具來封裝程式碼。
自動將程式碼佈署到適當的環境。

以下是具體章節：

章節 5：安裝與組態 GitLab Runners
章節 6：驗證你的程式碼
章節 7：保護你的程式碼
章節 8：封裝與佈署你的程式碼

安裝與組態 GitLab Runners

GitLab Runners 概述

GitLab Runner 是 GitLab CI/CD 的核心元件之一，負責執行 Pipeline 的工作並將結果回報給 GitLab。GitLab Runner 是一種小型程式，安裝在主 GitLab 應用程式之外，目的是接收 GitLab 發行的新 CI/CD 工作並根據 .gitlab-ci.yml 檔案中的指示執行這些工作。

GitLab Runner 支援多種基礎架構型別，包括獨立伺服器、虛擬機器、容器等。

Runner 建構與平台支援

首先要了解的是 GitLab Runner 的架構以及它與其他常見工具之間的比較。接下來我們會介紹如何安裝並組態 Runner，使其能夠與 GitLab 配對以執行 CI/CD 工作。最後我們會討論不同情況下使用不同 Runner 型態及執行器（executor）的最佳實踐。

安裝 Runner Agent

安裝 Runner Agent 的步驟會因作業系統和基礎架構而異。一般來說，安裝過程包括下載安裝指令碼並執行它以完成安裝。

小段落標題

安裝步驟

sudo curl -L --output /usr/local/bin/gitlab-runner \
    "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64"
sudo chmod +x /usr/local/bin/gitlab-runner
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start

組態與註冊 Runner

完成安裝後，需要組態並註冊 Runner 與 GitLab 以便執行 CI/CD 工作。這包括生成註冊令牌並在終端機中註冊 Runner。

小段落標題

組態與註冊步驟

sudo gitlab-runner register

Enter the GitLab instance URL (for example, https://gitlab.com/):
https://gitlab.example.com/
Enter the registration token:
<your_registration_token>
Enter a description for the runner:
my-runner
Enter tags for the runner (comma-separated):
linux,x64
Enter an executor: shell, ssh, docker-windows, docker, kubernetes, custom, docker-auto, docker-ssh, parallels:
docker
Enter the default Docker image (e.g. ruby:2.6):
alpine:latest

不同情況下使用不同 Runner 型態及執行器

瞭解何時以及為什麼要使用不同型態及執行器（executor）的 Runner 是非常重要的。以下是一些常見情況及最佳實踐：

Shell Executor：適合簡單且輕量級的工作。
Docker Executor：適合需要隔離環境且需要依賴多種工具時。
Kubernetes Executor：適合大規模且需要高度可擴充套件性時。

支援不同基礎架構型別

GitLab Runner 支援多種基礎架構型別，包括獨立伺服器、虛擬機器和容器等。這使得它能夠靈活地適應不同規模和需求的專案。

最佳實踐建議

根據專案需求選擇適當的 Runner 型態及執行器（executor），並確保定期更新和維護 Runner 以保持安全性和穩定性。

完成了這些設定之後，你就能夠管理從建置、測試到佈署應用程式的完整生命週期了。

自動化 DevOps 階段：圖示說明

此圖示展示了自動化 DevOps 階段中各項步驟之間的關係及其流程：

  graph TD;
    A[Code Commit] --> B[Build Stage];
    B --> C[Test Stage];
    C --> D[Security Scan Stage];
    D --> E[Package Stage];
    E --> F[Deploy Stage];

段落標題：內容解密：

Code Commit：開發者將新變更提交到版本控制系統中。
Build Stage：Pipeline 執行編譯和建置步驟。
Test Stage：執行自動化測試以確保程式碼正常運作。
Security Scan Stage：進行安全掃描以檢查潛在漏洞。
Package Stage：將應用程式封裝為可佈署格式。
Deploy Stage：將應用程式佈署到指定環境。

採用自動化流程

透過以上圖示及說明，玄貓希望你能夠更清楚地理解自動化 DevOps 階段中的各項步驟及其流程。隨著技術不斷進步，GitLab CI/CD Pipeline 提供了強大且靈活的工具來幫助開發者自動化其轉型過程中的各項操作。

希望這篇文章能夠幫助你更好地理解和應用 GitLab CI/CD Pipeline 在 DevOps 流程中的角色與功能。

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。