iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 6
2
DevOps

和艦長一起 30 天玩轉 GitLab系列 第 6

初探 GitLab Workflow & GitLab Flow

按著昨天的故事,我們假想中的產品開發團隊已經順利成立了,但在團隊開始投入開發工作之前,需要先和團隊成員們確認接下來團隊的工作分配、Workflow 以及團隊協作方式。

在我們假想的背景故事中,這是一個全新籌組的團隊,負責開發公司全新的產品。因此作為故事中的關鍵主管 Dev Leader 早已在心中作出決定,就是要採用 GitLab 作為團隊合作協作的核心工具,讓團隊直接採用 GitLab Workflow 作為團隊的 Workflow。(謎之音:故事不這樣演下去,艦長沒辦法繼續介紹 GitLab 啊~)

GitLab Workflow 簡介

GitLab 公司認為,一般來說從創意發想(Idea)開始直至產品上線並收集回饋意見(Feedback)為止,我們可以將軟體的開發流程(Workflow)大致劃分為 10 個步驟,10 個步驟彼此相連並且與團隊的生產力息息相關。而 GitLab Workflow 即是以 GitLab 為核心工具,借助 GitLab 的產品生態系,讓開發團隊能夠有效地串連這 10 個步驟,迅速搭建團隊的 Workflow。

下面就來說明這 10 個步驟有哪些重點,以及 GitLab 產品生態系又是如何在每個步驟提供支援:

  1. Idea: 除了面對面的實體會議,線上的聊天討論空間中的某個想法,也許亦有機會成為產品創意發想的養分。現今多數的開發團隊皆十分流行使用 Slack 這一類的工具,作為團隊的溝通協作工具,這些工具不僅在公事上為團隊提供了更方便、有效的溝通媒介,甚至於私它們也能為團隊的凝聚提供助益。而 GitLab 早在 2015 年便注意到團隊溝通協作工具的重要性,自 GitLab 7.14 版開始,GitLab 便將 Mattermost 這套類似 Slack 的 Open Source 團隊溝通協作工具納入 GitLab 的工具生態系。因此可以說打從團隊預備在線上溝通、討論產品概念的那一刻開始,GitLab 就已在背後支持著團隊了。
  2. Issue: 有了天馬行空的 Idea 之後,接著要將其轉變成更具體明確的 Story 或 Issue。而 GitLab 則提供了完整的 Issue Tracking 功能,GitLab 的 Issue Tracker 既可作為獨立的 Issue 討論空間,亦可以與實際程式碼之 commit 紀錄建立關聯。
  3. Plan: 延續步驟二,當 Story 或 Issue 被逐一建立完畢之後,不論你要走瀑布式、敏捷或隕石開發,在進入實際的程式開發工作之前,當然要先有所「計畫」,決定工作的優先順序。而 GitLab 的 Issue Tracker 可以直接搖身一變成為 Issue Board——即任務版(Task Board),幫助團隊一覽開發工作進行狀況的全貌。當然工具是隨人靈活使用的,雖然 Issue Board 尚欠缺仿間數位看板(KanBan)軟體的某些進階功能,但如果你習慣用看板方法來管理專案,你還是能在有所變通的狀況下,以看板方法的方式來使用 Issue Board。
  4. Code: 有了計畫之後,下一步當然就是動手撰寫程式。
  5. Commit: 程式撰寫完畢之後,即可送入版本控制之中。這應該不需多說,GitLab 的核心功能就是 Git 版本控制。
  6. Test: 當程式碼被提交至版本控制系統之後,接著就是測試。這也就是 GitLab CI 服務上場的地方了。
  7. Review: 當 CI 自動化建置、測試都通過之後,在將程式碼 Merge 至主要的 Branch 之前,需要先進行 Review 的動作。而 GitLab 的 Merge Request 功能,則提供了良好的機制,讓團隊可以針對 Merge Request 進行討論。
  8. Staging: 程式順利 Merge 之後,即可將程式自動部署至 Staging 或 Production-like 的環境,藉此再次驗證程式是否正確運行。除了 GitLab CI 既有的 CI / CD 功能之外,GitLab CI 目前更擁有名為 Auto DevOps 的神奇功能,讓 CI / CD / 自動化部署更加自動、順暢與便利。
  9. Production: 續上,當程式在 Staging 環境亦順利通過驗證,最後即可部署至 Production 環境供使用者使用。GitLab CI 目前已有 Environment 的功能,若是你有妥善規劃 Environment 與 CI / CD 流程,那麼對團隊而言 Production Deploy 也不過就是按下 GitLab 操作介面上的按鈕那樣簡單的一件小事。
  10. 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。

參考資料


上一篇
GitLab: 從建立 Group 和 Project 開始
下一篇
GitLab 和 Mattermost
系列文
和艦長一起 30 天玩轉 GitLab30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

0
Cheng Wei
iT邦新手 5 級 ‧ 2022-09-09 11:39:45

友善提醒,因為 GitLab 已更新版本,此文的內容已部分過期。

Cheng Wei iT邦新手 5 級 ‧ 2023-01-25 23:15:30 檢舉

自 2021 年 12 月 12 日開始,我就一直想要將原發佈在 iT 邦幫忙的鐵人賽系列文章搬移至 https://gitlab-book.tw 並補充說明文章內容已有過期之處。

因為當初參加 iThome 鐵人賽時,GitLab 仍在 12 版,但如今 GitLab 已更新好幾版了,需要提醒大家注意一下。

本文已完成搬遷

我要留言

立即登入留言