几个持续的区别:持续集成、持续部署、持续交付、持续发布
内外部都有很多人写,自己写篇博客,方便查找。图片就不贴了,如下链接里面基本上都有图片。
3ms搜了几篇:
外部的内容:
有篇Crisp公司人员的博文,约等于Jez文章的简化版,比对蛮清楚的:Continuous Delivery vs Continuous Deployment
《持续交付》作者Jez Humble自己介绍持续部署、持续交付的区别:Continuous Delivery vs Continuous Deployment
简单来说:
持续:就是一直在运行,随时可以发生,也是因为此,我并不认为例如每日构建(Daily Build)是持续,因为它是受控的(每日);
持续集成(Integration):从提交代码到传统的集成测试这个阶段,敏捷环境下我认为是从提交代码到代码编译完成、单元测试完成,没有严格意义上的集成测试;
持续交付(Delivery):从提交代码到传统的用户验收测试这个阶段,但是因为敏捷测试不同于传统测试理念的测试层级/阶段划分,持续交付实际上是到敏捷测试方法里面的“接收测试”为止(Acceptance Test,与传统的UAT不同,可以参考文章“《Scrum精髓》审校后记:关于Acceptance Test”以及敏捷测试四象限),这个过程是全自动的;从Jez自己的描述来看,至此再往后到“部署至生产环境”这个环节之间,是自动还是手动,就是持续交付和持续部署的关键区别;更像是一个研发决策或研发能力;
持续部署(Deployment):从提交代码到部署至生产环境这个阶段,全部自动化;也即是说持续交付与持续部署的区别,就在于“接收测试”之后,持续交付是需要由业务人员来人工确认并操作“部署至生产环境”的,而持续部署是只要“接收测试”通过就直接自动走到了“部署到生产环境”环节,就这么个区别;我觉得更像是一个运维决策;
持续发布(Release):从提交代码到用户可见/可用这个阶段,也即是说,持续部署是将可用的软件部署在厂商的机器上了,但是这个软件/服务并没有暴露给用户可以去访问和使用,有点蓝绿部署、灰度发布的那种味道,就像是随身带着钱包随时可以用、但没必要带着就非得掏出来;我觉得更像是一个业务决策;
欢迎交流探讨。
- 点赞
- 收藏
- 关注作者
评论(0)