iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 29
1

《Day 6 初探 GitLab Workflow & GitLab Flow》,我們有提到 Workflow 的最後一個步驟是 Feedback,對此 GitLab 提供了 Cycle Analytics 的功能,幫助團隊能夠了解每個步驟大致上個別花費了多少時間。

一樣用的老梗來說明,如果我們想要減肥,首先要做的不是去尋找各種減肥妙方,第一個步驟應該是先去量體重、體脂,知道自己身體的現況之後,再來訂定減肥計劃。同理,如果想要「持續改善」團隊的 Workflow、生產力,首先你也需要一些數據做為參考,幫助你找出團隊可能的瓶頸點。

Cycle Analytics

只要進入 Project > Cycle Analytics 即可看見下圖的畫面。在畫面中可以看見 GitLab 規劃 Cycle Analytics 可以幫忙我們自動計算 7 個不同步驟的時間數據。
https://ithelp.ithome.com.tw/upload/images/20191012/20120986KShRQxYzQa.jpg

這幾個步驟的都有各自計算的條件,只要達成條件就會自動收集數據。

  • Issue: 會自動收集從 Issue 被開立直到被設置了 milestone 或被移動至 Issue Board 的 list (例如移動至 To-DO)需要經過多久時間。這正是對應 GitLab Workflow 10 個步驟中,從 Idea 到 Issue 這兩個步驟,也就是當 Idea 被開立為一張又一張的 Issue(Idea) 之後,要經過多久的時間才會從 Idea 被轉變成真正需要執行的 Issue。
  • Plan: 會自動收集從 Issue 被排定為需要執行的工作項目之後,要經過多久時間才會出現首個與該 Issue 相關的 Commit。意思就是我們假設當 Issue 被排定為工作項目時,同時就被指派給某個工程師負責,工程師收到 Issue 之後,就會開始構思(Plan)該如何解決它,當他構思(Plan)完畢之後,他便會建立一個 Feature branch 並送出 first commit,開始著手實踐,這整段過程要花多久時間,就是 Plan。
  • Code: 會收集 Issue 的首個 Commit 到產生與此 Issue 相關的 Merge request 要經過多久時間。當工程師送出首個 Commit 之後,中間還會經過數次 Commit,等到該 Issue 的內容都被撰寫完畢之後,工程師就會送出 Merge request,而這整段撰寫程式花費多久時間,即是 Code。
  • Test: 會自動收集前述該 Issue 的 Feature branch 其 CI Pipeline 中的各項 CI Job 分別花了多久時間才執行完畢。理論上 Feature branch 內的各項 CI Job 都是與測試相關的內容,這些都被歸類在 Test。
  • Review: 會自動收集 Merge request 從開立直到被 merge 或 close 為止,需要經過多久時間。當工程師送出 Merge request 之後,接著由資深工程師負責 Review,假如有任何的問題導致尚不能 Merge 還必須進一步修改,工程師們可以在 Merge request 的頁面上進行討論,等到所有的問題都被解決之後才將程式 Merge 回主要的 branch,這整段時間與過程被歸類在 Review。
  • Staging: 計算從 Merge request 完成程式碼的 merge 之後一直到它被順利部署至 Production 環境需要經過多久時間。
  • Production: 計算從 issue 開立直到它被部署至 Production 環境需要經過多久時間,也就是從一個 Idea 的產生直到它走完整個 Workflow 要花費多久時間。

試用 Cycle Analytics

下面我們一樣利用先前試用 Auto DevOps 建立的範例 Project 來試用 Cycle Analytics。

  1. 首先建立一個新的 Issue,但不設置它的 Milestone。
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986XlvqBHeJuQ.jpg

  2. 等個幾分鐘後,我們再更新 Issue,為它設置 Milestone。
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986R6mrYDQd5W.jpg

    於是 Cycle Analytics 就能得到 Issue 的數據。
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986jE7KcoOuN0.jpg
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986lBpY0QdNR7.jpg

  3. 接著為 Issue 建立 Feature branch,並且送出 first commit。記得 Commit message 要標註 Issue 編號,例如 #1
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986WKAztr9JVx.jpg
    於是 Cycle Analytics 就能得到 Plan 的數據。
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986KcYXEa7Y9Z.jpg
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986xYgaed2gNu.jpg

  4. 下一步我們要以這個 Feature branch 建立 Merge request。記得 Merge request 的描述中也要包含 Issue 的編號及 Close 字串,例如 Closes #1
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986EbgTdjWUbn.jpg
    如此一來 Cycle Analytics 就能得到 Code 的數據。
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986jw8hgnDfhI.jpg
    (不好意思,這個範例太假。)
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986ZRm5ZhfgZ9.jpg

  5. 由於 Auto DevOps 會自動為我們的 Feature branch 產生 CI Pipeline,因此這一步我們不需要特別做什麼,只要等待 CI Job 執行完畢即可。
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986VZQxeLbfGv.jpg
    Cycle Analytics 自動會收集 Test 的數據。
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986ySgCizYSgJ.jpg
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986TG8dFi1mxa.jpg

  6. 接著,我們前往 Merge request 的頁面,按下 Merge 按鈕完成 Merge 的動作。
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986q4c6w8dNby.jpg
    於是 Cycle Analytics 就能得到 Review 的數據。
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986uq5cuXH78u.jpg
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986LJDcYvO1lr.jpg

  7. 同樣的 Auto DevOps 有幫我們產生 Staging Deploy 與 Production Deploy 的 CI Job,因此只要等待 CI/CD Pipeline 完成 Stage: Staging,接著我們趕快按下 Production Deploy 的按鈕即可。
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986ROZaBIkRpK.jpg
    等到 Production Deploy 都完成之後,Cycle Analytics 就能得到 Staging 與 Production 的數據。
    https://ithelp.ithome.com.tw/upload/images/20191012/20120986gcVd6ndpVh.jpg

Chart

除了 Cycle Analytics 之外,GitLab 也有提供多種 Chart。這些 Chart 分屬在多個功能之下,一樣能為團隊提供一些 Feedback。

Repository Charts

https://ithelp.ithome.com.tw/upload/images/20191012/20120986XWe9gkbSuB.jpg

CI/CD Charts

https://ithelp.ithome.com.tw/upload/images/20191012/20120986ily5Ht5F9J.jpg

Milestones 之下的 Burndown Chart

有在跑 Agile 的朋友應該都聽過 Burndown Chart。這個是付費功能,但如果你想試用看看,只要在 gitlab.com 上將 Project visibility 設為 Public 就會出現。下面就直接借用官方文件的圖片了。
https://ithelp.ithome.com.tw/upload/images/20191012/201209868MKTmL3bhQ.jpg
(圖片來自 https://docs.gitlab.com/ee/user/project/milestones/burndown_charts.html)

Project Insights

這也是另外一個付費功能,同樣如果想試用看看,只要在 gitlab.com 上將 Project visibility 設為 Public 就會出現。下面一樣就直接借用 GitLab 官方文件的範例圖片。
https://ithelp.ithome.com.tw/upload/images/20191012/20120986Tgi2DsyLqO.jpg
(圖片來自 https://docs.gitlab.com/ee/user/project/insights/)

小結

再次重申 Feedback 是 GitLab Workflow 最後也是非常重要的一個步驟,有了 Cycle Analytics 為我們自動收集的這些數據,團隊就可以做為參考,以此回顧專案進度、工時與各環節的控管狀況,幫助團隊找出目前開發流程中可能的瓶頸點。當然這些數據是死的,而且只要一不小心沒有按著 GitLab 規定的順序操作,GitLab 就無法自動收集這些數據。因此數據僅供參考,團隊的「持續改善」可不能只盯著數字,還是要收集多方的回饋,與團隊討論取得共識之後,再實施改善計畫。

今天就分享到這裡,鐵人賽也進入倒數了,明天就是隨便亂哈拉的總結嘍!我們明天見~

參考資料


上一篇
GitLab: Auto DevOps 之牛刀小試 6 - Customizing
下一篇
回顧與總結
系列文
和艦長一起 30 天玩轉 GitLab30

尚未有邦友留言

立即登入留言