GitLab 流程實作 DevOps 最佳實踐

GitLab 提供了一個完整平台，能有效整合開發、測試、佈署等環節，實作 DevOps 自動化流程。首先，團隊成員透過 GitLab Issue 追蹤任務，並利用標籤分類別與管理工作進度。開發者在功能分支上進行開發，並提交合併請求，觸發自動化測試和程式碼審查。在確保程式碼品質和安全性後，程式碼會被合併到主要分支，並自動觸發 CI/CD 管道，進行建置、測試和佈署。透過 GitLab 的 CI/CD 功能，團隊可以快速交付軟體，並即時監控佈署狀態。這樣的流程能有效縮短開發週期，提升團隊協作效率，並確保軟體品質。

使用 GitLab 流程實作 DevOps 實踐

玄貓在此將為大家詳細介紹如何使用 GitLab 流程來實作 DevOps 實踐，並透過具體案例來展示每個步驟的操作細節。這些步驟不僅能幫助團隊保持高效的工作流程，還能確保程式碼品質和安全性。

建立和管理問題

1. 建立問題：

   • Elizabeth 首先在 GitLab 中建立了一個名為「Filter hats by breed」的問題。這個問題描述了需要完成的工作內容，並且包含了相關的討論和後設資料。

2. 標籤問題：

   • Elizabeth 為這個問題增加了兩個標籤：一個範圍內的 Status::In Progress 標籤，和一個未範圍的 Back-end 標籤。這些標籤幫助團隊跟蹤問題的進度和負責人。

分支管理與程式碼提交

3. 建立臨時分支：

   • Elizabeth 建立了一個臨時分支 filter-hats-by-breed 來存放她的提交。

4. 建立合併請求：

   • Elizabeth 建立了一個名為「Draft: Filter hats by breed」的合併請求，並將其分配給團隊成員 Alice 和 Bob 進行程式碼審查。

5. 開始編碼：

   • 在完成了問題、分支和合併請求的設定後，Elizabeth 開始編寫程式碼。

6. 提交程式碼：

   • 每當 Elizabeth 編寫完一小段測試可行的程式碼時，她就會將其提交到臨時分支中。

自動化測試與程式碼審查

7. 檢視自動化測試結果：

   • Elizabeth 在合併請求中檢視自動化測試、程式碼品質掃描、許可證掃描和安全掃描的結果。如果沒有報告任何問題，她會慶祝一下，並享用一杯增加了更多糖的阿薩姆紅茶。

8. 團隊成員審查：

   • Alice 和 Bob 收到通知後，會檢視合併請求並對 Elizabeth 的變更進行審查。他們會在討論區域中提出一些建議和改進意見。

9. 協商與修改：

   • Elizabeth 與 Alice 和 Bob 討論她不認同的一些建議，直到達成共識。然後，她會根據協商結果進行修改並提交新的程式碼。

安全掃描與最終審核

10. 處理安全漏洞：

    • 在某次提交後，安全掃描報告了一個漏洞。Elizabeth 快速修復了這個漏洞，並再次執行自動化測試和掃描。

11. 最終審核：

    • Alice 和 Bob 對所有已提交的程式碼進行了最終審核並給予了正面反饋。Elizabeth 移除了 Back-end 標籤，增加了 Front-end 標籤，並將問題重新分配給前端工程師 George。

前端開發與協作

12. 前端開發：

    • George 在同一個臨時分支上編寫前端程式碼並進行提交。每次提交都會觸發自動化測試和掃描。

13. 進度管理：

    • George 感到工作進度落後於計劃，於是為原始問題增加了一個 At Risk 標籤。開發經理回應此標籤並分配了另一位前端開發者 Helen 來幫助 George。

14. 完成功能：

    • George 和 Helen 持續進行提交、審查和自動化測試的迴圈，直到完成該功能。他們移除了 At Risk 標籤並得到 Alice 和 Bob 的正面反饋。

安全與 QA 審核

15. 安全與 QA 團隊審核：
    • George 提及安全和 QA 團隊以取得他們的審核批準。當他們批准後，George 則移除了 Front-end 和 Status::In Progress 標籤並點選合併按鈕完成合併請求。

GitLab 元件理解

GitLab 是一個網頁應用程式，旨在解決軟體開發生命週期（SDLC）中的多種問題。以下是一些關鍵元件：

• GitLab 專案：代表一個軟體產品或組織中的一部分。
• GitLab 小組：可以收集具有相似主題的專案。
• GitLab 問題：記錄每個任務或工作塊。
• GitLab 標籤：用於強調問題狀態或健康狀況。
• GitLab 合併請求：用於將一個分支合併到另一個分支中。
• GitLab 流程（GitLab flow）：是使用 GitLab 元件的最佳實踐工作流程。

此圖示

  graph TD;
    A[建立問題] --> B[標籤問題];
    B --> C[建立臨時分支];
    C --> D[建立合併請求];
    D --> E[開始編碼];
    E --> F[提交程式碼];
    F --> G[檢視自動化測試結果];
    G --> H[團隊成員審查];
    H --> I[協商與修改];
    I --> J[處理安全漏洞];
    J --> K[最終審核];
    K --> L[前端開發];
    L --> M[進度管理];
    M --> N[完成功能];
    N --> O[安全與 QA 審核]

內容解密：

• 上述流程圖展示了從建立問題到最終完成功能的一系列步驟。每一步都涉及多方參與和自動化工具來確保程式碼品質和安全性。
• GitLab 流程強調協作和持續整合/持續佈署（CI/CD），使得開發過程更加高效且可靠。
• 每個步驟都有明確的角色和責任，確保每個人都瞭解自己的工作範圍和目標。
• 自動化測試和掃描工具在每次提交後執行，幫助及早發現和修復潛在問題。
• 安全掃描是關鍵步驟之一，確保程式碼不會引入新的漏洞。
• 最後，安全和 QA 團隊的審核是確保程式碼符合所有標準和要求的重要環節。

CI/CD 概念

在下一章中，我們將探討 CI/CD 概念及其在 GitLab 中的應用。這是 GitLab 最強大且最有幫助的功能之一。透過瞭解 CI/CD 概念，我們可以更好地利用 GitLab 的功能來實作高效且可靠的軟體開發流程。

GitLab CI/CD 管道結構與原理

無論是否熟悉 Git 或 GitLab 的基本概念，玄貓相信你已經對於開發者如何在軟體開發生命週期（SDLC）的 Create 階段中使用這些工具來建立、審查和儲存程式碼有了初步的瞭解。你也已經接觸到一些在 Verify、Package 和 Release 階段中遇到的問題。現在，是時候探討 GitLab 的 CI/CD 管道如何解決這些問題。

在本章中，你將學習持續整合（CI）和持續交付（CD）的含義，以及它們如何融入 GitLab Flow。你將學習如何描述管道的不同部分，包括階段和作業。你會看到這些部分如何組合在一起，以及程式碼如何透過它們流動。你將學習如何檢視管道的整體狀態，以及構成它們的個別階段和作業的狀態。你將瞭解 GitLab 可以觸發管道的不同方式，以及為什麼你可能希望限制管道執行的頻率。最後，你將學習如何組態一個簡單的 Hello World 風格管道給 Hats for Cats 軟體。

一旦你熟悉這些概念和做法，就會開啟通向透過管道啟用和組態強大 GitLab 功能的大門。當你達到那個階段時，很有可能你會成為一個堅定且忠實的 GitLab 使用者，無法想像回到其他 DevOps 工具。

在本章中，我們將涵蓋以下主要主題：

• 定義「管道」、「CI」和「CD」
• 管道的部分——階段、作業和命令
• 執行 GitLab CI/CD 管道
• 讀取 GitLab CI/CD 管道狀態
• 組態 GitLab CI/CD 管道

技術要求

與之前的章節一樣，如果你擁有一個 GitLab 執行例項（自行管理或軟體即服務（SaaS））上的帳戶，並可以登入並使用它來練習和實驗本章討論的概念，將能夠更好地理解本章內容。

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

由於 GitLab 的許多功能來自於組態 CI/CD 管道來處理你的程式碼，因此理解什麼是管道至關重要。所以，討論這個主題的一個顯而易見的起點是搞清楚我們究竟對「管道」、「CI」和「CD」這些詞語的具體含義。我們不會立即開始建立管道——那將在後面的章節中進行。

理解什麼是管道

GitLab CI/CD 管道是一系列步驟，當你對 GitLab 主機上的倉函式庫進行提交編輯時會自動執行。這句話有很多內容，讓我們仔細看看每一部分。

「一系列步驟」指的是什麼？

可以將這些步驟視為對檔案執行的任務。例如，你可能希望在檔案上執行各種測試或掃描程式，以確保程式碼編寫良好、沒有安全漏洞、使用了適當許可證的依賴項並滿足所有功能或效能要求。你也可能希望將程式碼封裝成可佈署格式，無論是 Ruby Gem、可安裝的 Red Hat 包、Docker 畫素還是任何其他包格式。當然，你也可能需要一個步驟來佈署程式碼到適當環境中——無論是測試環境、預生產環境還是專案實際生產環境。

「你的檔案」指的是什麼？

技術上講，GitLab CI/CD 管道可以在任何包含在 GitLab 專案倉函式庫中的檔案上執行我們剛剛描述過的步驟：原始碼檔案、組態檔案、README 檔案和測試資料檔案。簡而言之，可以組態管道來檢查、測試、封裝、佈署或以其他方式操作專案中的任何檔案。最常見的是被管道步驟針對操作的是原始碼檔案，但重要的是記住可以組態管理來執行幾乎任何任務在幾乎任何位於 GitLab 專案倉函式庫中的檔案。

為什麼指定「每次提交編輯時執行」？

因為在絕大多數情況下，「新增一個 Git 提交」正是觸發管理執行對檔案進行操作的原因。GitLab 帶來的一些 SDLC 優勢只有在管理頻繁執行且對於小集合檔案變更時才能發揮作用。為了實作這一點，GitLab 的預設行為是在每次向專案主機版本資料函式庫提交編輯檔案時執行完整管理。

提交並不是觸發管理執行唯一方法——儘管它是最常見方法。稍後在本章中你將學到手動啟動管理執行以及如何防止提交後執行管理。

為什麼要指定僅針對 GitLab 主機版本函式庫執行？

因為管理是一個 GitLab 概念而不是 Git 概念。這意味著管理只能存取由 GitLab 掌握版本控制系統知道的檔案——也就是說位於傳送到 Gitlab 執行例項上儲存專案版本資料函式庫中的檔案。

以此類別推：如果編輯位於專案版本資料函式庫中的地方檔案副本時則 Gitlab 無法看到檔案版本（至少直到用 git push 命令同步至 Gitlab）。再次說明：只有位於專案主機版本資料函式庫中的檔案才能被管理所針對操作。

每個專案僅定義一個管理

每個專案僅定義了一個 GitLab CI/CD 管理。然而，該管理所做之事——它所包含之任務——可能取決於各種因素導致該管理一次執行與另一次執行顯得不同。例如針對編輯原始碼執行之管理可能包含許多自動化測試和封裝程式碼成 Docker 畫素；而針對編輯檔案執行之管理則可能涉及拼寫檢查和佈署至 Web 伺服器。但是它仍然是兩種情況下之同一個管理。

它只是單一管理中的某些功能可以依據哪些型別程式碼變更切換開啟或關閉而已而已。很容易看到同一專案來自兩次不同輸出之兩次執行而認為它們是完全不同之兩次管理；但其實並非如此真相是每個專案僅有一個 CI/CD 管理而已：該管理做之事可能每次執行都不同。

認識「管道」術語之不同用途

「管道」術語有時被使用輕鬆模糊地使用。最精確地思考它的一種方式就是說：專案之管道只是應用於專案的檔案上之步驟系列藍圖或食譜而已。 執行該步驟並非技術性之「管道」，而是稱為「管線執行」或「管線例項」。但是人們常常把單次執行稱作是「管線」。我們在本章中也會採取相似做法：當「管線執行」或「管線例項」技術上會比較正確時我們往往會使用簡短名詞「管線」。 由於我們是在談論藍圖還是單次執行應該會由上下文中明顯出來。

同一時間裡專案可以同時執行多於一次執行次數之多次「管線例項」。如果同時間隔幾秒內進行兩次提交且如果每個工程步驟花費幾分鐘完成則就有可能同時間存在兩次執行不同提交之多次「運算例項」。每次執行都會根據不同檔案版本進行相同步驟。

檢視列出清單

在使用Gitlab建立軟體時最常見做之一就是檢視正在執行與完成之多次執行清單。繼續前面各章節建立之模式我們將更專注於瞭解要去做此事原因而不是詳細說明如何操作（因為圖形化介面GUI可能改變且官方Gitlab說明手冊總有最新指示）。

  graph TD;
    C[C]
    H[H]
    I[I]
    J[J]
    A[Git Commit] --> B[Trigger Pipeline];
    B --> C{Pipeline Configuration};
    C --> D[Stages and Jobs];
    D --> E[Run Tests];
    D --> F[Build Code];
    D --> G[Deploy Code];
    E --> H{Test Results};
    F --> I{Build Artifacts};
    G --> J{Deployment Status};

此圖示展示了從提交到佈署的一系列步驟流程圖。

1. Git Commit：開發者推播程式碼到倉函式庫。
2. Trigger Pipeline：觸發CI/CDPipeline。
3. Pipeline Configuration：根據組態檔案決定Pipeline的各個階段和任務。
4. Stages and Jobs：Pipeline分為測試（Run Tests）、構建（Build Code）和佈署（Deploy Code）等階段。
5. Run Tests：執行各種測試來確保程式碼品質。
6. Build Code：將程式碼編譯成可佈署格式。
7. Deploy Code：將構建好的程式碼佈署到相應環境。
8. Test Results：測試結果顯示成功與否。
9. Build Artifacts：構建過程產生的一些輸出物。
10. Deployment Status：佈署狀態顯示成功與否。

內容解密：

• Git Commit：開發者向版本控制系統推播更改後觸發了Pipeline。
• Trigger Pipeline：提交後觸發CI/CDPipeline。
• Pipeline Configuration：根據.gitlab-ci.yml檔案組態Pipeline。
• Stages and Jobs：Pipeline分為多個階段和作業分別負責不同工作如測試、編譯及佈署等工作。
• Run Tests：執行編寫好的測試指令碼以確保編譯後不會出現錯誤或者缺陷。
• Build Code：將原始碼編譯成二進位制或者其他格式以便進一步佈署。
• Deploy Code：將編譯好的程式釋出到伺服器上供使用者使用。
• Test Results：測試結果顯示該階段所有測試項透過否？
• Build Artifacts：構建過程中產生的一些中間產物或者輸出物例如jar包、war包等。
• Deployment Status：表示該程式釋出成功還是失敗？
• 本圖示清晰地展示了從推播程式碼到佈署過程中的各個步驟及其關係

  graph TD;
    C[C]
    A[Project] --> B[Pipeline];
    B --> C{Stages};
    C --> D[Test Stage];
    C --> E[Build Stage];
    C --> F[Deploy Stage];
    D --> G[Unit Tests];
    D --> H[Integration Tests];
    E --> I[Compile Code];
    E --> J[Package Code];
    F --> K[Deploy to Staging];
    F --> L[Deploy to Production];

此圖示展示了專案下面各個階段及其具體工作內容如單元測試、整合測試以及編譯與封裝等工作

內容解密：

• Project：代表一個特定專案。
• Pipeline：CI/CD Pipeline用於自動化構建、測試和佈署過程。
• Stages：Pipeline分為多個階段包括測試階段、構建階段以及佈署階段等多個階段
• Test Stage：測試階段包括單元測試以及整合測試兩項主要內容
• Unit Tests：對單個函式或者方法進行單元測試以確保正確執行。
• Integration Tests：對系統內不同模組之間相互呼叫關係進行整合測試以確保正確呼叫關係沒有問題
• Build Stage：構建階段包括編譯與封裝兩項主要工作內容
• Compile Code：將原始碼轉換為機器語言從而轉變為可執行程式或者二進位制檔案
• Package Code：將編譯完成後程式封裝為jar包或者war包從而便於進一步釋出與分發
• Deploy Stage：佈署階段包括先將程式釋出到測試環境再根據結果決定是否將其釋出到生產環境裡面供使用者使用
• 本圖示清晰地展示了專案下面各個階段及其具體工作內容如單元測試、整合測試以及編譯與封裝等工作