持续集成与持续交付与持续部署
这三个词有什么区别？ 我的大学提供了以下定义：
持续集成基本上只是意味着开发人员的工作副本每天几次与共享主线同步。
持续交付被描述为持续集成的逻辑演进：始终能够将产品投入生产！
连续部署被描述为持续交付后的合理下一步：在产品通过QA时自动将产品部署到生产环境中！
他们还提供了一个警告：如果您能够连续部署到testing系统，有时候也会使用术语“连续部署”。
所有这些让我感到困惑。 任何解释更详细一点（或带有一个例子）赞赏！
持续集成
我同意你们大学的定义。 持续集成是开发人员如何将代码连续集成到主线的策略，而不是频繁的。
您可能会声称这只是您的版本控制系统中的分支策略。
它与您分配给开发人员的任务大小有关。 如果一个任务估计需要4-5个人日，那么开发人员在未来4-5天内将不会煽动任何东西，因为他还没有做任何事情。
所以规模很重要：
small task = continuous integration big task = frequent integration 理想的任务规模并不比一天的工作大。 这样一个开发人员每天至less会有一次集成。
持续交付
持续交付基本上有三所学校 ：
持续交付是持续集成的自然延伸
这所学校看了Addison-Wesley“Martin Fowler”系列签名，并假定自2007年发布以来被称为“持续集成”，并且在2011年被称为“持续交付”，他们可能是第1 + 2卷与连续的事物有关的相同的概念性想法。
持续交付与敏捷软件开发有关
这所学校忽视了“持续交付”这个概念，即所有关于能够支持敏捷运动的原则，而不仅仅是一个概念性的想法或一个意向书，而是在现实生活中。
在敏捷宣言的第一个原则中，第一次实际使用了“持续交付”这个术语：
我们的首要任务是通过早期和持续交付有价值的软件来满足客户的需求。
这所学校声称“持续交付”是一个范例，涵盖了对“完成定义”进行自动validation所需的一切。
这所学校认为，“持续交付”和stream行词或大趋势“DevOps”是同一个硬币的另一面，因为它们都试图拥抱或封装这种新的范式或方法，而不仅仅是一种技术。
持续交付是持续部署的同义词
第三所学校提倡持续部署和持续交付可以互换使用，意味着同样的事情。
当开发人员掌握了某些东西时，它会立即交付给最终用户，这在大多数情况下意味着应该将其部署到生产环境中。 因此，“部署”和“交付”的意思是一样的。
哪个学校join
你的大学显然join了第一所学校，并声称我们指的是同一出版物系列的第1 + 2卷。 我的意见是这是滥用“持续交付”这个词。
我个人主张认识到“ 持续交付”与为敏捷运动所提出的观点和概念实施真实的支持有关。 所以我join了学校，说这个词包含了一个完整的范例 – 比如“DevOps”。
使用交付作为部署同义词的学校主要是由创build部署控制台的工具供应商提倡的，试图从“ 持续交付 ”这个术语的更广泛使用中获得一些炒作。
持续部署
持续部署的重点主要与最终用户访问软件更新所依赖的领域有关，因为这些信息的更新依赖于某些集中式源代码的更新，而且这种集中式源代码并不总是易于更新，因为它是单一的或者具有（太）相关性（networking，SOA，数据库等）。
对于没有集中信息源（设备，消费产品，客户端安装等）的软件或者信息的集中来源易于更新的应用程序（应用程序存储工件pipe理系统，开放源代码库等）的许多领域来说， ），关于“连续部署”这个词几乎没有任何宣传。 他们只是部署; 这不是一件大事 – 这不是一个需要特别关注的痛苦。
持续部署不是一般人都感兴趣的事实也是一个论点，即声称“交付”和“部署”是同义词的学校是错误的。 因为持续交付实际上对每个人都是非常有意义的，即使您正在设备中使用embedded式软件或为框架发布开源插件。
你们大学的定义是持续部署是持续交付的一个自然的下一个步骤，它隐含地认为每个交付的QA都应该立即提供给最终用户，这更接近我的部落用来描述术语“Continous释放“，而这又是另外一个对所有人都没有意义的概念。
发布可能是一个非常具有战略性或政治性的东西，没有任何理由认为每个人都希望一直这样做（除非他们是网上书店的stream式服务types的公司）。 尽pipe如此，那些始终不盲目释放所有东西的公司可能有许多原因，无论如何他们都想成为部署的主人，所以他们也要做连续部署 。 不是发布到产品，而是发布到生产环境。
我再次相信你的大学错了。 他们错误地认为“持续部署”是“持续释放”。
持续部署就是不断地将开发过程的结果转移到可以全面执行functiontesting的生产环境的规程。
连续交付故事情节
在图片中，这一切都是活生生的： CoDe的故事线http://web.archive.org/web/20160315190327/http://www.code-conf.com/osl15http://img.dovov.comcdstoryline.png
持续集成过程是状态转换图中的前两个动作。 如果成功的话，它将启动实现done定义的Continuous Deliverypipe道。 部署只是在这个pipe道中不得不连续完成的许多行动之一。 理想情况下，这个过程从开发人员提交到VCS的点到stream水线确认我们有一个有效的发布候选者的地方是自动的。
问题和答案都不符合我简单的思维方式。 我是一名顾问，已经将这些定义与许多Dev团队和DevOps人员进行了同步，但对于如何与整个行业相匹配感到好奇：
基本上我想到的是连续交付的敏捷实践：
不连续（一切手册）0％—-> 100％连续交付价值（全部自动化）
持续交付的步骤：
零。 当开发人员检入代码时，没有任何东西是自动的。如果他们在办理登机手续之前已经运行/执行过testing，那么你很幸运
-
持续构build：在每次登记时自动构build
-
持续集成（CI）：至less对unit testing进行自动化testing，以certificate新代码与现有代码的集成，但最好是集成testing（端到端）。
-
连续部署（CD）：当代码至less将CI传递到testing环境时，自动部署，当通过CIcertificate质量或在手动testing后将较低环境标记为PASSED时，自动部署到较高环境中。 IE，在某些情况下testing可能是手动的，但是推向下一个环境是自动的。
-
持续交付：将系统自动发布并发布到生产环境中。 这是生产中的CD加上任何其他configuration更改，如设置A / Btesting，向用户通知新function，通知支持新版本和更改注释等。
持续集成基本上只是意味着开发人员的工作副本每天几次与共享主线同步。
或每天多次。 基本上，任何给定的离散任务都经常完成。 考虑一个开发单一商业应用程序的团队。 在许多环境中，可能会发生以下情况：
- 一两个开发人员保留了几天的本地更改，因为“尚未准备好”。
- 一个或两个开发人员在源代码pipe理中创build分支，以便他们可以在不受其他人的变化困扰的情况下处理他们的function。
这些可能会导致问题。 糟糕的代码/任务组织导致分支，分支导致合并，合并…导致痛苦。 持续整合作为一种实践，通过鼓励每个人从同一个共享来源来解决这个问题。 个人工作项目应该足够分散，在短时间内完成（最多小时）。
基本上总的想法是在less量的工作中整合一点小小的变化。 整合一个巨大的变化是不成比例的大量工作。 如果以不变的小步骤完成，整合工作的总量就会减less。 这使得开发人员可以花更多的时间来处理业务可见的function，而不是开发过程的开销。
持续交付被描述为持续集成的逻辑演进：始终能够将产品投入生产！
这遵循了离散的，明确定义的工作项目的相同想法。 如果有一个主代码库只能通过完整，经过testing的已知工作特性以小增量进行调整，那么该代码库始终是稳定的。 自动化testing在这里能够certificate按下button时的稳定性。
需要完成的稳定工作越less（这同样是开发过程的开销，应该被消除），那么代码库就越能够被推到任何给定的环境。 在很多公司，部署可能是一个非常艰苦的过程。 即使是一个星期的全手动甲板操作。 这是昂贵的，没有商业价值。 通过使用良好的工作项目定义，有效的自动化testing和持续集成，团队可以将代码库的交付自动化到任何给定的环境。
连续部署被描述为持续交付后的合理下一步：在产品通过QA时自动将产品部署到生产环境中！
你很less会在商业环境中看到这种情况，遇到这种情况真是太高兴了。 如果代码库可以自动testing并自动部署到任何给定的环境，那么生产就像任何其他环境一样。 因此，如果团队已经build立起来，那么通过始终能够将更新部署到生产环境中，对于业务来说具有重大价值。
缺陷修复程序更快地发送给客户，新function更快地进入市场，新的想法以较小的增量对市场进行testing，以便重新定位优先级等。
例如，假设一家公司对其基于软件的产品或服务中的新function有很大的想法。 他们已经做了一些调查，他们知道市场，他们相信这个想法会带来一个强大的新的收入线。 现在考虑提供该function的两个选项：
- 花几个月在一个分支上开发整个事情。 花费数周将其整合回主代码库。 花费天testing它。 花一天时间来部署它。 然后才开始跟踪生产系统的实际收入。
- 一次一个实现小部分function。 每个星期都会发布一个新的。 每周获得更多的实际收入数据。
在第一种情况下，如果该function没有达到预期的市场效果，那么在客户实际上不需要的东西上浪费了大量的金钱。 在第二种情况下，客户不需要的事实是很早就确定的，而其余的工作则是非优先化的。
最终，这些“连续的事情”都是关于消除开发过程的开销。 如果一个公司的收入是一个特定的服务产品，那么理想的情况是所有的成本都应该投入到这个服务中。 开发过程开销（合并代码，合并后重新testing相同function，手动部署任务等）实际上并没有对服务的价值做出贡献，所以这些概念试图从stream程中去除这些成本。
我认为亚马逊的定义是直接和简单的理解。
“ 持续交付是一种软件开发方法，其发布过程是自动化的，每一次软件更改都会自动构build，testing并部署到生产环境中，在最终推向生产之前，人员，自动化testing或业务规则决定即使每次成功的软件更换都可以立即投入生产并持续交付，但并非所有变更都需要立即发布。
持续集成是一种软件开发实践，团队成员使用版本控制系统，并将他们的工作频繁地集成到同一位置，如主分支。 每次更改都通过testing和其他validation来构build和validation，以便尽快检测到任何集成错误。 与持续交付相比，持续集成专注于自动构build和testing代码，从而将整个软件发布过程自动化为生产 。“
请查看http://docs.aws.amazon.com/codepipeline/latest/userguide/concepts.html
一张图可以代替很多单词：
请享用… ：-）
＃ 我已经更新了正确的图片…
Atlassian发表了关于持续集成与连续交付与持续部署的很好的解释。
简而言之：
持续集成 – 每当新提交被推入分支时，自动构build和testing应用程序。
持续交付 – 持续集成 +通过“点击button”将应用程序部署到生产（向客户发布通常是按需提供的）。
持续部署 – 是持续交付，但没有人为干预（发布给客户正在进行中）。
我认为我们正在分析，也许使一些“连续”的单词变得复杂一些。 在这种情况下连续意味着自动化 对于“连续”的其他单词，请使用英文作为您的翻译指南，请不要使事情复杂化！ 在“连续构build”中，我们自动构build（编写/编译/链接/等）我们的应用程序到一个特定的平台/容器/运行时/等可执行的东西。 “持续集成”意味着您的新function在与其他实体交互时按照预期进行testing和执行。 显然，在集成发生之前，必须发生构build，并且还将使用全面的testing来validation集成。 因此，在“持续集成”中，人们使用自动化来增加现有function的价值，而不会负面地破坏现有的function，而是很好地与其集成，从而为整体增加了一个可感知的价值。 整合意味着，通过纯粹的英语定义，事物在代码交谈中和谐地交织在一起，我的整个编辑，链接，testing和运行都是完美的。 如果最终产品不合格，你不会打电话给你的东西？ 在我们的情况下，“持续部署”与“持续交付”是同义词，因为在一天结束的时候，我们已经为我们的客户提供了function。 但是，通过分析，我可以说部署是交付的一个子集，因为部署某些东西并不一定意味着我们交付了。 我们部署了代码，但由于我们没有有效地向我们的利益相关者传达信息，所以我们未能从业务angular度提供！ 我们部署了部队，但是我们还没有把应许的水和食物交给附近的城镇。 如果我join“持续过渡”这个术语，会有其自身的优点吗？ 毕竟，它可能更适合于描述代码在环境中的移动，因为它具有“从/到”的内涵，而不仅仅是部署或交付，这可能意味着永远只有一个位置！ 如果我们不应用常识，这就是我们所得到的。
总之，这是一个简单的东西来形容（做得有点复杂！），只是使用常识，英语，你会没事的。
持续集成，持续交付和持续部署之间的差异
DevOps是3C的组合 – 持续的 ， 沟通的 ， 协作的 ，这导致了各个行业的主要焦点。
在物联网连接的设备世界里，产品所有者，networking，移动和QA等多个scrum特性在scrum周期中以敏捷的方式工作，以便将产品交付给terminal客户。
持续集成：同时在多个端点工作的多个Scrumfunction
持续交付：通过集成和部署，将产品交付给多个客户同时处理。
持续部署：将多个产品部署到多个平台上的多个客户。
观看这个知道DevOps如何启用物联网连接的世界： https ： //youtu.be/nAfZt2t4HqA
;){kind=link}