作者dream1124 (全新開始)
看板Soft_Job
標題[請益] 工作流程結合 pull-request 與持續整合
時間Wed Sep 2 19:39:30 2015
大家晚安
小弟我最近為了規劃結合 ci server (jenkins) 與 git server (Atlassain stash)
的提交流程而傷腦筋,想到的流程各有優劣與耽心的事,不知道該向上級提出什麼
建議才好....
這讓我想請問大家的團隊都是怎麼結合 ci 與 git 的?
各提交流程又會有什麼問題,請問大家方便分享一下嗎?
現在我想到提交到 dev 分支的工作流程有兩種︰
1. 開發者提交新分支 (feature branch, fb) 到 stash 伺服器
-> feature branch post receive hook 觸發 jenkins 自動建置新分支
-> 開發者 pull-request(pr) dev
-> pull-request 觸發 ci merge build
-> 回寫結果到 stash pull-request
-> 審核建置結果和 code review 提交項目
-> 人工按下 merge 按鈕合併修正至目標分支(dev)
-> dev 分支 post-receive hook 觸發自動建置
-> jenkins 回報 dev 分支的整合結果到 stash
這開發方案的優點是已經有現成 jenkins 和 stash 的擴充套件支援,
缺點是我耽心整合的次數會否太頻繁?
現成 webhook 套件在 fb 提交的時候會建置一次,pr 產生的時候針對 fb
再觸發一次,人工 merge 完成後,dev 的變化又會再觸發一次。
要是 pr 還沒結束的時候 dev 產生變化,所有未結束的 pr 分別都會觸發建置,
這樣團隊只要頻繁提交,整合伺服器的負擔或許就很重
2. 開發者提交新分支 (feature branch) 到 stash 伺服器
-> feature branch post receive hook 觸發 jenkins 自動建置新分支
-> 開發者 pull-request dev
-> 審核者直接 code-review 提交項目
-> 若審核通過,則手動按下建置按鈕,觸發 jenkins merge build,
與第 1. 項不同的是建置成功會由 jenkins 提交 merge commit 至 dev 分支
-> jenkins 回報前一步的整合與提交結果到 stash
這個方案的特色/優點是提交 fb 至 dev 的動作由 jenkins 執行,
理論上提交到 dev 的程式碼必定能建置且通過測試,不用執行很多次建置,
而且我們可以在這個步驟安插自動化的企業流程,我跟上級比較喜歡這方案。
但問題是我耽心多個 pull-request 在差不多的時間批准時,
jenkins 可能會有多個整合任務同時執行,即使建置結果正常的程式碼也可能會
因為有其他 merge commit 先提交而造成 non-fast-forward 無法提交,
而且奇怪的是.... 現在的套件幾乎都不太支援這種持續整合做法,
我是第一次實現持續整合系統,不知道為什麼會這樣....
最後,再怎麼強的系統都很難避免意外,這兩種方法在網路上都沒找到 dev 發生錯誤
的回溯方式,讓我很想知道當 dev 不幸出現無法編譯或是測試完全不合格的程式時,
各團隊都制定什麼方法和流程在第一時間回復這種錯誤呢?
是等開發者 revert commit 或修改完錯誤再申請 pull-request 送上去嗎?
還是該不會每人都能強迫取代舊分支吧? 這樣好像很危險
請問大家方便幫忙看一下以上兩種方案可行嗎?
會不會有什麼潛在問題呢? 還是有什麼改良方案可以請分享一下嗎?
謝謝
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.231.187.216
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1441193972.A.6B0.html
1F:推 Wolfken: Jenkins可以設成同時只有一個build在跑,如果有多個一起 09/02 22:33
2F:→ Wolfken: 來,就排隊,如果build fail就直接停掉 09/02 22:33
3F:推 ga009900: 關於第一點,我們目前只有 PR 當下進行 dev merge build 09/03 23:04
4F:→ ga009900: 人工code review且merge後,會自動發佈至測試機 09/03 23:06
5F:→ ga009900: 如果建置或發佈失敗會寄信通知,再去看哪邊被搞壞了 09/03 23:08