GitLab 元件深度探討與 CI/CD Pipeline 實踐

– 11 分鐘閱讀

GitLab 作為一個涵蓋軟體開發生命週期（SDLC）所有十個階段的平台，提供了一系列工具和功能，幫助團隊更有效率地開發和交付軟體。從最初的程式碼版本控制，到後續的測試、佈署和監控，GitLab 都能提供相應的支援。尤其在 CI/CD Pipeline 的實踐上，GitLab 提供了強大的自動化能力，讓團隊可以輕鬆地構建、測試和佈署應用程式。透過 YAML 組態檔案，開發者可以定義不同的階段和任務，例如單元測試、整合測試、安全掃描和佈署等。這些任務會在每次程式碼提交時自動執行，確保軟體的品質和安全性。除了 CI/CD 功能外，GitLab 也提供了專案管理工具，例如問題追蹤、里程碑和看板等，方便團隊追蹤進度和協作。

在實際應用中，GitLab 的專案和群組功能可以幫助團隊更好地組織和管理程式碼。透過建立群組和子群組，可以將相關的專案整合在一起，並設定不同的許可權。例如，可以將不同平台的應用程式（例如 Web、iOS 和 Android）分別放在不同的子群組中，方便管理和維護。此外，GitLab 的問題追蹤功能也相當實用，可以讓團隊成員回報錯誤、提出新功能需求，並追蹤處理進度。每個問題都可以設定指派人、截止日期、標籤和權重等，方便團隊成員協作和管理。在 CI/CD Pipeline 的組態中，也可以設定在特定階段執行安全掃描，例如 SAST 和 DAST，以確保程式碼的安全性。透過這些功能，GitLab 可以幫助團隊更有效率地進行軟體開發，並提高軟體的品質和安全性。

GitLab 元件深度探討

GitLab 致力於將軟體開發生命週期（Software Development Life Cycle, SDLC）分割成多個具體階段，以便開發團隊能夠更有效地管理與推進專案。以下是 GitLab 的主要階段：

  • 計劃（Plan）：將工作分解成可管理的部分，並進行優先順序排序、權重分配及團隊成員分配。
  • 建立（Create）：提交、檢討及批准檔案編輯，無論是程式碼、組態資訊或其他資產。
  • 驗證（Verify）：執行自動化測試，確保軟體符合預期功能。
  • 封裝（Package）：將軟體封裝成可佈署的格式。
  • 安全（Secure）：檢查軟體及其依賴項中存在的任何安全漏洞。
  • 發布（Release）：佈署軟體，選擇性使用複雜技術如功能旗標及金絲雀佈署。
  • 組態（Configure）：設定佈署環境。
  • 監控（Monitor）：報告效能指標、事件或錯誤。
  • 保護（Protect）：檢測 Kubernetes 叢集等佈署環境中的潛在安全問題。

需要注意的是，這些階段的劃分並非絕對，不同公司可能會根據自身需求將 SDLC 分割成更多或更少的階段。GitLab 的劃分方式對於熟悉軟體開發的人來說應該相當合理。

回到 GitLab 解決的問題上來，GitLab 的初期目標是解決使用 Git 所面臨的困難。當時它主要專注於「建立」階段，但現在它涵蓋了所有十個 SDLC 階段。由於每個階段都有其獨特的挑戰，要簡潔地描述 GitLab 解決的單一問題幾乎是不可能的。然而，最簡單且最準確的回答是：GitLab 幫助人們更高效且更安全地編寫出更好的軟體。

玄貓必須承認，GitLab 在解決所有十個階段問題上的效果並不相同。例如，GitLab 提供的一些功能可能比其他功能更成熟或穩定。最早期的功能，如與 Git 相關的功能，通常是最成熟的；而最近開發的功能，如在 Kubernetes 叢集中保護應用程式免受可疑流量侵害，則相對較為基礎。然而，GitLab 對其各個階段解決方案的相對成熟度非常透明，並明確指出未來將重點開發和改進哪些功能。

GitLab 平台介紹

有人可能會好奇 GitLab 如何與專注於單一 SDLC 階段的工具競爭。畢竟，一個工具真的能取代十個各自專精於不同領域的工具嗎？首先，你可能會發現自己並不需要你最初認為所需的那麼多功能或那麼強大的工具。例如，玄貓曾經參加了一整天的 Java 效能分析工具培訓課程。課程結束後，他對這些工具所提供的驚人功能和詳細效能瓶頸報告感到頭暈目眩。然而，他的公司只需要這些工具功能的一小部分即可滿足需求。這個故事告訴我們：GitLab 應該可以提供你所需的所有功能，無論你關注哪個 SDLC 階段。

其次，GitLab 的一些功能是由獨立開發的開源工具整合而來的，這些工具在各自領域中被認為是最佳選擇。例如，GitLab 的許多安全漏洞掃描器都是高度評價的開源工具。你可以下載並在 GitLab 外部使用這些工具，但 GitLab 使得在工作流程中啟用它們變得非常簡單，並將其輸出整合到現有的 GitLab 儀錶板中。

最後，如果你真的發現某個 SDLC 階段需要超出 GitLab 提供能力範圍之外解決方案時，幾乎總是可以找到方法將外部工具整合到你的 GitLab 工作流程中。有些整合是由 GitLab 明確支援且結果幾乎無縫連線；其他整合則需要你付出更多努力。但是幾乎任何可以從作業系統命令列執行的工具都可以與 GitLab 連線。

驗證、安全及發布階段

現在我們已經瞭解了 GitLab 慢慢全面助力所有十個 SDLC 階段了, 接下來我們放大焦點至其中三個常見且富挑戰性之部分: 驗證、安全及發布階段。

這三個階段是軟體開發過程中最常使用且最富挑戰性之部分, 正好也是 GitLab 最有效之所在, 而解決這些問題之核心特色則是 CI/CD Pipeline (持續整合/持續交付)。

驗證

驗證階段旨在透過自動化測試來確保軟體符合預期功能。GitLab 提供了一系列自動化測試工具和框架，允許開發者在每次程式碼提交時自動執行測試。這些測試包括單元測試、整合測試和端對端測試等。

stages:
  - test

unit_test:
  stage: test
  script:
    - echo "Running unit tests..."
    - npm test

構建容器圖示

此圖示展示了 Gitlab CI/CD Pipeline 各階段之流程

  graph TD;
    A[Push Code] --> B[Trigger Pipeline];
    B --> C[Run Unit Tests];
    C --> D[Run Integration Tests];
    D --> E[Deploy to Staging];
    E --> F[Run End-to-End Tests];
    F --> G[Deploy to Production];
小段落標題：內容解密：

以上範例展示了一個簡單但完整之 CI/CD Pipeline 組態範例, 各步驟包含：

  1. stages :定義 pipeline 階段
  2. unit_test :定義要執行之任務名稱
  3. stage : 指定任務於何處執行 (本例中為 test)
  4. script : 指定任務要執行之 shell 指令(本例中執行 npm test)

安全

安全階段專注於檢查軟體及其依賴項中的安全漏洞。GitLab 提供了一系列內建的安全掃描工具，例如 SAST（靜態應用程式安全掃描）、DAST（動態應用程式安全掃描）和依賴項掃描等。

stages:
  - security

sast_scan:
  stage: security
  script:
    - echo "Running SAST scan..."
    - gitlab-sast
小段落標題：內容解密：

以上範例展示了一個簡單但完整之 CI/CD Pipeline 組態範例, 各步驟包含：

  1. stages :定義 pipeline 階段
  2. sast_scan :定義要執行之任務名稱
  3. stage : 指定任務於何處執行 (本例中為 security)
  4. script : 指定任務要執行之 shell 指令(本例中執行 gitlab-sast) 透過上述組態, 每次 push code 則會觸發 SAST Scan 以進行靜態應用程式安全掃描

發行

發行階段涉及將軟體佈署到生產環境。GitLab 支援多種佈署策略和技術，例如藍綠佈署、金絲雀佈署和功能旗標等。

stages:
  - deploy

deploy_to_production:
  stage: deploy
  script:
    - echo "Deploying to production..."
    - scp -r /path/to/app user@server:/path/to/production
小段落標題：內容解密：

以上範例展示了一個簡單但完整之 CI/CD Pipeline 組態範例, 各步驟包含：

  1. stages :定義 pipeline 階段
  2. deploy_to_production :定義要執行之任務名稱
  3. stage : 指定任務於何處執行 (本例中為 deploy)
  4. script : 指定任務要執行之 shell 指令(本例中透過 scp 指令將應用程式推播至伺服器) 透過上述組態, 每次 push code 則會觸發 deploy to production

採用 CI/CD Pipeline

CI/CD Pipeline 是現代軟體開發中的核心概念之一, 無論您選擇何種語言或技術架構, CI/CD Pipeline 均可協助您將持續交付融入您組織文化之中, 根據持續交付之理念並不限制於某一特定技術或框架, 您只需要瞭解其中基本概念即可.

使用 GitLab 組織工作

在 GitLab 中，專案和群組是組織工作的基本單位。專案代表單一軟體產品或非軟體專案，是存放檔案和開始使用 GitLab 各種功能的起點。群組則用來收集相關專案，並提供角色和許可權管理。讓我們深入瞭解這些概念。

專案與群組的基本概念

專案（Projects）

專案是 GitLab 的基礎單位，代表你正在開發的單一軟體產品或其他型別的專案。無論是軟體開發還是非技術專案，都可以使用專案來規劃、管理和追蹤進度。

例如：

  • 開發團隊 #1 的找近鄰洗車應用程式
  • 開發團隊 #2 的桌面版洗車應用程式
  • 技術寫作團隊的檔案
  • 活動企劃團隊的即將舉辦的會議
  • 全公司新員工的上班任務

群組（Groups）

當你有多個相關專案時，可以使用 GitLab 的群組來組織它們。群組類別似於資料夾，可以包含多個專案和其他群組，最多可以有 20 層次的子群組。

例如：

  • 同一團隊的所有專案
  • 不同作業系統版本的相同軟體
  • 與資料函式倉管理相關的所有專案

實際應用：Hats for Cats

假設你有一個 Hats for Cats 網路商店的想法，並且需要開發三個不同形式的應用程式：網頁應用程式、iOS 應用程式和 Android 應用程式。你決定將這些應用程式分別設為不同的專案，因為雖然有些邏輯相似，但實作方式有所不同。

首先，你可以建立一個名為「Hats for Cats」的頂層群組，並在其中建立一個名為「Mobile」的子群組來收集 iOS 和 Android 應用程式。然後，你可以在「Hats for Cats」群組中建立一個名為「Web」的專案來開發網頁應用程式。

此外，你還需要建立一個獨立的專案來存放跨平台的線上檔案，因為這些檔案不屬於任何特定專案。

專案結構示意圖

以下是「Hats for Cats」專案的結構示意圖：

  graph TD;
    A[Hats for Cats] --> B[Web];
    A --> C[Mobile];
    C --> D[iOS];
    C --> E[Android];
    A --> F[Documentation];

此圖示展示了 Hats for Cats 專案中的各個部分及其相互關係。頂層群組「Hats for Cats」下有三個專案：「Web」、「Mobile」和「Documentation」。而「Mobile」子群組下則包含「iOS」和「Android」兩個專案。

內容解密：

  1. 專案結構：這是 GitLab 中如何組織專案和子專案的示意圖。頂層專案「Hats for Cats」下有三個主要部分：網頁應用、移動應用以及檔案。
  2. 關係展示：使用 Mermaid 圖表來展示各部分之間的關係，這樣可以更清晰地理解專案的層次結構。
  3. 技術選擇：選擇 Mermaid 圖表作為視覺化工具是因為它簡單直觀且易於理解。
  4. 實際應用：這個示意圖展示瞭如何將理論應用到實際專案中，幫助讀者更好地理解如何在 GitLab 中進行專案管理。

角色與許可權

除了收集相關專案外，群組還可以用來設定角色和許可權。你可以邀請其他 GitLab 使用者加入群組並賦予他們不同的角色和許可權。

例如：

  • 建立一個技術支援團隊並賦予他們檢視和編輯所有相關專案的許可權。
  • 對外部合作夥伴設定只讀許可權，讓他們能夠檢視但不能修改內容。

這樣，群組提供了一種簡單且有效的方式來管理多個使用者對多個專案的存取控制。

內容解密：

  1. 角色設定：在 GitLab 中設定角色和許可權是非常重要的一步，確保不同的人員能夠根據需求存取特定資源。
  2. 許可權控制：透過群組設定許可權，可以靈活地控制誰能夠檢視或編輯哪些資源。
  3. 實務應用：這種方法在實際工作中非常實用，特別是在需要多團隊協作或跨部門合作時。
  4. 安全性：透過設定合適的角色和許可權，可以提高系統的安全性，防止未經授權的人員存取敏感資料。

總結來說，GitLab 的專案和群組功能提供了一種靈活且強大的方式來組織和管理工作。無論是軟體開發還是其他型別的專案，都可以透過這些工具來提高效率和協作能力。

瞭解 GitLab 元件

在 GitLab 中，組織和管理專案是非常重要的。透過建立群組和子群組，你可以將相關的專案整合在一起，並且為這些專案分配許可權。讓我們來看看這樣的結構是如何運作的。

專案與群組結構

首先，我們來看看專案和群組的基本概念。一個專案在 GitLab 中代表一個 Git 儲存函式庫，你可以在這裡儲存你的程式碼。專案也是你在 GitLab 中進行大部分工作的中心地點。多個相關的專案可以被收集到一個群組中。群組可以包含專案、其他群組，甚至兩者皆有。

這種結構有幾個好處：

  1. 組織管理：透過將專案組織在群組和子群組中，你可以保持專案井然有序且容易找到。
  2. 許可權管理：你可以在群組層級分配許可權給團隊成員，這些許可權會自動應用到群組內的所有專案。

以下是一個簡單的例子：假設我們有一個名為「Hats for Cats」的群組，其中包含 iOS 和 Android 版本的專案。這樣的結構不僅讓我們能夠清晰地看到每個版本的進度，還可以方便地管理許可權。

使用問題追蹤工作

如果一個 GitLab 專案代表一個單一產品或倡議，那麼問題（Issue）就是代表一個具體工作單元。如果你之前使用過其他工具來規劃和追蹤工作，可能會遇到「故事」（story）或「票」（ticket）等類別似概念。問題存在於 GitLab 專案中，每個問題只屬於一個專案（雖然可以在專案之間移動）。此外，問題還與 GitLab 的許多其他元件相關聯，這些連結是 GitLab 能夠跨越軟體開發生命週期（SDLC）十個階段的一大特色。

問題的結構

GitLab 問題由幾個部分組成，其中最重要的四個部分如下：

  1. 標題：簡短描述問題的內容。例如，「新增 FAQ 頁面」、「修復錯誤 #12」或「提升頁面載入速度 20%」都是合理的問題標題。
  2. 描述：可以包含任意多或少的文字，支援 Markdown 格式，還可以包含截圖或連結。
  3. 選擇性後設資料欄位：包括指派人、截止日期、標籤和權重等。
  4. 討論區：團隊成員可以在這裡進行討論，就像 Facebook 或 Instagram 的留言區。

問題後設資料

除了標題和描述外，問題還有幾個重要的後設資料欄位：

  1. 指派人（Assignee）：負責推進問題並作為聯絡人的團隊成員。
  2. 截止日期（Due date）：可以直接設定到問題上。
  3. 標籤（Labels）：用於優先順序排序、路由或報告進度等。
  4. 權重（Weight）：描述預計完成該問題所需的工作量。這可以是具體度量（如人小時）或抽象度量（如小任務獲得一點、中等任務獲得兩點）。

此外，問題還有一個非常重要的狀態列位：是否已開啟或已關閉。每個問題都從「已開啟」狀態開始，當工作完成後，狀態會改為「已關閉」。

問題討論區

每個問題都有一個討論區，讓人們可以進行多執行緒討論。討論區支援回覆特定留言或新增全新留言，並且可以包含表情符號、連結或圖片。

以下是來自「Hats for Cats」專案的一個範例問題：

# 新增 FAQ 頁面

## 描述
我們需要新增一個 FAQ 頁面來回答常見問題。

## 標籤
- 優先順序：高
- 分類別：功能新增

## 指派人
@johndoe

## 截止日期
2023-12-01
玄貓

玄貓

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