使用 Gitlab issue board 達成任務與工作流程視覺化，並搭配 Webhook 打造自動化 Kanban
從 Gitlab CE 6.x 的時代一路用到了現在 10.x 的版本，應該也算是他們的資深用戶了。這篇文章會分享我這幾年在使用 Gitlab 跑敏捷開發的一些經驗談。
一開始我們的 Gitlab 只拿來存程式碼，專案的管理有嘗試過用 Trello 來管理工作流程，大約試了幾個 Sprint 之後就放棄了，放棄的原因是因為要一直在不同的系統間來回切換，還得花不少時間在維護 Trello board 讓它保持在最新狀態。
後來折衷的做法是使用 Gitlab 的 milestone 頁面，不過那頁也只有三種預設的清單 (Unstarted, Ongoing and Completed) 。雖然陽春了點，至少能大略了解目前的進度。最重要的是不用手動維護清單的狀態，對努力找到偷懶方法的軟體工程師來說，能自動的東西，絕對不想手動去做。
雖然 Milestone 頁面，能夠提供目前的進度，但是對更細節的資訊就稍嫌不足。譬如我想知道某個 BUG 目前的修復狀態到哪了，原本的介面只會告訴我正在進行中。無法得知是已經開始進行、正在進行自動化測試或者已經部署到 Staging 環境上等待驗收之類的訊息。
對於每個月總會定時更新 Gitlab 的忠實用戶來說，看到他們推出 issue board 的時候其實還滿興奮的，馬上將當時的工作流程切割成洋洋灑灑數個階段，並放到 issue board 上面。
上圖所包含的階段分別是：
- Planning: 規劃中的任務，還有些細節需要釐清。
- To Do: 接下來待處理的任務
- Doing: 處理中的任務。
- Ready for Testing: 已發出 Merge Request，等待執行自動化測試。
- Testing: 已發出 Merge Request，正在執行自動化測試。
- Ready for Review: 已通過自動化測試，等待 Code Review
- Review: 正在進行 Code review
- Staging: 已部署到 Stage 的環境，等待驗收。
- Ready for Production: 已在 Stage 環境驗收過，等待部署到 Production
- Production: 已部署到 Production 的環境，等待最後驗收。
分類完成後，看著井然有序的 Issue 列表，頓時覺得自我感覺良好XD。之前使用 Trello 時需要頻繁切換系統和 Milestone 頁面只有陽春狀態的問題都是過去式了。
然而這種自我感覺良好的心情並沒有持續太久。實際運作了一兩週後，發現我還是得花心力去維護 issue board 讓它保持在最新的狀態。最初版本的 issue board 唯一內建的自動化功能就只有切換清單的時候，會自動移除舊的標籤，並加上新的標籤。雖然後續有強化了不少功能，對當時的團隊來說遠遠不夠。這時軟體工程師努力讓自己可以變得更懶的病又發作了XD。
對我來說，最理想的目標就是每個人只要做著跟平常一樣流程（我們團隊使用的是 Git flow / Gitlab flow）：
- Open feature branch
- Make some change and commit
- Push to Gitlab
- Create merge request
- Review and merge
- Verify and close issue
Issue board 就會即時反應最新的狀態，需要人為介入的地方越少越好。要達到這個目的，我整合了 Gitlab webhook 和 Gitlab API 來打造一個自動化看板。下面的篇幅會一一介紹任務在每個工作階段移動的流程，與自動化所需的步驟。
Backlog 到 Planning / To Do
任務從 Backlog 到 To Do 的步驟，我們目前沒有做自動化。畢竟排定任務優先權與決定施作順序的責任還是在 PM 身上，暫時無法由機器代勞。
To Do 到 Doing
因為團隊是實行 Git flow / Gitlab flow 的關係，每次的功能變動後會先建立一個分支，告一段落後才會合併回 master。若是直接使用 Gitlab UI 建立分支的話，還會連對應的 Merge Request 都建立好。
所以這裡我串接了 Push event 的 webhook。因為走 Gitlab flow 的關係，分支的命名規則會是 ##-this-is-issue-xx-title 。最前面的 ## 代表的就是對應的 issue iid。
在 Push event webhook 裡面去解析來源分支的名稱，再拿解析出的 issue iid 去呼叫對應的 API 更改 issue label，增加 Doing 移除 To Do ( Issue board 的清單都是從特定的標籤產生的)。
Doing 到 Ready For Testing / Testing
當 Feature branch 的開發告一段落後，會發一個 Merge Request 給其他人。我們使用了 Gitlab description templates 來規範 Merge Request 的敘述要包含哪些東西，其中最重要的就是這個 MR 裡面包含的 issue 編號。
在 Merge Request event webhook 裡面去解析 description 的內容，得到所有相關連的 issue iid。再拿來源分支名稱去專案裡面的所有的 pipeline 清單做比較，得到最新的 pipeline id 與狀態， pending 就移到 Ready for Testing； running 就移到 Testing。最後再將所有 issue iid 寫入快取，讓接下來的 Pipeline event webhook 使用。
Ready for Testing / Testing 到 Ready for Review
每次 Feature branch 有新的 commit 都會觸發 CI pipeline，執行相關的自動化測試。為了即時反應 Merge Request 所包含之 Issue 的最新狀態，我在 Pipeline event webhook 裡面去檢查快取是否含有 Merge Request event 提及的 issue iid。如果有的話，在 pipeline 狀態變成 running 時，把 Ready for Testing 的 issue 移到 Testing；狀態是 success 時，把 issue 移到 Ready for Review 並通知 reviewer 可以開始進行 Code review 的流程。
通知 reviewer 的方式，目前是使用一個 Bot 的帳號透過留言 mention reviewer 的方式，這樣會觸發 Gitlab 內建的通知系統，並把這個留言自動加到 reviewer 的待辦清單裡。如果想要更即時的話還可以整合 Slack 的 API 同步發 Slack 訊息給 reviewer。
Ready for Review 到 Review
將 Code review 拆成 Ready for Review 和 Review 兩階段的原因是，當同一個 Reviewer 身上會同時有多個 Merge Request 等待審核時，就能知道哪些 issue正在審核中，而哪些 issue 還在排隊。
原本的做法是要求 Reviewer 手動將 issue 從 Ready for Review 拉到 Review 的清單，當一個 Merge Request 裡面包含多筆 issues 時，這就變成擾人的一件事。
為了解決這個問題，我們串接了 Comment event hook 針對在已通過自動化測試的 Merge Request 的留言動作，自動將同一個 Merge Request 裡面提到的相關 issues 移到 Review 的清單裡。
Ready for Review / Review 到 Staging
這裡串接了 Merge Request event hook。當 MR 被合併之後，Webhook 會將所有提及的 issue iid 存到快取中，讓接下來的 Pipeline event webhook 使用。
當 master 的 pipeline 執行成功後，Webhook 就會把快取裡的所有 issues 移到 Staging 的清單，把 issue 重新指派給 issue owner，並通知 issue owner 和PM 可以到 stage 上面去驗收成果。
Staging ➔ Ready for Production ➔ Production
在 Stage 上驗收完成的 issue 得由 issue owner / PM 手動拉到 Ready for Production。這會搭配接下來要部署到 Production 時，需要包含的 Changelog 有關。
當一個 Milestone 的功能都完成並測試過後，我們會發一個 Merge Request 並包含 Changelog 的訊息。這時 Merge Request event hook 就會去檢查，所有提及到的 issue 是否都已經在 Ready for Production 的清單裡面。當 MR 被合併之後，Webhook 一樣會將所有提及的 issue iid 存到快取中，當接下來的 Pipeline event webhook 部署成功後，就會將快取中所有的 issues 移到 Production 的清單，並通知 PM 做最後的驗收。
在更新過的流程裡面，需要手動調整 Issue board 的地方就只剩下一開始排定任務優先權和施作順序，以及最後在 Stage 和 Production 的驗收步驟。其他人只需要遵照正常的 Git flow / Gitlab flow 開發流程來作業，Issue board 就會反映專案目前最新的狀態，有這些資訊後才能確認目前的團隊工作流程是否存在瓶頸，對症下藥，進而加速團隊的交付速度。
