初探 GitLab Workflow & GitLab Flow
本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。
本系列文是從 iT 邦幫忙鐵人賽系列文章搬至 gitlab-book.tw，鐵人賽撰文時 GitLab 仍為 12.x 版本，因此本系列文內容已有部分過期，本次搬移至此後，會視狀況新增一些補註說明。 鐵人賽原文網址：https://ithelp.ithome.com.tw/articles/10217430）
按著昨天的故事，我們假想中的產品開發團隊已經順利成立了，但在團隊開始投入開發工作之前，需要先和團隊成員們確認接下來團隊的工作分配、Workflow 以及團隊協作方式。
在我們假想的背景故事中，這是一個全新籌組的團隊，負責開發公司全新的產品。因此作為故事中的關鍵主管 Dev Leader 早已在心中作出決定，就是要採用 GitLab 作為團隊合作協作的核心工具，讓團隊直接採用 GitLab Workflow 作為團隊的 Workflow。（謎之音：故事不這樣演下去，艦長沒辦法繼續介紹 GitLab 啊～）
【新增補充】GitLab 原廠已經捨棄 GitLab Workflow，改為倡議 DevOps Lifecycle，至於 GitLab Workflow 則被原廠拿去當作 VS Code extension 的名稱。 GitLab 原廠不止捨棄原本推崇的 GitLab Workflow，甚至將當年介紹何為 GitLab Workflow 的 文章徹底刪除（即是本文「參考資料」中的連結 https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/），只能說官方真是做得很絕。 因此本文的關於 GitLab Workflow 的內容基本上都是過期了，但雖說是過期，也只是對於 GitLab 原廠而言是過期的，筆者個人的想法是，它依然是一個值得我們參考的範本，如果你對於該如何規劃自己團隊的 Workflow 毫無頭緒時，它依然是具備一定程度的參考價值。
GitLab Workflow 簡介
GitLab 公司認為，一般來說從創意發想（Idea）開始直至產品上線並收集回饋意見（Feedback）為止，我們可以將軟體的開發流程（Workflow）大致劃分為 10 個步驟，10 個步驟彼此相連並且與團隊的生產力息息相關。而 GitLab Workflow 即是以 GitLab 為核心工具，借助 GitLab 的產品生態系，讓開發團隊能夠有效地串連這 10 個步驟，迅速搭建團隊的 Workflow。
下面就來說明這 10 個步驟有哪些重點，以及 GitLab 產品生態系又是如何在每個步驟提供支援：
- Idea: 除了面對面的實體會議，線上的聊天討論空間中的某個想法，也許亦有機會成為產品創意發想的養分。現今多數的開發團隊皆十分流行使用 Slack 這一類的工具，作為團隊的溝通協作工具，這些工具不僅在公事上為團隊提供了更方便、有效的溝通媒介，甚至於私它們也能為團隊的凝聚提供助益。而 GitLab 早在 2015 年便注意到團隊溝通協作工具的重要性，自 GitLab 7.14 版開始，GitLab 便將 Mattermost 這套類似 Slack 的 Open Source 團隊溝通協作工具納入 GitLab 的工具生態系。因此可以說打從團隊預備在線上溝通、討論產品概念的那一刻開始，GitLab 就已在背後支持著團隊了。
- Issue: 有了天馬行空的 Idea 之後，接著要將其轉變成更具體明確的 Story 或 Issue。而 GitLab 則提供了完整的 Issue Tracking 功能，GitLab 的 Issue Tracker 既可作為獨立的 Issue 討論空間，亦可以與實際程式碼之 commit 紀錄建立關聯。
- Plan: 延續步驟二，當 Story 或 Issue 被逐一建立完畢之後，不論你要走瀑布式、敏捷或隕石開發，在進入實際的程式開發工作之前，當然要先有所「計畫」，決定工作的優先順序。而 GitLab 的 Issue Tracker 可以直接搖身一變成為 Issue Board——即任務版（Task Board），幫助團隊一覽開發工作進行狀況的全貌。當然工具是隨人靈活使用的，雖然 Issue Board 尚欠缺仿間數位看板（KanBan）軟體的某些進階功能，但如果你習慣用看板方法來管理專案，你還是能在有所變通的狀況下，以看板方法的方式來使用 Issue Board。
- Code: 有了計畫之後，下一步當然就是動手撰寫程式。
- Commit: 程式撰寫完畢之後，即可送入版本控制之中。這應該不需多說，GitLab 的核心功能就是 Git 版本控制。
- Test: 當程式碼被提交至版本控制系統之後，接著就是測試。這也就是 GitLab CI 服務上場的地方了。
- Review: 當 CI 自動化建置、測試都通過之後，在將程式碼 Merge 至主要的 Branch 之前，需要先進行 Review 的動作。而 GitLab 的 Merge Request 功能，則提供了良好的機制，讓團隊可以針對 Merge Request 進行討論。
- Staging: 程式順利 Merge 之後，即可將程式自動部署至 Staging 或 Production-like 的環境，藉此再次驗證程式是否正確運行。除了 GitLab CI 既有的 CI / CD 功能之外，GitLab CI 目前更擁有名為 Auto DevOps 的神奇功能，讓 CI / CD / 自動化部署更加自動、順暢與便利。
- Production: 續上，當程式在 Staging 環境亦順利通過驗證，最後即可部署至 Production 環境供使用者使用。GitLab CI 目前已有 Environment 的功能，若是你有妥善規劃 Environment 與 CI / CD 流程，那麼對團隊而言 Production Deploy 也不過就是按下 GitLab 操作介面上的按鈕那樣簡單的一件小事。
- Feedback: 這是最後、也是非常重要的一個步驟，它能幫助產品及團隊自身得以繼續不斷的「持續改善」。GitLab 目前已有 Cycle Analytics 功能，可以針對專案進度、工時的控管狀況提供數據分析，如團隊能善用這項功能，即可幫助團隊發覺目前開發流程中的瓶頸點，讓團隊能有所本的向著「持續改善」的道路前進。
大致認識 GitLab Workflow 的 10 個步驟其概況後，其實我們會發現這條 Workflow 與其他常見的 Workflow 也並無太大差異。重要的關鍵還是在於到底 GitLab 在建構產品生態系時，為這條 Workflow 提供了哪些合適的功能，而這些功能又是如何幫助團隊得以順利上手運用這套 Workflow。
關於 GitLab Workflow 實際會使用到哪些 GitLab 功能且該如何使用，這些內容我們會隨著文章的進度，再逐一說明。
GitLab Flow
知道 GitLab Workflow 的 10 個步驟後，接著要說明另一項與 Workflow 十分相關的事情，即是我們的假想團隊這次將採用的 Git 分支策略——GitLab Flow。
GitLab Flow 是 GitLab 公司由 GitHub Flow 再發展而來的。GitLab Flow 保留了 GitHub Flow 的分支策略，依然有 feature branch 與 master branch，但在 master 之外再增加專門用來配合交付與部署的 branch，例如 pre-production branch、production branch 或 特定版號 -stable。
- Production branch：用來幫助團隊明確知道目前正式上線的程式碼是哪一個版本。因此團隊可以按著開發步調持續地推進開發工作，開發進度依然按照 Github Flow 的做法，由 feature branch 合併至 master branch。當程式要正式上線時，才根據要交付的範圍，從 master branch 合併至 production branch，同時在 production branch 即可搭配 GitLab CI 功能觸發 CI Job - production deploy。
- Environment branch：續上，GitLab Flow 建議你除了多增加 production branch 對應正式環境之外，你也可以根據不同的部署環境額外建立對應的 branch。例如也許你的正式環境是一個龐大的分散式架構，因此在部署到正式環境之前，為了避免出現預期之外的問題，還需要先在和正式環境類似但規模較小的 pre-production 環境進行測試與驗證；在此情境下，你不妨就增加一個 pre-production branch 對應 pre-production 環境。同理，也許今天某公司可能需要定期展示最新功能給投資人觀看，需要一個環境會定期部署最新版本的程式，GitLab Flow 建議即可增加一個 vc branch 來管理它。
- Release branch：最後，如果你的程式並非是直接部署於某個環境，而是直接對外發佈（release），那麼 GitLab Flow 的作法是不一定要建立 production branch，而是改為根據每次的 release 建立對應的 release branch。這麽做的目的在於讓 master branch 能夠持續地穩健前進，而 release 出去的分支既能保持當下版本在功能上是獨立 stable 的狀態，又能適度的跟隨 master 修補程式漏洞。
根據上面的內容，我們可以了解到 GitLab Flow 保留了 feature branch 與 master branch，使得開發團隊能專注於開發工作。同時額外新增的 production、environment 及 release branch，再搭配 GitLab 的 CI、merge request、issue tracking、Environment 等功能，將能幫助開發工作和交付部署工作之間能做出適度的切分，避免相互影響。
小結
在今天的內容，我們介紹了 GitLab Workflow 與 GitLab Flow 這兩個必須先讓團隊成員都清楚認知的重要觀念，當團隊成員都能對此建立共識，遵守開發工作流程中的默契與規則，團隊的生產力與協作能力才能有所提升。
今天的內容就到此，明天讓我們來認識一下 GitLab 整合至產品生態系中的團隊溝通協作工具 GitLab Mattermost。