初探Gitlab API - 打造工時填寫與統計功能
從三月以來，敏捷一路走得跌跌撞撞，唯一堅持住的就是每日立會，
就這樣跑了兩個月，每天的會議也變成大家的習慣，
15分鐘雖然不長，但讓大家每天都能思考要做什麼，
並且即時反應問題讓團隊(或主管)去處理，就能顯著提升。
狼來了! 怎麼辦?
團隊雖然適應了這樣的步調，不過也沒真正執行完整的Scrum，直到...大老闆說要來review大家的Scrum執行成效!!
嗯，這個review實際上就是寫寫報告講給老闆聽，
不過也剛好趁這個外來的Force，再來全面執行Scrum一次，重新將6月定調為咱們的All New Sprint!!
不過照我們公司來經驗來看，你自己說敏捷run得很好，別人是不會相信的...
所以，要準備很多資料，才會讓長官覺得很厲害~
原本敏捷對於這些專案執行過程中的資料搜集方式，沒有一定的作法，
若真的要認真搜集這些資料，也不是不行，
只是希望大家不要只是做得好像敏捷，實質上一點都不敏捷。
佛心的免費Gitlab平台
我們選擇了Gitlab來做為溝通平台，它免費又提供多樣化功能，能結合Git做版控到整個Devops流程，
不過這部分我們完全沒使用到 XDDDD
團隊現在使用的是svn，CI也建置了Jenkins和其他套件功能，
現有交付流程也有諸多限制(包含資安掃描、稽核等關卡一定要簽名佐證文件)，
所以暫不考慮整個移植到Gitlab來處理。
我們看上的是Gitlab提供彈性的issue功能，以及搭配其Labels，能作為Scrum Board的特性，
又能做工時預估與花費的統計，資訊的記錄與呈現都能支援，而成為了我們的選擇方案。
不過免費版的功能有許多限制，像是一個issue只能同時有一位被指派者、只能有一個看板、不提供burndown chart...畢竟是免費的，只能接受它的不完美。
工時花費怎麼填!? 統計工時更讓人頭大!
Gitlab的每個issue的工時要各自進去下/spend指令來填寫，這其實還蠻擾人的，大家又要確保每天填滿8小時，每週40小時，
如果缺少了統計工時的功能，要每個issue都去累加才會知道自己填了多少小時，
這政策在試行之時，就受到不小的反彈，連我自己都覺得填這工時真的太痛苦啦~~
於是，我開始研究Gitlab提供的API(Gitlab API v4)，發現可以自行透過API來取得這些工時資訊，
就著手研發工時填寫和統計的功能，目前用到的Gitlab API功能有members、issues、notes和events。
工時填寫功能
填寫工時要先選擇要填的issue，程式針對open的issue做篩選，然後同事找了幾種篩選的方式：
- 選擇含有指定的Label的issue
- 被指派給自己的issue
- 自己按過讚的issue
為了怕大家填錯，加了正規表示式來做防呆。
/^((-?\d+(\.?\d+)*[mhdw])|(-?\d+(\.?\d+)*))?(\s?\d+(\.?\d+)*[mhdw])*$/ig- 開頭可以有負號(-)
- 數字+mhdw 這四個其一，代表分鐘、小時、日、週
- 也可數字不帶單位，預設是小時
- 多種單位混打時，數字都要帶單位才行
在Gitlab上送出工時，是下/spend指令，會在issue中增加一個note。
一開始注意到issue中有一個API是add_spent_time，但這個指令不能指定日期，只會填當日，變得很不實用。
繼續研究note的API，我們利用了Create new issue note在body參數中直接送/spend這類的指令，也支援指定created_at的日期，要注意先將/做html encoding後才能送出post。
最後發現，這個create note的api現存一個bug，當note是純下指令的時候，都會回傳400 bad reqeust...所以後來我只好在回傳fail時，判斷訊息內容決定是否成功，但這個寫法不是很準確，之後Gitlab會修正這個問題。
工時統計功能
一開始的想法，是透過events去撈取target_type=note的create記錄，來判斷指定的author取出相關的issue，但後來發現/spend指令的note不會被event的api撈出來而作罷。後來只好改抓target_type=issue的create記錄(直接撈issue的資料會更多)，然後再用這些issue.iid，依序撈出issue中所有note的內容，再判斷內容為added或substracted開頭，就是工時填寫的記錄。
這作法的缺點就是會多次呼叫API，回傳的資料量也很大，執行效能不佳...
之後還在考慮效能如何改進，可能會從event去篩選還前後一個月open與close的issue，來減少撈到的issue數量；另外也可以做成第一次查詢後，把與查詢者相關的issue記錄下來，後續可直接更新這些相關issue資料的方式，來大幅減少API呼叫次數。
總結
這次在操作這些API的同時，也學習了一些API制定的原則，未來可以應用在自行研發的系統上。
很久沒開發Javascript的前端程式，對於語法和架構都有點陌生了，
接下來要思考將現有程式重構，並且套用適合的單元測試框架，
建置好用的IDE工具，讓這套程式後續仍好維護，
大家的工時才能填得安心，需求一直滾滾來，大家發大財! XD
留言
張貼留言