Rachel2022-08-12 来自日本为啥我感觉老师说的这个job模式的pipline和我们实际实施的持续交付的pipline一样呢？但是理论好像有差别，没太分辨清楚他们的关系作者回复: 是的。通过Job模型来梳理Pipeline。实际上Job模型是可以替代jenkins，cloudbee的！
羊羊2022-08-02 来自日本以前公司的CI流水线是3个团队共同完成的，每个团队负责一个大的Job，每个Job通过rest api来通信。一个Job完成之后，会通过rest api发送下一个job需要的信息，来激活下流job。但是实践中，总是会遇到各种问题，使pipeline中断，希望老师能分享一些，能让pipeline更加稳定的经验。作者回复: “下流job”应该是“下游job”，是吧😄 增强automation健壮性的一般性办法有 1. 加入re run机制，这个你可以参考jdbc connection的机制。一次出错没关系，可以retry多次，直到超过max number 2. 分析常见错误原因，调整参数。比如实例比较慢，可以调大time out。如果是测试账号失效，可以run time创建测试账号。 如果确实是间歇性失败。。。。。那就提交bug，让开发人员修改吧。😂
孙中原2022-07-27 来自日本感谢老师的分享。这里我有一个问题，像我们这边设计ci pipeline的时候，是以制品的视角来设计，描述了一个制品从被开发者提交到最终上线，质量等级不断提升的过程。您的Job设计，是以需求的角度来设计的。那么，Job树怎么与CI pipeline结合呢？作者回复: job树是自动化测试设计的一种建模方式，CI pipeline本身也是自动化。如果是全新的pipeline设计，不妨用Job模型来完成；如果是和已存的pipeline集成，那就是接口对接了。我们微信上加了，是吧，微信上细聊你的场景。
swordman2022-06-22原先我们jenkins pipeline的设计比较low，直接在绘图工具或纸上，绘制stage，然后就开工写代码了。当pipeline脚本越来越多，参与编写的人也越来越多时，脚本非常难维护，也很难做Review，这估计就是没有设计带来的“附属品”。 今天终于知道pipeline的设计方法了，可以解决以上的痛点，接下来，就是将它用于实践！作者回复: 谢谢分享！ Job模型就是为了帮助理清思路，做好设计！
。。。2022-05-09这个git地址登不进去呀作者回复: 如果你指的是example git的地址，抱歉，它是mock的。 本专栏唯一Github地址 https://github.com/sheng-geek-zhuanlan