現代軟體開發講求速度與品質，自動化佈署扮演著關鍵角色。本文將探討 GitLab CI/CD 的核心概念，並解析如何在 GitLab 中實踐 CI/CD，建立自動化佈署管道。持續整合（CI）強調頻繁整合程式碼並執行自動化測試，確保程式碼品質。持續佈署（CD）則是在程式碼測試完成後，自動佈署到目標環境。GitLab CI/CD 管道串聯這些步驟，從程式碼提交到佈署完成，形成一個自動化的流程。在 GitLab 中，可以根據不同的 Git 分支或標籤決定佈署位置。例如，開發分支佈署到審查環境，主分支佈署到測試環境，而帶有版本號的標籤則佈署到生產環境。GitLab 的審查環境會隨著分支的合併而自動銷毀，簡化了環境管理。持續交付和持續佈署的區別在於，持續交付需要人工批准才能佈署到生產環境，而持續佈署則是完全自動化的。在佈署前，程式碼可能需要封裝，例如 Java 封裝成 WAR 或 EAR 檔案，Ruby 封裝成 Gem 檔案，或封裝成 Docker 映像檔。CD 管道會將封裝好的軟體推播到目標環境，例如 Docker 倉函式庫或 AWS 環境。
自動化佈署的管道與策略
在現代軟體開發中，自動化佈署（Continuous Deployment, CD）已成為不可或缺的技術。它不僅提升了開發效率，還確保了軟體的穩定性和可靠性。玄貓將探討CD的核心概念，並介紹如何在GitLab中實作這些概念。
管道、持續整合與持續佈署的定義
在開始之前，我們需要明確一些關鍵術語。持續整合（Continuous Integration, CI）是指將程式碼頻繁地整合到主分支中，並自動執行測試以確保程式碼品質。持續佈署（CD）則是將經過測試的程式碼自動佈署到生產環境或其他環境中。而管道（Pipeline）是指一系列自動化步驟，從程式碼提交到佈署完成。
在GitLab中，CD管道通常根據不同的Git分支或標籤來決定佈署位置。以下是一個典型的組態範例：
- 若管道執行於
add-login-feature、fix-password-bug或remediate-cross-site-scripting-vuln等分支，則將程式碼佈署到審查環境進行測試。 - 若管道執行於主分支，則將程式碼佈署到測試環境。
- 若管道執行於生產標籤（如
version-1-0或version-12-2），則將程式碼佈署到生產環境。
瞭解審查環境
審查環境是軟體開發中不可或缺的一部分。它允許開發團隊在安全的沙盒環境中測試他們的軟體，以確保其滿足功能需求。GitLab提供了一種特殊的審查環境，稱為「審查環境」。每個非預設的Git分支都會有一個專門的審查環境，當這個分支被合併到預設分支時，審查環境會被自動銷毀。
審查環境是GitLab的一大特色。使用者無需手動設定這些環境，只要在GitLab中建立一個分支，審查環境就會自動出現，準備好接受CI/CD管道的佈署。這大大簡化了開發流程，提高了效率。
持續交付與持續佈署
持續交付（Continuous Delivery）與持續佈署（Continuous Deployment）之間有一個關鍵區別：前者需要人工批准才能佈署到生產環境，而後者完全自動化。持續交付確保了程式碼可以隨時佈署到生產環境，但需要手動批准以避免錯誤。持續佈署則完全自動化，程式碼一經測試透過便會直接佈署到生產環境。
使用CD包裝與佈署程式碼
CD管道在佈署之前可能需要對程式碼進行包裝。例如，Java程式碼可以封裝成WAR或EAR檔案，Ruby程式碼可以封裝成Gem檔案，C程式碼可以封裝成Docker映像檔案等。這些包裝形式取決於專案的語言和佈署策略。
無論是否需要包裝，CD管道都會將軟體推播到目標環境中。這可以透過推播Docker映像到倉函式庫、使用命令列工具佈署到AWS環境等方式實作。
此圖示表示CD管道的基本流程
graph TD
E[E]
A[提交程式碼] --> B{CI測試}
B -->|透過| C[準備佈署]
B -->|失敗| D[通知開發者]
C --> E{是否為生產環境}
E -->|否| F[佈署到審查/測試環境]
E -->|是| G{是否為持續交付}
G -->|是| H[等待人工批准]
G -->|否| I[直接佈署到生產]
內容解密：
此圖示展示了CD管道的基本流程：
- 提交程式碼：開發者將程式碼提交到版本控制系統中。
- CI測試：系統自動執行CI測試以檢查程式碼品質。
- 透過：若測試透過，進入準備佈署階段。
- 失敗：若測試失敗，通知開發者進行修復。
- 準備佈署：準備將經過測試的程式碼進行佈署。
- 目標環境判斷：判斷目標環境是否為生產環境。
- 否：若不是生產環境，將程式碼佈署到審查或測試環境。
- 是：若為生產環境，進入下一步判斷。
- 持續交付判斷：判斷是否為持續交付模式。
- 是：若為持續交付模式，等待人工批准後再進行佈署。
- 否：若為持續佈署模式，直接將程式碼佈署到生產環境。
CD 的優點
CD 的主要目的是「讓發布變得平淡無奇」。透過每次提交都進行自動化佈署，無論是審查、測試還是生產環境，都能讓團隊更頻繁地釋放小幅度更新。這不僅降低了風險，還讓客戶能夠更早地獲得新功能和修復。
透過在非生產環境中進行多次測試和驗證，團隊可以更有信心地將新功能推播到生產環境。這種方法減少了每次發布帶來的風險和回復可能性。
總結來說，「玄貓」探討了CD 的核心概念及其實作方式，「玄貓」透過具體案例和技術深度介紹瞭如何在GitLab 中構建高效且穩定的CI/CD 管道，「玄貓」也強調了CD 在現代軟體開發中的重要性及其帶來的優勢。「玄貓」期待這些內容能夠幫助讀者更好地理解和應用CD 技術，「玄貓」也歡迎大家提出更多有關此主題的問題與討論。「玄貓」認為技術無止境，「玄貓」也樂於與大家一起探索更多新穎技術和解決方案。「玄貓」希望大家在未來的工作中能夠運用所學知識，「玄貓」也期待看到更多創新與突破！
GitLab CI/CD 管道架構與基礎概念
在探討 GitLab CI/CD 管道的架構之前，玄貓會先介紹一些核心概念：管道（pipeline）、持續整合（Continuous Integration，CI）以及持續交付（Continuous Delivery，CD）。這些概念是理解 GitLab CI/CD 管道的基礎。
管道、CI 與 CD 的定義
- 管道（Pipeline）：這是一系列自動化的任務，用來構建、測試和佈署應用程式。每當有新的程式碼提交到 Git 儲存函式庫時，這些任務會自動執行。
- 持續整合（CI）：這是一種開發實踐，旨在經常性地將開發者的程式碼合併到主分支中。透過自動化測試來確保新程式碼不會破壞現有功能。
- 持續交付（CD）：這是持續整合的延伸，確保應用程式隨時可以被安全地佈署到生產環境中。CD 的目標是讓每個提交都能夠成為可佈署的產品。
GitLab Runner 的介紹
GitLab Runner 是實作 CI/CD 管道自動化的關鍵元件。它們是小型程式，負責執行 GitLab 例項發出的命令。這些命令包括構建、測試和佈署等任務。具體來說，GitLab Runner 是將 CI/CD 組態轉換為實際執行任務的工具。
玄貓會簡要介紹 GitLab Runner 在 CI/CD 管道中的角色，並解釋如何安裝和組態它們。以下是 GitLab CI/CD 管道架構的簡要圖示：
graph TD;
A[GitLab 例項] --> B[CI/CD 組態檔案];
B --> C[GitLab Runner];
C --> D[構建任務];
C --> E[測試任務];
C --> F[佈署任務];
D --> G[測試結果];
E --> G;
F --> G;
A --> G;
此圖示展示了 GitLab CI/CD 管道的三個主要元件：CI/CD 組態檔案、GitLab Runner 和 GitLab 例項。GitLab 例項管理和協調所有管道任務，最終顯示這些任務的結果。
模組化與自動化
一旦理解了這些高層次的概念，就可以探討管道的具體組成部分：階段（stages）、工作（jobs）和命令。
階段（Stages）
每個管道由一個或多個階段組成。階段是一組主題相關的任務。例如：
- 構建（Build）：包含編譯和封裝原始碼的任務。
- 測試（Test）：包含執行自動化測試、程式碼品質掃描和安全掃描的任務。
- 佈署（Deploy）：將程式碼佈署到適當的環境。
GitLab 預設提供這三個階段，但你可以根據需求進行修改。明確定義階段有助於提高可讀性和排錯效率。
操作（Jobs）
每個階段由多個工作組成。工作是由 GitLab Runner 執行的一系列命令。你可以根據需要定義多個工作，並且每個工作都可以組態不同的環境和依賴項。
命令
命令是工作中的基本單位。它們是實際執行的操作，例如編譯、測試和佈署等。命令通常是 shell 命令或其他可執行檔案。
非程式碼主題特殊處理
玄貓強調，非程式碼主題必須提供具體實務案例及明確資料支援。以下是一些具體案例：
- 持續整合案例：一家金融科技公司透過引入 CI 管理流程，降低了程式碼合併時出現錯誤的風險，並且提高了開發速度。
- 持續交付案例：一家電子商務平台透過 CD 流程，實作了每日多次佈署，大幅提升了應用程式更新的頻率和穩定性。
###視覺化圖表使用規範
玄貓積極使用Mermaid圖表來呈現流程、架構、關係及概念。以下為Gitlab CI/CD架構概念圖：
graph TD;
C[C]
A[Git Repository] --> B[CI/CD Pipeline Trigger];
B --> C{CI/CD Configuration File};
C --> D[Stage: Build];
C --> E[Stage: Test];
C --> F[Stage: Deploy];
D --> G[Build Artifacts];
E --> H[Test Results];
F --> I[Deployed Application];
此圖示展示了從 Git 儲存函式庫觸發 CI/CD 管道後，透過不同階段進行構建、測試和佈署的流程。
標題格式規範
GitLab CI/CD 管道架構與基礎概念
模組化與自動化
階段（Stages）
GitLab Runner 的介紹
模組化與自動化
操作（Jobs）
命令
GitLab CI/CD 管道結構深度探索
在現代軟體開發中，持續整合（CI）與持續佈署（CD）是不可或缺的流程。GitLab 提供了一套強大且靈活的 CI/CD 管道，讓開發者能夠自動化建置、測試及佈署流程。瞭解這些管道的結構對於有效地使用 GitLab CI/CD 是至關重要的。
GitLab CI/CD 管道的基本組成
GitLab CI/CD 管道由三個主要組成部分構成：階段（Stages）、任務（Jobs）及指令（Commands）。這些組成部分協同工作，確保每個開發流程都能順利進行。
段落標題：階段（Stages）
階段是 GitLab CI/CD 管道的最高層次，代表一系列相關任務的集合。例如，常見的階段包括建置（Build）、測試（Test）及佈署（Deploy）。這些階段是依序執行的，每個階段完成後才會進行下一個階段。
次段落標題：此圖示
graph TD;
A[建置] --> B[測試];
B --> C[佈署];
次段落標題：內容解密：
此圖示展示了典型的 GitLab CI/CD 管道階段。建置階段負責編譯程式碼或建置映像檔；測試階段則執行自動化測試來驗證程式碼；最後，佈署階段將經過驗證的程式碼佈署到生產環境或其他目標環境。
段落標題：任務（Jobs）
任務是 GitLab CI/CD 管道中的基本執行單元，每個任務都有一個描述其功能的名稱。任務是階段內的具體操作，例如編譯程式碼、執行測試或佈署應用程式。每個階段可以包含多個任務，而每個任務都必須屬於某個階段。
次段落標題：此圖示
graph TD;
A[建置] --> B[編譯Java程式碼];
A --> C[建置Docker映像];
D[測試] --> E[執行單元測試];
D --> F[執行效能測試];
G[佈署] --> H[將應用程式佈署到生產環境];
次段落標題：內容解密：
此圖示說明瞭每個階段內可能包含的多個任務。例如，建置階段可能包括編譯 Java 原始碼及建置 Docker 映像等任務；測試階段則包含執行單元測試及效能測試；最後，佈署階段將應用程式推播到目標環境。
段落標題：指令（Commands）
指令是任務內部執行的具體操作命令。這些命令可以類別比為人類在終端機中輸入的命令，例如編譯 Java 原始碼、建置 Docker 映像或執行 Maven 測試等。每個任務可以包含多個命令來完成其功能。
次段落標題：此圖示
graph TD;
build[build]
tag[tag]
A[任務A] --> B[javac *.java];
A --> C[mvn test];
D[任務B] --> E[docker build --tag my_app:1.2];
次段落標題：內容解密：
此圖示展示了兩個不同任務內可能包含的命令。任務 A 包含編譯 Java 原始碼及執行 Maven 測試；而任務 B 則負責建置 Docker 映像。
技術選型考量與實際錯誤教訓
在設計 GitLab CI/CD 管道時，選擇合適的工具和命令是至關重要的。例如，如果你選擇使用 Maven 作為建置工具，則需要確保所有相關依賴項都已安裝並正確組態。此外，確保每個任務都只執行一個具體的操作，這樣可以提高管道的可維護性和可靠性。
實際錯誤教訓顯示，當任務命名不清晰或包含多個操作時，會導致管理和除錯困難。因此，命名必須簡潔明瞭且反映其真實功能。
標準化與未來趨勢
在現代軟體開發中，標準化和自動化是不可或缺的。GitLab CI/CD 提供了強大的工具來實作這些目標。未來趨勢顯示，越來越多的開發者會採用這些技術來提高生產力和降低錯誤率。
GitLab CI/CD 管線探討
GitLab CI/CD 是一個強大的工具，能夠自動化軟體開發和佈署流程。瞭解如何執行和管理這些管線對於提升開發效率和保證程式碼品質至關重要。以下是關於 GitLab CI/CD 管線的詳細探討，包括執行管線的方法、不同型別的管線及其應用場景。
GitLab CI/CD 管線的基本概念
GitLab CI/CD 管線能夠對不同的分支進行測試和佈署，確保每個分支的程式碼都能夠順利執行。例如，在圖 4.5 中展示了不同分支的管線執行結果。最新的管線執行在 add-login-feature 分支上，而第二新的管線則執行在 fix-password-bug 分支上。這兩個分支可能包含不同的內容，甚至是新的檔案，因此測試階段在不同分支上的結果可能會有所不同。
graph TD
A[add-login-feature] --> B[Pipeline]
C[fix-password-bug] --> D[Pipeline]
B --> E[Test Failed]
D --> F[Test Passed]
內容解密：
此圖示展示了 GitLab CI/CD 管線如何對不同分支進行測試。add-login-feature 分支和 fix-password-bug 分支各自觸發了不同的管線，並且在測試階段中可能會出現不同的結果。這種多分支測試機制能夠幫助開發者更早地發現和修復問題。
手動執行管線
除了自動觸發的管線外，GitLab 還允許開發者手動執行管線。這對於需要針對特定分支進行測試或佈署的情況非常有用。以下是手動執行管線的步驟：
- 前往管線列表頁面。
- 點選「Run pipeline」按鈕。
- 選擇要執行管線的分支。
- 點選「Run pipeline」按鈕。
graph TD
A[Visit Pipelines List] --> B[Click Run Pipeline]
B --> C[Select Branch]
C --> D[Click Run Pipeline]
內容解密：
此圖示展示了手動執行 GitLab CI/CD 管線的流程。透過選擇特定分支來執行管線，開發者可以根據需要進行測試和佈署，確保程式碼品質。
Git 標籤管線
除了分支之外，GitLab 還支援對 Git 標籤進行測試。這對於針對特定版本進行測試或佈署非常有用。例如，可以為版本 3.1 的程式碼打上標籤 version-3-1，然後手動觸發相應的管線進行測試。
graph TD
A[Create Tag] --> B[Version-3-1]
B --> C[Manually Trigger Pipeline]
C --> D[Select Tag]
D --> E[Run Pipeline]
內容解密：
此圖示展示瞭如何對 Git 標籤進行測試。透過建立標籤並手動觸發相應的管線，開發者可以確保特定版本的程式碼能夠順利執行。
其他型別的管線
除了標準的分支和標籤管線之外，GitLab 還支援其他型別的管線：
- Merge Request Pipelines：這些管線在合併請求時執行，確保源分支中的程式碼能夠順利合併到目標分支。
- Merged Result Pipelines：這些是特別型別的合併請求管線，在源分支中的提交時執行，模擬合併後的結果。
- Merge Trains：這些是特別型別的合併結果管線，可以同時處理多個合併請求，確保它們能夠順利合併到目標分支。
這些高階功能雖然不如標準分支和標籤管線常用，但對於複雜的開發場景非常有用。
跳過管線
雖然 GitLab CI/CD 管線非常強大，但在某些情況下可能不需要執行管線。例如：
- SaaS 版本的 GitLab 有每月計算時間限制。
- 對於微小改動（如新增註解或修正小錯誤）不需要立即佈署。
- 在提交多個低風險變更時可以等待所有提交完成後再執行一次管_line。
要跳過某次提交所觸發的管_line，可以在提交訊息中新增 [skip ci] 或 [ci skip]。
