我會這麼做：
每天 Jenkins 自動 by 日期開一新 local branch
feature branch post receive hook 觸發 jenkins "記下該版本"
-> 每隔一定時間 (如 3 小時) Jenkins 將該 N 版 merge 到該新分支
-> Jenkins build
--> 過 -> notify 人去 code review merge 過的東西
--> 不過 -> notify 人去 debug
-> 每日到一特定時間點 (如下午六點) 將該新分支 merge 到 dev
可自動可人工，自動的話就是如有問題人要把 job 停掉
過該時間之後記的版本都排去下一個上班日
雖然比每一版跑一次比較不細，
不過幾小時前寫的應該還能容易的 debug，
loading 也固定，
也不用怕爛掉要回復反正是爛 local branch
一定要能建置能跑才會弄回 dev / master
如果一定要一版跑一次，
個人會建議方案一然後加機器做 Jenkins Master/Slave，
給 Jenkins Merge dev 感覺好恐怖...
是說好像沒看到 test 的部份？是包含在建置裡還是略過...
※ 引述《dream1124 (全新開始)》之銘言：
: 大家晚安
: 小弟我最近為了規劃結合 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), 來自: 36.226.185.68
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1441196619.A.CE9.html