作者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/cn.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