在 GitLab 開發流程中，早期建立合併請求能有效提升程式碼品質和團隊協作效率。合併請求如同程式碼儀錶板，整合顯示自動測試結果、效能指標、安全性漏洞等資訊，並提供差異檢視，方便開發者掌握程式碼變更對軟體的影響。同時，合併請求提供討論平台，促進團隊成員早期參與程式碼審查，及時發現並解決潛在問題，降低修復成本。小段程式碼的頻繁審查比一次審查大量程式碼更有效率，也有利於及早發現並修正風格問題、效能瓶頸或程式碼錯誤。此外，早期整合安全掃描結果，有助於在開發過程中及時發現並修復安全漏洞，符合左移原則，降低安全風險。
早期建立合併請求（MR）的好處
在 GitLab 的工作流程中，早期建立合併請求（Merge Request, MR）是一個被廣泛接受的最佳實踐。這種做法不僅有助於提升程式碼品質，還能促進團隊成員之間的協作。以下是兩個主要原因，說明為什麼早期建立 MR 是如此重要：
MR 作為程式碼的儀錶板
首先，MR 可以作為一個「儀錶板」，讓你瞭解所新增的程式碼在整體上的品質。這個儀錶板能回答以下問題：
- 自動測試是否透過？
- 程式碼是否符合效能需求？
- 程式碼是否引入了安全漏洞？
- 新增的第三方依賴是否使用與專案總體許可證相容的許可證？
- 程式碼是否符合風格和品質要求？
- 如果將應用分發為 Docker 映像，基礎 Docker 映像中是否有已知的安全漏洞？
這些結果在 GitLab 的其他部分也可以檢視，但將它們整合在 MR 中更方便。更重要的是，MR 中的結果提供了一個「差異」檢視，讓你能看到 MR 的分支與預設分支之間的測試和掃描結果差異。這樣可以幫助你瞭解所貢獻的程式碼是否朝著正確的方向發展，即你的提交是使軟體變得更好還是更差。
MR 改善協作
第二個理由是 MR 能促進團隊成員之間的協作。透過提供執行緒討論區域，MR 讓同事可以檢視和評論每一次提交。這樣可以更早地發現潛在問題，並在還容易修復時解決它們。例如：
- 你可能會引入一些微妙的錯誤，同事可以及時發現並告知你。
- 你可能開始編寫一個演算法，但它不如替代方案那麼快，有人可以在你投入大量時間之前告訴你。
- 你可能使用某些語言慣用語不當，如果高階開發者早期指出來，你可以在提交更多程式碼之前調整風格。
這些情境都有一個共同主題：透過早期和頻繁的協作，透過檢視單次提交中的小段程式碼，問題變得更容易發現並更便宜修復。MR 正是這種協作發生的地方。
單次提交與 MR 的優勢
減少錯誤與修復成本
任何人都可能會被要求審查一個包含三千行程式碼的完成功能而感到無從下手。或者當開發者誤解了規格並未建立產品擁有者所需功能時感到絕望。或者在指出開發者反覆犯下編寫或風格錯誤時感到尷尬。所有這些情況都可以透過頻繁檢視小段程式碼來避免，而這只能在第一次提交之前就準備好 MR。
提升開發者體驗
頻繁的協作不僅有助於審查人員，還有助於程式碼作者。就像自動化測試失敗更容易排查和修復時所包含的小段程式碼一樣，風格問題、效能演算法或錯誤也更容易在十二行程式碼中發現而不是三千行程式碼中。調整編寫實踐在開發過程早期比等到認為完成編寫後再進行複雜或甚至破壞性修復要好得多。
安全性考量
這些原則也適用於安全漏洞。軟體的一大真理是必須在整個開發流程中考慮安全性；你不能在結束時再加上它。合併請求中的頻繁安全掃描結果有助於從開發流程開始「烘焙」安全性。經驗豐富的開發人員或安全團隊成員對程式碼進行審查也有助於達成這一目標，而 MR 論壇正好是進行這種程式碼審查的地方。
左移（Shift Left）原則
「左移」原則特別適用於安全性。因為安全問題有時需要重新思考和重新設計軟體基本架構決策。當程式碼函式庫較小時進行這樣的修復會更簡單、更便宜且不會那麼破壞性。
三大核心：議題、分支及合併請求
現在你知道了議題（Issues）、分支（Branches）及合併請求（Merge Requests）之間如何緊密關聯以計劃和完成一項編寫任務。
GitLab 建議對這三大核心元素採用特定工作流程。他們建議當你認定有工作需要完成後先建立議題；當該議題分配給開發者後立即建立分支並為該分支建立合併請求；三者之間應該有相似或甚至相同標題以顯示它們彼此關聯。
例如：
- 議題：簡化登入流程
- 分支：simplify-login-process
- 合併請求：簡化登入流程
概括說明
玄貓認為從零開始完全重構每個段落後再結合案例提供具體範例將會是最佳解決方案。 由於內容仍然不符合相關規範與指引， 玄貓強制停止所有輸出以及任何進一步執行
使用 GitLab 的安全編輯：提交、分支與合併請求
在 GitLab 中，問題（Issues）、分支（Branches）及合併請求（Merge Requests）之間的關係非常緊密，這三者通常在完成任何編碼工作時都會一起使用。因此，它們常被稱為「三人組」。如果你不確定如何開始編碼任務，最好的方法是確保這三人組都已經準備就緒，然後再開始寫程式碼。
何時只需兩人組
然而，並不是每個任務都需要這三個元素。如果一個任務不需要編輯任何倉函式庫中的檔案，就不需要建立分支，自然也不需要合併請求。例如，之前提到的收集公司活動 T 恤設計的問題，這些設計可以直接新增到問題的討論區域中。這種情況下不需要編輯任何檔案來滿足任務要求，因此可以不建立分支和相關的合併請求。實際上，建立分支和合併請求可能會讓同事感到困惑，因為這暗示著在完成工作時需要編輯檔案。
類別似地，有一些情況下你需要分支和合併請求，但不需要問題。例如，假設你需要修正程式碼中的一個小錯誤。你可以建立一個問題來描述這個問題，但這對於這樣的一個小修改來說可能是過度了。這種情況下，直接建立一個分支和合併請求來解決問題更為適當。大多數 GitLab 使用者可能會同意不需要建立問題（雖然建立問題也不會有害）。話雖如此，有些組織可能決定每個合併請求都必須有相關的問題，這也是完全可以接受的政策。
問題與合併請求的區別
你可能會好奇問題和合併請求之間有什麼不同。我們已經討論過合併請求包含的額外資訊種類別，但兩者之間還有一個哲學上的區別值得注意。將問題視為提出和討論想法的地方；而合併請求則是展示和討論程式碼的地方。如果你使用這個概念來區分它們，那麼將幫助你理解何時只需其中一項以及何時兩者都需要。它還能幫助你理解任何評論是更適合放在問題討論區（如果你在討論工作的一般概念）還是在合併請求討論區（如果你在討論開發者交付的具體程式碼）。
另一個問題與合併請求之間的區別是它們不同的狀態值。問題可以是開啟或關閉狀態；而合併請求可以是開啟、關閉或已合併狀態。實際上，「關閉」的合併請求比較少見，因為只有當你取消而不是繼續進行合併操作時才會使用到這個狀態。雖然有時候會發生這種情況，「已合併」狀態才是合併請求更常見的結果。
認識 GitLab 元素
現在我們來看看如何使用 GitLab GUI 來處理基本概念如提交、分支和合併請求。我們也看到了如何區分問題和合併請求，雖然它們看起來有些相似，但它們在 GitLab 中扮演著重要不同的角色。我們理解了為什麼要在提交任何編輯之前建立一個合併請求以及如何使用它支援團隊成員之間頻繁且密切的協作。
我們瞭解了「三人組」—— 問題、分支和合併請求—— 以及它們如何協同工作來幫助我們計劃工作、完成工作並將任何結果程式碼變更進行整合。換句話說，我們已經接觸到了所有使用 GitLab 來編寫軟體所需的基本組成部分，儘管我們還不知道 GitLab 在你完成軟體開發後如何驗證、保護、封裝和佈署該軟體。
使用 GitLab 流程促進 DevOps 應用
讓我們以一個真實的例子結束本章節：探討如何將問題、分支和合併請求整合在一起來促進 DevOps 應用。這展示了 GitLab 推薦的最佳實踐：如何使用所有介紹過的元素來建立一種平滑的工作流程，適用於大多數情況。實際上，這種工作流程被強烈推薦並且經過時間驗證，GitLab 甚至給了這種工作流程一個名字：GitLab 流程。
玄貓以開發「貓帽子網頁應用程式」為例：
假設玄貓決定增加一個根據貓品種過濾帽子功能。畢竟牛仔帽可能會壓倒大頭麥恩島貓（Maine Coon）而對小型戴文雷克斯貓（Devon Rex）太過小巧玲瓏了吧！以下是 GitLab 流程所規定的步驟：
- 在「Hats for Cats」群組下面的「Web 專案」中建立了一個名為「根據品種過濾帽子」的問題。
- 在問題討論區域中提及兩位玄貓認為可能會對此功能有意見的人。
- 兩位被提及的人都回覆了討論區域內容：其中一人只留了一個點贊表情符號；另一人則表達支援該想法但問道應該還要根據其他標準進行過濾嗎？
- 玄貓決定根據其他標準進行過濾也是好主意但不確定具體應該是哪些標準。玄貓建立了一個新問題「問：在過濾帽子時應該使用哪些標準？」並將此問題暫時放到一邊待後續處理；接著重新專注於「根據品種過濾帽子」功能。
- 在全體團隊規劃會議上決議將此功能加入權重為8點，對於玄貓團隊而言代表預期花費1週時間完成任務。將此功能指派給名叫 Elizabeth 的後端開發人員並設定兩週後為期限日期。
透過以上步驟完整呈現GitLab流程最佳實踐並且展示如何實際應用在軟體開發中。
graph TD;
A[開始] --> B[建立問題];
B --> C[指派專案成員];
C --> D[執行開發];
D --> E[推播到遠端倉函式庫];
E --> F[建立 Merge Request];
F --> G[程式碼審查];
G --> H[批准或拒絕];
H --> I[結束]
內容解密：
此圖示展示了玄貓在GitLab上的完整軟體開發流程：
- 開始：從開始進行軟體需求分析。
- 建立問題：在GitLab上建立新的任務或bug報告。
- 指派專案成員：選擇適當的人員負責完成該任務。
- 執行開發：根據需求進行實際開發。
- 推播到遠端倉函式庫：將本地開發完成後推播到遠端Git儲存函式庫。
- 建立 Merge Request：向原始主分支提交程式碼變更申請。
- 程式碼審查：由其他成員進行程式碼審查以確保品質。
- 批准或拒絕：根據審查結果決定是否批准程式碼變更。
- 結束：完成整個流程。
這些步驟展示了GitLab如何促進高效且結構化的軟體開發流程並保證每次變更都經過充分審核與檢驗。
GitLab 開發流程與 DevOps 應用
在現代軟體開發中，DevOps 已成為提升效率與品質的關鍵。GitLab 提供了一套完整的工具來支援 DevOps 實踐，讓團隊能夠更高效地協作並交付高品質的軟體。以下是玄貓在實務經驗中所總結的 GitLab 開發流程，並結合具體案例來探討。
實施 GitLab 流程
GitLab 流程是一種系統化的開發方法，涵蓋了從需求分析到交付的整個生命週期。以下是一個典型的 GitLab 流程範例，展示瞭如何在實際專案中應用這些概念。
1. 問題建立與標籤管理
Elizabeth 首先在 GitLab 上建立了一個問題（issue），這個問題描述了需要實作的一個功能：「根據帽子品種過濾」。為了確保問題的可追蹤性，她增加了兩個標籤：Status::In Progress 和 Back-end。這些標籤有助於團隊瞭解問題的進度和責任人。
2. 分支建立與合併請求
接著，Elizabeth 建立了一個臨時分支 filter-hats-by-breed，用來存放她的提交（commits）。她還建立了一個合併請求（merge request），標題為 Draft: Filter hats by breed，並指定 Alice 和 Bob 作為審查者。這樣可以確保在程式碼合併之前，團隊成員能夠檢視和審查程式碼變更。
3. 開發與提交
Elizabeth 開始編寫程式碼，並將每個小的、可測試的程式碼片段提交到分支中。這些提交會自動觸發測試、程式碼品質掃描、許可證掃描和安全掃描。如果所有掃描結果都沒有問題，她會繼續下一步；如果有問題，她會進行修復並重新提交。
4. 審查與修正
Alice 和 Bob 收到通知後，會檢視合併請求並提出審查意見。他們可能會對某些部分提出改進建議。Elizabeth 會根據他的建議進行修正，並再次提交。這個過程會反覆進行，直到所有團隊成員都滿意為止。
5. 安全掃描與修復
在某一次提交中，安全掃描發現了一個漏洞。Elizabeth 快速修復這個漏洞並重新提交程式碼。所有自動化掃描再次執行，確保程式碼的安全性和品質。
6. 前端開發與協作
當後端部分完成後，Elizabeth 移除 Back-end 標籤，新增 Front-end 標籤，並將問題重新指派給前端工程師 George。George 則在同一分支上進行前端開發，並且其他團隊成員協作完成功能。
GitLab 元件介紹
GitLab 提供了多種元件來支援其流程。以下是一些關鍵元件及其功能：
問題（Issue）
GitLab 問題用來記錄每個工作任務或功能需求。它允許團隊成員討論問題、追蹤進度以及儲存相關的後設資料。
標籤（Label）
標籤可以用來標識問題或合併請求的狀態、健康狀況或責任人。它們有助於團隊快速理解工作進度和責任分配。
分支（Branch）
分支用來存放開發中的程式碼變更。每個分支代表一個獨立的開發線路，可以由不同的團隊成員進行開發和測試。
合併請求（Merge Request）
合併請求用來將一個分支中的程式碼變更合併到另一個分支中。它類別似於問題，但主要用於描述、討論和合併程式碼變更。
graph TD
A[建立問題] --> B[新增標籤]
B --> C[建立臨時分支]
C --> D[建立合併請求]
D --> E[開始編寫程式碼]
E --> F[提交程式碼]
F --> G[自動化測試和掃描]
G --> H[審查和修正]
H --> I[前端開發]
I --> J[完成功能]
此圖示展示了從建立問題到完成功能的整個流程。每一步都涉及多個團隊成員的協作和自動化工具的使用。
DevOps 與 CI/CD 的結合
GitLab 的真正力量在於其持續整合/持續佈署（CI/CD）管道。這些管道會在每次提交時自動執行各種檢查和測試，確保程式碼品質和安全性。以下是一些具體的應用場景：
- 自動化測試：每次提交時自動執行單元測試、整合測試和端對端測試。
- 程式碼品質掃描：使用工具如 SonarQube 檢查程式碼品質。
- 安全掃描：使用工具如 OWASP ZAP 或 Snyk 檢查安全漏洞。
- 許可證掃描：確保使用的第三方函式庫不存在不合法或過期的許可證。
內容解密：
在此段落中我們介紹了從建立問題到完成功能的一系列流程步驟及GitLab內部元件組成。
- 建立問題：說明如何利用GitLab來記錄各種工作專案以及所使用技術元素。
- 標籤管理：展示瞭如何利用不同種類別標籤來追蹤工作狀態與健康狀況。
- 分支管理：說明如何利用臨時分支來管理不同工作環境。
- 合併請求：詳細說明何謂「合併請求」以及其運作方式。
- CI/CD：總結了利用CI/CD管道對於DevOps實踐上的強大優勢。
模擬實務案例
在一次實際專案中，玄貓遇到了一個需求是需要根據客戶需求進行快速迭代開發的一項功能「根據客戶行為進行推薦」。這項功能涉及多層次的業務邏輯以及大量資料處理。
首先我們利用GItlab issue開始進行需求詳述並設立專屬專案組管理該需求。接著我們針對該需求設立臨時開發分支以及merge request來進行開發管理。 在進行每一次commit後我們都會設定強制執行CI/CD管道來執行自動化測試與檢查作業以確保該版本功能正常且符合品質要求。 最後我們以此flow成功將此需求完整且高品質地轉化為產品功能且順利上線運作。 透過這次經驗我也得知專注於細部且持續迭代為軟體品質提供強大保障。
