GitLab CI/CD 管道結構深度解析與實踐

– 10 分鐘閱讀

GitLab CI/CD 管道是現代軟體開發流程中不可或缺的一環，它將程式碼的建置、測試和佈署流程自動化，大幅提升了開發效率和軟體品質。本文從基本概念出發，逐步解析 GitLab CI/CD 管道的核心組成：階段、工作和指令，並闡述它們之間的邏輯關係。透過 YAML 程式碼範例，實際演示如何組態一個簡單的 GitLab CI/CD 管道，以及如何定義不同階段的任務。此外，文章也說明瞭如何觸發管道執行、監控管道狀態，以及如何解讀 GitLab 提供的管道執行資訊，例如程式碼版本、提交訊息、提交者和執行時間等。文章更進一步探討 CI 和 CD 的具體內涵，CI 階段涵蓋各種測試、掃描和檢查，確保程式碼的品質和安全性；CD 階段則專注於程式碼的佈署，將程式碼自動佈署到不同的環境，例如測試環境、預生產環境和生產環境。最後，文章結合實際案例，展示 GitLab CI/CD 如何應用於真實的軟體開發場景，並展望未來 CI/CD 的發展趨勢以及在技術選型方面的考量。

GitLab 的 CI/CD 管道結構

接下來，我們將探討 GitLab 的 CI/CD 管道結構，這是 GitLab Flow 中的核心部分。玄貓將帶你瞭解什麼是持續整合（CI）和持續交付（CD），以及它們如何解決驗證、封裝和發布等階段的問題。這一章節將涵蓋以下幾個主要主題：

  • 定義「管道」、「CI」和「CD」
  • 管道的組成部分：階段、工作和指令
  • 執行 GitLab CI/CD 管道
  • 語讀 GitLab CI/CD 管道狀態
  • 組態 GitLab CI/CD 管道

技術需求

為了最大化學習效果，建議你有一個 GitLab 例項（自行管理或軟體即服務，SaaS）的帳戶，並能夠登入和使用，以便實踐和驗證本章所討論的概念。

定義「管道」、「CI」和「CD」

什麼是管道？

GitLab CI/CD 管道是一系列在你提交更改到 GitLab 託管的倉函式庫時執行的一系列步驟。這些步驟可能包括各種測試、掃描程式碼以確保其品質、包裝程式碼以便佈署以及佈署程式碼到適當的環境。

持續整合（CI）

持續整合是指開發者經常將程式碼變更合併到主分支，並在每次合併時自動執行測試以確保程式碼品質。這有助於早期發現和修復問題。

持續交付（CD）

持續交付則是將已經透過測試的程式碼自動佈署到生產環境或預生產環境中。這確保了程式碼可以快速且可靠地交付給使用者。

管道的組成部分

GitLab CI/CD 管道由多個階段（stages）、工作（jobs）和指令（commands）組成。每個階段可以包含多個工作，而每個工作則由一系列指令組成。

階段（Stages）

階段是管道中的一個邏輯分割槽，通常代表一個特定的任務集合。例如，測試階段可能包括單元測試、整合測試和效能測試。

工作（Jobs）

工作是階段中的具體任務，它們通常是一系列指令的集合。例如，在測試階段中，你可能會有一個單元測試工作和一個整合測試工作。

指令（Commands）

指令是工作中的具體操作，例如執行測試、編譯程式碼或佈署應用程式。

stages:
  - build
  - test
  - deploy

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

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

deploy_job:
  stage: deploy
  script:
    - echo "Deploying the application..."

內容解密：

這段程式碼定義了一個簡單的 GitLab CI/CD 組態檔案。它包含三個階段：構建、測試和佈署。每個階段都有一個對應的工作，這些工作分別執行構建、測試和佈署操作。build_job 在構建階段執行，並執行一個簡單的構建命令；test_job 在測試階段執行，並執行單元測試和整合測試；deploy_job 在佈署階段執行，並執行佈署命令。這些指令展示瞭如何在不同階段中組態不同的任務來自動化整個軟體開發流程。

執行 GitLab CI/CD 管道

GitLab 提供多種方式來觸發管道執行。最常見的是在提交程式碼時自動觸發，但你也可以手動觸發或使用 Webhook 或 API 來觸發。

語讀 GitLab CI/CD 管道狀態

觀察管道狀態是使用 GitLab 構建軟體時的一項常見操作。你可以檢視整體管道狀態以及每個階段和工作的狀態。這有助於快速識別問題並進行除錯。

組態 GitLab CI/CD 管道

組態一個簡單的 Hello World 風格的管道可以幫助你開始使用 GitLab 的 CI/CD 功能。以下是一個基本組態範例：

stages:
  - build
  - test

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

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

內容解密：

這段程式碼展示了一個簡單的 GitLab CI/CD 組態檔案。它包含兩個階段：構建和測試。build_job 在構建階段執行，並執行一個簡單的構建命令；test_job 在測試階段執行，並執行測試命令。這些指令展示瞭如何在不同階段中組態不同的任務來自動化應用程式構建和測試過程。

問答集錦

  1. 什麼是 GitLab 的 CI/CD？ GitLab 的 CI/CD 是指持續整合與持續交付/佈署。持續整合（CI）意味著經常將程式碼變更合併到主分支並自動執行測試；持續交付/佈署（CD）則是在程式碼透過測試後自動佈署到生產環境或預生產環境。

  2. GitLab 的 CI/CD 工作流程如何解決 SDLC 中 Verify、Package 和 Release 的問題？ GitLab 的 CI/CD 工作流程透過自動化測試、封裝和佈署過程來解決 SDLC 中 Verify、Package 和 Release 的問題。這樣可以確保程式碼品質、減少手動操作錯誤並加快交付速度。

  3. 如何組態一個簡單的 GitLab CI/CD 管道？ 組態一個簡單的 GitLab CI/CD 管道需要建立一個 .gitlab-ci.yml 檔案並在其中定義不同的階段、工作和指令。例如，你可以定義 build 和 test 階段，並在每個階段中組態相應的工作來執行構建和測試命令。

  4. GitLab 的 CI/CD 有哪些觸發方式？ GitLab 的 CI/CD 有多種觸發方式，包括自動觸發（如提交程式碼）、手動觸發、Webhook 和 API 呼叫等。

  5. 如何檢視 GitLab CI/CD 錄錄狀態？ 檢視 GitLab CI/CD 錄錄狀態可以透過 GitLab 的圖形使用者介面（GUI）來實作。你可以檢視整體鍊錄狀態以及每個階段和工作的狀態，這有助於快速識別問題並進行除錯。

清晰明瞭地展示邏輯關係

以下為此圖示展示邏輯關係：

  graph TD;
    A[提交程式碼] --> B[觸發GitLabCI/CI]
    B --> C[執行構建]
    B --> D[執行測試]
    B --> E[執行佈署]

此圖示展示了從提交程式碼開始的一系列步驟：觸發GitLabCI/CI後依序進行構建、測試及佈署等操作過程

GitLab CI/CD Pipeline 結構解析

在理解 GitLab 的 CI/CD Pipeline 之前，我們必須先熟悉其基本結構與功能。GitLab 的管線列表不僅顯示每次管線執行的透過或失敗狀態，還能告訴我們是否有任何管線「卡住」或無法執行。它顯示每個管線執行的程式碼版本、觸發管線的提交訊息、提交者、管線開始時間以及執行時間（如果已完成）。

GitLab 的管線列表

此列表提供了取消正在執行中的管線的圖形使用者介面（GUI）控制。對於一些複雜的管線，可能需要幾分鐘甚至幾小時才能完成。如果你的專案有限制的管線分鐘數，當某些微小的檔案變更觸發管線時，你可能想要取消該管線以節省分鐘數。

此外，此列表還提供了重新執行任何管線的 GUI 控制。例如，如果一個管線因為暫時性的網路問題而失敗，你可能會想要重新執行它。

以下是「Hats for Cats」專案的管線列表，包含正在執行和已完成的管線。表格以逆時間順序列出管線，最新的管線在最上面。你可以看到兩次管線執行已以「透過」狀態完成，一次以「失敗」狀態完成，而最新的兩個管線仍在執行。不要擔心每一行中描繪各部分狀態的圖示；我們會在本章稍後進行詳細說明。

此圖示

graph TD
    A[最近的兩個管線] --> B[正在執行]
    C[前兩個管線] --> D[已完成]
    D --> E[透過]
    D --> F[失敗]

CI 和 CD 的定義

雖然每個 GitLab 專案只定義了一個管線，但幾乎每個管線都由兩部分組成：CI 和 CD。CI 部分專注於回答「你的程式碼是否良好？」這個問題，而 CD 部分則關注程式碼應該佈署到哪裡並將其佈署到那裡。

CI - 持續整合

CI 代表持續整合（Continuous Integration），這不是 GitLab 特有的術語，而是大多數軟體公司都認同和理解的一個標準術語。你可以將其視為確保你正在編輯的任何檔案能夠與專案穩定程式碼函式庫良好整合的一部分。具體來說，當你將功能或修補分支合併到預設分支時，是否會出現新問題？早期發現這些問題有助於更容易和經濟地修復它們。

CI 部分透過在你將程式碼提交到 GitLab 主機上的專案 Git 儲存函式庫時執行測試、掃描和其他檢查來實作這一點。至少，這是 GitLab 管線的預設行為。你可以覆寫此行為，使得每次提交不執行管線，但這裡不討論這些原因。

以下是可能 CI 相關步驟的一部分清單：

  • 功能測試：你的軟體是否按照預期執行？這包括品質保證（QA）團隊花費大量時間編寫的迴歸測試。
  • 安全掃描：你的程式碼是否引入任何安全漏洞？
  • 程式碼品質掃描：你的程式碼是否遵循最佳實踐（如類別長度、空白使用等風格考量）？
  • 效能測試：你的程式碼是否滿足效能預期？
  • 許可證掃描：所有程式碼依賴項是否使用與主專案許可證相容的軟體許可證？
  • 模糊測試：是否可以透過傳遞異常長字串、超出預期範圍的數字或其他奇怪或極端資料作為輸入來觸發程式碼當機或意外錯誤？

由於 GitLab 提供了對這些檢查型別的一流支援，因此它們很容易在 CI 管道中啟用。但是你可以將任何工具、掃描或檢查整合到 GitLab 管道中。我們稍後會學習如何做到這一點，但現在你知道的是：任何可以從命令列執行的工具（無論是商業、開源還是自製）都可以新增到 GitLab 管道中。

CI 的優勢

CI 的主要優勢之一就是它促進了「左移」理念。越早執行測試，越早發現問題；越早發現問題，修復起來就越輕鬆和便宜。「左移」盡可能多的軟體開發任務會帶來巨大回報。

CI 的另一個優勢，特別是在結合 GitLab 透明的「單一視窗」監控開發生命週期時，是它促進了協作。例如，當安全測試頻繁執行時，讓整個團隊瞭解專案安全狀況。我們是否正在引入未預期的漏洞？開發人員是否需要調整他們的編碼方法或架構以減少下個月新增新功能時引入更多漏洞？

CD - 持續交付與持續佈署

CD 的術語比較模糊，GitLab 使用它來表示持續交付（Continuous Delivery）或持續佈署（Continuous Deployment）。兩者都涉及決定程式碼應該佈署到哪個環境以及實際執行該佈署。

CD 是將你開發出來經過多次測試後才放入實際產品環境中供使用者操作上去。CD 專注於回答「你的程式碼應該被佈署到哪裡？」並將其實際佈署到那裡。

對於大部分軟體開發團隊而言，通常會設定多種環境以用於佈署程式碼：

  1. 功能測試環境：用於進行功能測試。
  2. 效能測試環境：用於進行效能測試。
  3. 模仿生產環境：用於識別並解決在生產環境中可能出現錯誤。
  4. 生產環境：實際供真實使用者操作。

GitLab 應用同樣思維去處理各種環境下去佈署程式碼。

CI/CD 在單一管道中的運作方式

GitLab 不會有分開的是 CI 和 CD 的兩個不同單獨工作流程去管理 ，而是透過一套自動化流水程式來完成所有工作流程。 每一次提交跟觸發條件都會被包含在此流水程式內進行檢驗跟處理 以下就是完整Pipeline：

流水號

  graph TD
    F[F]
    A[提交] --> B{進入管理流水號}
    B -->|成功| C[開始執行CI]
    B -->|失敗| D[報錯]
    C --> E[依序進行多種測試]
    E --> F{測試結果}
    F -->|成功| G[開始CD]
    F -->|失敗| D
    G --> H[依序進行多種佈署]

內容解密：

  1. 提交：當我們將特定分支進行提交時就會被推入這個流水號。
  2. 流水號：所有推播進來所進行確認跟管理之處。
  3. CI：進入持續整合進行所有必要測試。
  4. 檢查結果：確認整合完畢沒有任何問題。
  5. CD：進入持續交付之處如果一切OK就直接到達生產環境。

整合實際案例

假設有一家軟體公司正在開發一款新型網路應用程式。他們使用 GitLab 作為版本控制和 CI/CD 工具。以下是他們如何利用 GitLab 的 CI/CD Pipeline：

  1. 功能開發：開發人員在本地機器上編寫和測試新功能。
  2. 提交程式碼：當功能開發完成後，開發人員將程式碼提交到 GitLab 儲存函式庫。
  3. 觸發 CI：GitLab 自動觸發 CI 流水號進行自動化測試、安全掃描和其他檢查。
  4. 檢查結果：如果所有測試透過，CI 流水號將程式碼標記為可靠。
  5. 觸發 CD：接著進入 CD 階段，根據預設組態將程式碼佈署到不同環境（如測試環境、預生產環境）。
  6. 佈署完成：最終程式碼將被佈署到生產環境中供真實使用者使用。

未來趨勢與技術選型考量

隨著技術的不斷進步，GitLab 的 CI/CD Pipeline 預計會變得更加智慧化和自動化。未來可能會看到更多根據 AI 和機器學習的自動化工具被整合到 Pipeline 中，以提高效率和準確性。

技術選型方面，選擇適合自己專案需求的人工智慧工具非常重要。例如：

  1. AI 快速回應機器人：可以快速回答常見問題。
  2. AI 自動程式碼檢查工具：可以自動檢查程式碼品質和安全性。
  3. AI 自動化測試工具：可以自動生成和執行測試案例。
玄貓

玄貓

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