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

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

Cycle Analytics

只要進入 Project > Cycle Analytics 即可看見下圖的畫面。在畫面中可以看見 GitLab 規劃 Cycle Analytics 可以幫忙我們自動計算 7 個不同步驟的時間數據。

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

• 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。
   

2. 等個幾分鐘後，我們再更新 Issue，為它設置 Milestone。
   

   於是 Cycle Analytics 就能得到 Issue 的數據。
   
   

3. 接著為 Issue 建立 Feature branch，並且送出 first commit。記得 Commit message 要標註 Issue 編號，例如 #1。
   
   於是 Cycle Analytics 就能得到 Plan 的數據。
   
   

4. 下一步我們要以這個 Feature branch 建立 Merge request。記得 Merge request 的描述中也要包含 Issue 的編號及 Close 字串，例如 Closes #1
   
   如此一來 Cycle Analytics 就能得到 Code 的數據。
   
   （不好意思，這個範例太假。）
   

5. 由於 Auto DevOps 會自動為我們的 Feature branch 產生 CI Pipeline，因此這一步我們不需要特別做什麼，只要等待 CI Job 執行完畢即可。
   
   Cycle Analytics 自動會收集 Test 的數據。
   
   

6. 接著，我們前往 Merge request 的頁面，按下 Merge 按鈕完成 Merge 的動作。
   
   於是 Cycle Analytics 就能得到 Review 的數據。
   
   

7. 同樣的 Auto DevOps 有幫我們產生 Staging Deploy 與 Production Deploy 的 CI Job，因此只要等待 CI/CD Pipeline 完成 Stage: Staging，接著我們趕快按下 Production Deploy 的按鈕即可。
   
   等到 Production Deploy 都完成之後，Cycle Analytics 就能得到 Staging 與 Production 的數據。
   

Chart

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

Repository Charts

CI/CD Charts

Milestones 之下的 Burndown Chart

有在跑 Agile 的朋友應該都聽過 Burndown Chart。這個是付費功能，但如果你想試用看看，只要在 gitlab.com 上將 Project visibility 設為 Public 就會出現。下面就直接借用官方文件的圖片了。

（圖片來自 https://docs.gitlab.com/ee/user/project/milestones/burndown_charts.html）

Project Insights

這也是另外一個付費功能，同樣如果想試用看看，只要在 gitlab.com 上將 Project visibility 設為 Public 就會出現。下面一樣就直接借用 GitLab 官方文件的範例圖片。

（圖片來自 https://docs.gitlab.com/ee/user/project/insights/）

小結

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

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

參考資料

• https://about.gitlab.com/blog/2016/10/25/gitlab-workflow-an-overview/#feedback
• https://about.gitlab.com/product/cycle-analytics/
• https://about.gitlab.com/blog/2016/09/21/cycle-analytics-feature-highlight/
• https://gitlab.com/help/user/analytics/cycle_analytics.md
• https://docs.gitlab.com/ee/user/project/milestones/burndown_charts.html
• https://docs.gitlab.com/ee/user/project/insights/