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

Question

这三个术语有什么区别？我的大学提供以下定义:

持续集成基本上只意味着开发人员的工作副本每天都会与共享主线同步几次.

持续交付被描述为持续集成的逻辑演变:始终能够将产品投入生产!

持续部署被描述为持续交付后的逻辑下一步:每当通过QA时自动将产品部署到生产中!

它们还提供警告:如果您能够连续部署到测试系统,有时也会使用术语"持续部署".

所有这些让我感到困惑.任何更详细的解释(或附带一个例子)是值得赞赏的!

Answer 1

持续集成

我同意你大学的定义.持续集成是开发人员如何持续地将代码集成到主线的策略 - 而不是经常.

您可能会声称它只是您的版本控制系统中的分支策略.

它与您分配给开发人员的任务的大小有关; 如果一项任务估计需要4-5个人日,那么开发人员将不会煽动在接下来的4-5天内提供任何东西,因为他还没有做任何事情 - 但是.

因此大小很重要:

small task = continuous integration
big task   = frequent integration

理想的任务规模不超过一天的工作量.这样开发人员每天至少会有一次集成.

持续交付

持续交付中基本上有三所学校:

持续交付是持续集成的自然延伸

这所学校,看看Addison-Wesley"Martin Fowler"签名系列,并假设自2007年发布以来被称为"持续集成",而2011年之后被称为"持续交付",它们可能是第1 + 2卷那有连续做同样的概念想法的东西.

持续交付与敏捷软件开发有关

这所学校的观点是,持续交付的全部意义在于能够支持敏捷运动中的原则,不仅仅是作为一个概念性的想法或一个意向书,而是为了真实 - 在现实生活中.

在敏捷宣言中采用第一原则的偏移,其中"连续交付"一词实际上是第一次使用:

我们的首要任务是通过尽早和持续交付有价值的软件来满足客户.

该学校声称"持续交付"是一种范例,包含实施"完成定义"自动验证所需的一切.

这所学校接受"持续交付"和流行词或大趋势"DevOps"是同一枚硬币的翻转面,因为它们都试图接受或封装这种新的范例或方法,而不仅仅是一种技术.

持续交付是持续部署的同义词

第三所学校主张持续部署和持续交付可以互换使用,意思相同.

当某些东西在开发人员手中准备就绪时,它会立即传递给最终用户,这在大多数情况下意味着它应该部署到生产环境中.因此,"部署"和"交付"意味着相同.

哪所学校加入

你的大学明显加入了第一所学校,声称我们指的是同一出版物系列的第1 + 2卷.我的观点是,这是滥用持续交付这一术语.

我个人主张理解,持续交付与实现对敏捷运动所提出的想法和概念的现实支持有关.所以我加入了学校,说这个术语包含了一个完整的范例 - 比如"DevOps".

使用交付作为部署同义词的学校主要由创建部署控制台的工具供应商提倡,试图从更广泛使用术语持续交付中获得一些宣传.

持续部署

对持续部署的关注主要与最终用户访问软件更新依赖于此信息的某些集中源更新以及此集中源不易更新的域相关,因为它是单片或具有(太高)一致性本质上(网络,SOA,数据库等).

对于许多生成软件的域,其中没有集中的信息源(设备,消费者产品,客户端安装等)或者集中的信息源易于更新(应用程序存储工件管理系统,开源存储库等). ),几乎没有关于"持续部署"一词的炒作.他们只是部署; 这不是一件大事 - 这不是需要特别关注的痛苦.

持续部署不是每个人都普遍感兴趣的事实也是一个论点,即声称"交付"和"部署"是同义词的学校都错了.因为持续交付实际上对每个人都非常有意义 - 即使您在设备中进行嵌入式软件或为框架发布开源插件.

您的大学定义持续部署是持续交付的自然下一步隐含地假设每个QA的交付应该立即可供最终用户使用,更接近我的部落用来描述术语"连续"的定义发布",反过来,这是另一个概念,通常不会对每个人都有意义.

发布可能是一个非常具有战略性或政治性的事情,并且没有理由假设每个人都希望一直这样做(除非他们是在线书店是一种流媒体服务类型的公司).尽管如此,那些不会盲目地一直发布所有内容的公司可能有许多原因,他们无论如何都希望成为部署的主人,所以他们也做了持续部署.不是发布到生产,而是发布候选者到生产环境.

我再次相信你的大学弄错了.他们误以为"持续发布"的"持续部署".

持续部署只是持续能够将开发过程的结果转移到类似生产环境的学科,其中功能测试可以全面执行.

持续交付故事情节

在图片中,一切都活跃起来:

持续集成过程是状态转换图中的前两个操作.哪 - 如果成功 - 启动实现完成定义的Continuous Delivery管道.部署只是必须在此管道中持续完成的众多操作之一.理想情况下,从开发人员提交到VCS的位置到管道确认我们拥有有效的候选发布版本的点,该过程是自动进行的.

Answer 2

问题和答案都不符合我的简单思考方式.我是一名顾问,并将这些定义与许多Dev团队和DevOps人员进行了同步,但我很好奇它与整个行业的匹配程度:

基本上我认为连续交付的敏捷实践就像一个连续统一体:

不连续(一切手动)0%----> 100%持续交付价值(一切自动化)

持续交付的步骤:

零.开发人员检查代码时没有什么是自动化的......如果他们在办理登机手续之前编译,运行或执行任何测试,那么你很幸运.

1. 持续构建:在每次签入时自动构建,这是第一步,但无法证明新代码的功能集成.

2. 持续集成(CI):自动构建和执行至少单元测试,以证明新代码与现有代码的集成,但最好是集成测试(端到端).

3. 持续部署(CD):当代码至少将CI传递到测试环境时自动部署,当通过CI或通过在手动测试后将较低环境标记为PASSED来证明质量时,优选地进入更高环境.IE,在某些情况下测试可能是手动的,但是自动升级到下一个环境.

4. 持续交付:自动发布并将系统发布到生产中.这是CD投入生产以及任何其他配置更改,如A/B测试设置,向用户通知新功能,通知支持新版本和更改注释等.

编辑:我想指出,敏捷宣言的第一个原则(http://agilemanifesto.org/principles.html)和持续交付的实践中提到的"持续交付"概念之间存在差异,似乎是问题的上下文引用.持续交付的原则是努力减少库存浪费,如精益思想(http://www.miconleansixsigma.com/8-wastes.html)中所述.自敏捷宣言于2001年编写以来,灵活团队持续交付(CD)的实践已经出现多年.这种敏捷实践直接解决了这一原则,尽管它们是不同的东西,显然很容易混淆.

Answer 3

我认为亚马逊的定义很简单易懂.

" 持续交付是一种软件开发方法,其中发布过程是自动化的.每个软件更改都会自动构建,测试并部署到生产中.在最终推向生产之前,人员,自动化测试或业务规则决定何时应该进行最终推送.虽然每次成功的软件更改都可以通过持续交付立即发布到生产中,但并不是所有的更改都需要立即发布.

持续集成是一种软件开发实践,团队成员使用版本控制系统并将其工作频繁地集成到同一位置,例如主分支.每个更改都通过测试和其他验证进行构建和验证,以便尽快检测到任何集成错误.与持续交付相比,持续集成专注于自动构建和测试代码,从而使整个软件发布流程自动化直至生产.

请查看http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html

Answer 4

Atlassian发布了关于持续集成与持续交付与持续部署的良好解释.

简而言之:

持续集成 - 每当新提交被推入分支时,都是自动构建和测试应用程序.

持续交付 - 持续集成 +通过"单击按钮"将应用程序部署到生产中(通常是按需发布给客户).

持续部署 - 持续交付,但无需人工干预(正在向客户发布).

Answer 5

持续集成基本上只意味着开发人员的工作副本每天都会与共享主线同步几次.

或者每天多次.基本上,任何给定的离散任务都经常完成.例如,考虑一个开发人员在一个业务应用程序上工作.在许多环境中,可能会发生以下情况:

• 一两个开发人员在几天内保持本地更改,因为"它还没有准备好".
• 一个或两个开发人员在源代码管理中创建分支,以便他们可以"处理他们的功能",而不会被其他人的更改所困扰.

这些可能会导致问题.糟糕的代码/任务组织导致分支,分支导致合并,合并......导致痛苦.持续集成作为一种实践通过鼓励每个人使用相同的共享源来解决这个问题.个别工作项应足够离散,以便在短时间内完成(最多几小时).

基本上,一般的想法是在少量工作中集成一个小的变化.整合大的变化是一项不成比例的大量工作.如果以恒定的小步骤完成,集成工作的总量会更小.这使开发人员可以将更多时间用于业务可见功能而不是开发流程开销.

持续交付被描述为持续集成的逻辑演变:始终能够将产品投入生产!

这遵循离散的,明确定义的工作项的相同想法.如果只有一个主代码库只能通过完整,经过测试的已知工作特性以较小的增量进行调整,那么该代码库始终是稳定的.自动测试是关键,能够通过按下按钮来证明稳定性.

需要完成的稳定工作越少(同样,开发过程开销并且应该被消除),代码库可以更频繁地推送到任何给定的环境.在许多公司中,部署可能是一个非常艰苦的过程.即使是为期一周的全副手操作.这很昂贵,没有商业价值.通过采用良好的工作项定义,有效的自动化测试和持续集成,团队可以自动执行代码库到任何给定环境的交付.

持续部署被描述为持续交付后的逻辑下一步:每当通过QA时自动将产品部署到生产中!

你很少会在商业环境中看到这种情况,遇到它时会非常高兴.如果代码库可以自动测试并自动部署到任何给定的环境,那么,生产就像任何其他环境一样.因此,如果团队已经建立起来,那么通过始终能够将更新部署到生产中,可以为业务带来巨大的价值.

缺陷修复程序更快地发送给客户,新功能更快地到达市场,新的想法以较小的增量对市场进行测试,以允许重定向优先级等.

例如,假设一家公司对其基于软件的产品或服务中的新功能有一个很大的想法.他们已经做了一些研究,他们了解市场,他们相信这个想法将带来强劲的新收入.现在考虑提供该功能的两个选项:

1. 花几个月在一次性分支中开发整个事物.花几周时间将它集成到主代码库中.花几天时间测试一下.花一天时间部署它.而且,只有然后开始在生产系统中跟踪的实际收入.
2. 一次一个地实现该功能的一小部分.每周发布一个新的部分.每周获得更多实际收入数据.

在第一种情况下,如果该功能没有达到预期的市场效果,那么很多钱就会浪费在客户实际上并不想要的东西上.在第二种情况下,客户不想要它的事实很早就确定了,而其余的工作都被排除在优先级之外.

最终,这些"连续的事物"都是为了消除开发过程的开销.如果公司的收入来源是特定的服务产品,那么理想情况下,他们的所有成本都应该用于该产品.开发流程开销(合并代码,在合并后重新测试相同的功能,手动部署任务等)实际上并没有贡献服务的价值,因此这些概念试图从流程中消除这些成本.

Answer 6

一个图可以替换许多单词:

请享用!:-)

#我已经更新了正确的图片......

Answer 7

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