我会这麽做： 每天 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://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1441196619.A.CE9.html