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

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

假如把开发工作流程分为以下几个阶段:

编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署

正如你在上图中看到,「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」有着不同的软件自动化交付周期。

持续集成

持续集成是指软件个人研发的部分向软件整体部分交付,频繁进行集成以便更快地发现其中的错误。“持续集成”源自于极限编程(XP),是 XP 最初的 12 种实践之一。

CI 需要具备这些:

  • 全面的自动化测试。这是实践持续集成&持续部署的基础,同时,选择合适的自动化测试工具也极其重要;
  • 灵活的基础设施。容器,虚拟机的存在让开发人员和 QA 人员不必再大费周折;
  • 版本控制工具。如 Git,CVS,SVN 等;
  • 自动化的构建和软件发布流程的工具,如 Jenkins,flow.ci;
  • 反馈机制。如构建/测试的失败,可以快速地反馈到相关负责人,以尽快解决达到一个更稳定的版本。

持续集成的优点

  • “快速失败”,在对产品没有风险的情况下进行测试,并快速响应;
  • 最大限度地减少风险,降低修复错误代码的成本;
  • 将重复性的手工流程自动化,让工程师更加专注于代码;
  • 保持频繁部署,快速生成可部署的软件;
  • 提高项目的能见度,方便团队成员了解项目的进度和成熟度;
  • 增强开发人员对软件产品的信心,帮助建立更好的工程师文化。

持续集成,该从何入手

最重要的一环是选择合适的持续集成系统。是搭建私有部署还是选择托管型持续集成系统,关键在于团队运行的基础设施,团队对持续集成系统的资源投入力度。

对比一下私有部署和托管型持续集成系统,或许能帮助你更好地做出选择。

  • Self Hosted CI 指的是将软件部署在公司的机房或内网中,需要提供多台服务器来完成 CI 系统的运转,同时需要对不同机器之间进行环境配置。比如Maven 或 Gradle 或 Jenkins ,他们的特点是自由开源,且文档支持广泛。优点在于对构建环境有完全的控制权,能够实现完全定制。但需要搭建环境和配置、维护成本高,需要买专门的机器,花费较多人力物力且更新迁移风险高;
  • Hosted CI 指的是由 SaaS 型的 CI 服务,全程在线进行构建配置,不需要考虑装机器,装软件,环境搭建等成本。常见的有 CircleCI,Codeship 和 TravisCI 等,还有国内最新的持续集成服务——flow.ci 。SaaS 型的 CI 的特点在于无需额外机器,几分钟就可以用起来。可以根据你的需要动态调度资源。省时,省心,省力。

整体而言,Jenkins 过去一直是大部分公司的选择,但这个现象正在发生改变,随着公有云服务、Docker,SaaS 的普及,越来越多的企业开始选择 Hosted CI,也就是托管型持续集成系统。

另外,在选择合适的持续集成服务时,还需要考量系统的灵活度以适应公司不同阶段的开发测试需求。

选择持续集成系统只是持续集成应用的其中一步,还需要建立合适的持续集成文化比如代码质量管控、测试文化等。做好持续集成,可为持续交付与持续部署打好坚实基础。

持续交付

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

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

持续交付的好处

持续交付和持续集成的优点非常相似:

  • 快速发布。能够应对业务需求,并更快地实现软件价值。
  • 编码->测试->上线->交付的频繁迭代周期缩短,同时获得迅速反馈;
  • 高质量的软件发布标准。整个交付过程标准化、可重复、可靠,
  • 整个交付过程进度可视化,方便团队人员了解项目成熟度;
  • 更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作,相比于传统的瀑布式软件团队,更少浪费。

持续部署

持续部署是指当交付的代码通过评审之后,自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着,所有通过了一系列的自动化测试的改动都将自动部署到生产环境。它也可以被称为“Continuous Release”。

为什么说持续部署是理想的工作流程?

“开发人员提交代码,持续集成服务器获取代码,执行单元测试,根据测试结果决定是否部署到预演环境,如果成功部署到预演环境,进行整体验收测试,如果测试通过,自动部署到产品环境,全程自动化高效运转。”

实际上,产品在从需求到部署的过程中,会经历若干种不同的环境,例如 QA 环境、各种自动化测试运行环境、生产环境等。这些环境的搭建、配置、管理,产品在不同环 境中的具体部署,状况是比较非常复杂的,从头到尾地全自动持续部署的确困难。那么,如果能做到持续交付,保证代码在模拟环境没问题,也许团队成员做到真正的心理有数。

持续部署的优点

持续部署主要好处是,可以相对独立地部署新的功能,并能快速地收集真实用户的反馈。

“You build it, you run it”,这是 Amazon 一年可以完成 5000 万次部署,平均每个工程师每天部署超过 50 次的核心秘籍。

最后

「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」提供了一个优秀的 DevOps 环境,对于整个团队来说,好处与挑战并行。无论如何,频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。

作者:firim

来源:51CTO

时间: 2024-08-17 14:02:35

谈谈持续集成,持续交付,持续部署之间的区别的相关文章

使用Jenkins、Docker和Ansible进行持续集成和交付

本文讲的是使用Jenkins.Docker和Ansible进行持续集成和交付,[编者的话]本文介绍了使用Docker.Jenkins等技术实现应用开发,测试到部署的自动化.它是一种探索.重点在于流程中的代码检测.测试.部署.部署后要做的事情没有涉及.会在后面文章中介绍. 本文试图为您介绍一个设置持续集成.交付.部署工作流的可行方式.我会使用Jenkins.Docker.Ansible和Vagrant来设置(配置)两个服务器.一个作为Jenkins的服务器,另一个用来模拟生产环境.前者用来检查代码

持续集成篇 --Hudson持续集成服务器的安装配置与使用

IP:192.168.4.221  8G内存(Hudson多个工程在同时构建的情况下比较耗内存) 环境:CentOS 6.6.JDK7 Hudson不需要用到数据库   Hudson只是一个持续集成服务器(持续集成工具),要想搭建一套完整的持续集成管理平台,还需要用到前面课程中所讲到的SVN.Maven.Sonar等工具,按需求整合则可. 1.  安装JDK并配置环境变量(略) JAVA_HOME=/usr/local/java/jdk1.7.0_72   2.  Maven本地仓库的安装(使用

让IT跟上业务思考的速度--从持续集成到持续交付

通过 7 个持续交付最佳实践,给读者一个思路,无论是建设持续交付能力,还是在进行持续交付平台的选型,都能够在业界经验的基础上走向更为正确的道路.同时,本文还引入了持续交付成熟度模型,目的是想帮助企业,把一个想象中全面而复杂的交付流程进行切分,按照环节和成熟度等级展现,将实现持续交付能力之路变得更为清晰.更可操作.有助于企业建立良好的期望和愿景,并开展切实可行的行动. 市场和业务瞬息万变,企业的 IT 部门必须面对产品上线周期不断变短的事实,也就是说,需要建立产品交付反馈圈,并让这个闭环圈的反馈速

基于容器服务的持续集成与云端交付(五)- 探究持续交付系统的本质

换个角度看持续交付 在<基于容器服务的持续集成与云端交付>系列中,我们已经讨论了持续集成与持续交付给软件开发带来的变革,介绍了如何从零搭建一个持续交付系统以及在阿里云上面如何实现持续交付. 不过,在这篇文章中,我们会用一个不一样的角度来思考持续交付,到底持续交付给我们带来了什么,在容器的持续交付的场景中还缺少什么.回到本系列第一篇文章中的容器持续交付的流程图: 这张图中描述了一个基于容器的持续交付的流程,它定义了几个阶段,本地开发阶段.持续集成阶段.持续交付阶段等等,规定了在每个阶段中该做什么

使用 Subversion、Hudson 和 Eclipse 构建持续集成系统

持续集成系统简介 持续集成系统是指持续地编译.测试.检查和部署源代码的系统. Martin Fowler 对 持续集成是这样定义的 : 持续集成是一种软件开发实践,团队开发成员经常集成它们的工作,通常每个成员每天可 能会发生多次集成.每次集成都通过自动化的构建(包括编译.发布.自动化测试)来验证,从而尽快地发现集成错误.这 个过程可以大大减少集成的问题,从而让团队能够更快的开发内聚的软件. 持续集成有以下几个特点和要求: 有统一的源代码库. 开发人员基于同一个源代码库进行开发是进行持续集成的一个

Jenkins与Docker的持续集成实践

本文讲的是Jenkins与Docker的持续集成实践[编者的话]持续集成(CI/CD)是一种软件开发实践.用于帮助团队成员频繁.快速的集成,测试他们的工作成果,以尽快发现集成错误. 更频繁.更早的集成意味着更早的发现问题.通过持续集成,及时发现和解决代码故障,提高代码质量,减少故障处理成本等等. [3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站]本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览:持续集成系统介绍:客户端与服务端的

以review 系统为核心的新一代持续集成

传统的持续集成(CI)系统被设计成作业的流水线.你可以有一个同行评审,然后开始构建作业,然后是单元测试作业,然后是集成测试作业,然后是性能测试作业,诸如此类. 每个作业都是由前一个作业的成功完成事件触发的,而第一个作业则是由版本控制系统中源代码文件的变更事件来触发的.当然,如果你的目标是多个二进制平台,或者如果你正在构建的是一组组件,以此来测试整个的应用程序,那么它还会更加的复杂. 那么如果有任务失败了会怎样?Jez Humble 和 David Farley 在持续交付中认为,你首先需要遵循这

Jenkins+Ant+Jmeter搭建持续集成的接口测试平台

一.什么是接口测试? 接口测试是测试系统组件间接口的一种测试.接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点.测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等. 接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统,主要测试这些系统对外部提供的接口,验证其正确性和稳定性.接口测试同样适用于一个上层系统中的服务层接口,越往上层,其测试的难度越大. 接口测试实施在多系统多平台的构架下,有着极为高效的成本收益比,接口测试天生为高复杂性的平台

如何破局CI工具拉锯战:探寻中小企业的持续集成之路

摘要:随着持续集成技术的不断成熟,各种持续集成相关的开源和商用软件层出不穷,但是对于中小型企业的技术团队而言,往往在进行持续集成实践时会陷入工具之间的拉锯战.那么,对于中小团队而言,如何才能实现高效敏捷的持续集成方案?2017苏州云栖大会云效专场上,南京路特CTO.阿里云MVP戚俊结合实践经验为大家分享了中小团队持续集成之路. 以下内容根据演讲视频以及PPT整理而成. 虽然持续集成的概念已经火了很长时间了,但是因为各个企业的规模以及业务类型都不同,所以在持续集成中遇到的问题也各不相同.本次将结合