谈谈持续集成持续交付持续部署

Posted 田攀

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了谈谈持续集成持续交付持续部署相关的知识,希望对你有一定的参考价值。

经常会听到持续集成,持续交付,持续部署,三者究竟是什么,有何联系和区别呢?什么是“持续”?

所谓的持续,就是说每完成一个完整的部分,就向下个环节交付,发现问题可以马上调整。是的问题不会放大到其他部分和后面的环节。

这种做法的核心思想在于:既然事实上难以做到事先完全了解完整的、正确的需求,那么就干脆一小块一小块的做,并且加快交付的速度和频率,使得交付物尽早在下个环节得到验证。早发现问题早返工。

假如把开发工作流程分为以下几个阶段:编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署

 

The Product Managers' Guide to Continuous Delivery and DevOps 文中对「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」这三个概念有很详细的解释。

 

持续集成

持续集成指的是,频繁地(一天多次)将代码集成到主干。强调开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。

好处在于: 快速发现错误。每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易。

持续集成的目的,就是让产品可以快速迭代,同时还能保持高质量。它的核心措施是,代码集成到主干之前,必须通过自动化测试。只要有一个测试用例失败,就不能集成。

 

Martin Fowler说过,"持续集成并不能消除Bug,而是让它们非常容易发现和改正。"

 

持续交付

持续交付(Continuous delivery)指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。

持续交付可以看作持续集成的下一步。它强调的是,不管怎么更新,软件是随时随地可以交付的。

 

持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题,可以继续手动部署到生产环境中。

持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。持续交付优先于整个产品生命周期的软件部署,建立在高水平自动化持续集成之上。

试想想,如果说等到所有东西都完成了才向下个环节交付,导致所有的问题在最后爆发出来,解决成本巨大甚至无法解决。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中进行更多的自动化测试。如果代码没有问题,可以继续手动部署到生产环境中。当然,持续交付并不是指软件每一个改动都要尽快部署到产品环境中,它指的是任何的代码修改都可以在任何时候实施部署。

持续部署

持续部署(continuous deployment)是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境。

持续部署的目标是,代码在任何时刻都是可部署的,可以进入生产阶段。

持续部署则是在持续交付的基础上,把部署到生产环境的过程自动化。

持续集成、持续交付、持续部署恰恰可以早发现早解决,从而可以避免这个问题。

 

 

参考

如何理解持续集成、持续交付、持续部署?

The Product Managers’ Guide to Continuous Delivery and DevOps

持续集成是什么?

谈谈持续集成,持续交付,持续部署之间的区别

 

 

以上是关于谈谈持续集成持续交付持续部署的主要内容,如果未能解决你的问题,请参考以下文章

持续集成,持续交付,持续部署

持续集成+持续交付+持续部署

持续集成 vs. 持续交付 vs. 持续部署

OpenShift中的持续交付

CI / CD /CD 持续集成 持续交付 持续部署

持续集成:什么是持续集成(CI)持续交付(CD)和持续部署(CD)