这是 Amazon 一年完成 5000 万次部署，平均每个工程师每天超过 50 次部署的核心秘籍。
2009年底，比利时根特举办了第一届DevOpsDays。Chris-Read作为嘉宾之一，代表ThoughtWorks出席了这次活动并带来名为“持续集成，流水线和部署”的演讲。ThoughtWorks作为DevOps运动最早的见证者和奠基人，并没有意识到这个周末聚会将在接下来10年给全球IT行业带来深远影响。
本文将重点探讨Docker与持续集成/持续部署（CI/CD）之间的关系，并深入分析如何利用Docker构建高效的交付流程。从社区角度、市场角度、领域角度、资源角度、生态角度、层面角度和技术领域应用等多个角度进行综合分析，帮助读者深入了解Docker在持续交付中的价值和应用。
我在采用持续交付的组织中和开发团队工作一起工作，发现很多开发者认为的正确的敏捷团队的工作方式，在这里跑得不是很顺畅。我认为传统敏捷与持续交付的矛盾的根本在于，二者是采用不同的方式把软件变得“可以发布“（ready to release）的。
很多企业正在采用DevOps和持续集成/持续交付方法，以提高其规划、构建、测试和发布应用程序和特性的能力，从而以高质量和规模快速推向市场。调研机构IDC公司预计，到2022年，全球DevOps软件市场规模将从2017年的39亿美元增至80亿美元。
如果你身处IT领域，并且你不是昨天才出生的，那么你一定理解速度的必要性。自从企业实施了持续集成(CI)和持续交付(CD)，开发与交付周期要比过去快了很多。举个例子，浏览器和社交媒体站点每天都会进行多次交付，那些想要跟上信息时代步伐的企业，都在实施持续交付。为了确保持续交付的成功，有几个每个企业都需要知道的持续交付原则。
春节前与同事讨论CD（持续交付）的技术方案，发现主流的技术方案是软件交付最后一公里的“AD”（自动化部署）。站在本系列文章提到四个关键价值的“提升交付速度”这个运维价值看，单纯的自动化部署主要将部署/回切工作从1小时提升到5分钟的效率能力上。而在端到端的IT交付价值链中，部署是其中一个节点，所提升的55分钟只占整个IT交付链路中的一部分，更大的消耗是在节点与节点之间的协同。所以，“持续交付”应该跳出“部署”，站在整个IT交付链路，关注节点的自动化、节点与节点之间的连接线，通过标准化、流水线、自动化、相关工具链打通等工程性工作的落地，提升整个IT效能。
持续交付（Continuous delivery，缩写为 CD），是一种软件工程方法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的编译、测试与发布变得更快更频繁。这种方式可以减少软件开发的成本与时间，减少风险。 而我对持续交付的一个较为抽象的理解是“一套软件工程方法论和许多最佳实践的集合”。方法论和实践都需要人去总结落地，所以，要想体会到持续交付的真正含义，就要在实际工作中贯彻和使用实践工具。
对企业来说，这些价值一起使持续交付成为真正的游戏变革者。尽管可以在团队或项目级别开始采用和验证，但持续交付的本质是它以需要真正投资和自上而下承诺的方式跨越了组织边界。选择与现有投资互补并共存的持续交付工具链是走向成功的关键一步， 特别是因为 CD 可以引导你的组织采用 DevOps 文化。
上篇文章中，基于Jenkins pipeline构建了一个简单的持续交付过程。但这个过程仍有些问题需要完善，并没闭环。
前面的文章，聊了软件工程的基础理论、项目管理、需求分析、架构设计、软件测试以及线上服务的质量保障。其中在架构设计和线上服务的质量保障中，我也提到了关于持续集成持续交付相关的内容。软件工程的本质是用工程化的方法去规范软件开发，让软件开发项目可以按时保质完成的同时且成本可控。
CI/CD 的核心概念是持续集成、持续交付和持续部署。它是作为一个面向开发和运营团队的解决方案，主要针对在集成新代码时所引发的问题（也称为：“集成地狱”）。
CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题（亦称：“集成地狱”）。
对于项目或产品而言，好的工程实践也许并不起决定作用，项目或产品的成功依赖的因素太多了，市场，风口，公司的营销能力，人脉以及资源等。
大家好，我是洋子。昨天写了一篇文章《CI/CD是什么》，介绍了持续集成，持续交付，持续部署的概念
作者 Andrew Phillips 译者 张斌 持续交付（CD）是一种软件策略，它使企业尽可能快速有效地向用户提供新特性。持续交付的核心思想是创建可重复、可靠和逐步改进的过程，从而将软件从概念变为现实带给客户。持续交付的目标是通过自动化软件生产线使变更不断流入生产。持续交付流水线使持续交付成为可能。 流水线将软件交付过程分成阶段。每个阶段旨在从不同角度验证新特性的质量，以确认新功能，并防止失误给用户造成影响。流水线应向团队提供反馈，并让所有交付新特性的人员了解变更流。 虽然没有标准流水线这样的东西，但典
来源：https://blog.jjonline.cn/linux/238.html
DevOps是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。具体来说，就是在软件交付和部署过程中提高沟通与协作的效率，旨在更快、更可靠的的发布更高质量的产品。
CI的英文名称是Continuous Integration，中文翻译为：持续集成。
持续集成(Continuous Integration）与持续交付(Continuous Delivery )、持续部署（ContinuousDeployment）作为敏捷开发实践，可以及早发现、解决问题，从而更早地将产品交付给客户。及早地从客户那里得到反馈，就可以及早地对产品进行修复和完善，交付更加完美的产品给客户，最终形成了良好的可以持续的闭环。
持续交付（CD）是一种软件策略，它使企业尽可能快速有效地向用户提供新特性。持续交付的核心思想是创建可重复、可靠和逐步改进的过程，从而将软件从概念变为现实带给客户。持续交付的目标是通过自动化软件生产线使变更不断流入生产。持续交付流水线使持续交付成为可能。
如果从这个系列的第一篇看起，直至这一篇为止，我相信一个共识应该是：在技术上实现它非常简单
携程系统部研发总监吴毅挺，在 QCon 北京 2016 上分享了《携程的持续交付之路》：经历了新平台上线、大刀阔斧改革、以及 528 之殇之后，携程的交付能力有了怎样的提升？交付平台有了怎样的改进？我们从中能够得到什么经验？都可以在视频中找到答案。 随着携程业务的高速发展，研发人员增长迅速，业务系统日益复杂，缩短 Idea 到功能交付至用户手中的时间至关重要。 本次演讲分享了携程持续交付平台的发展历程。新一代平台上线，引入诸多新技术，大刀阔斧的变革应用部署规范和生命周期管理，建立可视化发布，数千应用如何平滑
由上图可知「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」这三个概念的区别是在软件开发流程中根据实现的持续化，自动化的阶段的不同来划分的。
随着DevOps理念的普及与扩散，可能会被一大堆名字概念搞的莫名其妙，理清它们之间的关系可以帮助团队知道DevOps如何落地，改善工作流程。
上篇文章学习了DevOps四大知识体系的“敏捷管理”(Scrum框架)、“精益管理”（精益看板），今天继续“持续交付”的学习。
本篇是上一篇的延续。很早之前，我提到过，运维的本质其实是在做交付，没有做到面向用户的交付，不是好运维，IT也不是一个好IT。如下图：
本文主要介绍了持续交付和DevOps的概念、现状、挑战和实践，强调了持续交付和DevOps对于软件开发和运维的重要性，并通过一些实践案例和思考来加强理解。
编外的话 KK是一位摄影爱好者，所以PPT里会有大量精美的图片，这 PPT 看着多舒心呀！笔者有幸在北京和KK有过一次亲密接触，并和KK畅聊 Jenkins 及 DevOps。 真的不是我矮啊，只是K
有一天，业务人员急冲冲的跑过来，对你说生产上出现了一个严重BUG，必须要尽快修复。你听完问题描述后，胸有成竹坐定并迅速定位问题，随后改动了一行代码并提交，系统开始自动编译、各个环境自动化测试、发布上线。几分钟后，生产环境上该BUG已经被修复掉。 上面所提到的场景，这是不是很美妙？但是想必不少读者要忍不住要吐槽了，这太不实际了：新功能上线测试不要时间么？新增了功能肯定要做回归测试，这都需要一定的时间。况且怎么可以随便部署上线？还得通过预发演练、走发布审批流程。其实这些过程大家也都清楚，那么不妨从另一个角度思考
在过去十年，DevOps 一直是大家热议的话题，10 个人心中有 10 个哈姆雷特，十家公司却不止十个 DevOps 定义，也许在你从事技术的生涯中，听过不止 100 种 DevOps 定义。
在软件或运维开发过程中经常会遇见DEV FAT UAT PRO CI CD等名词。但又不确定其中的意思，下面为各名词作一个解释归类。
什么是 CI/CD？ 什么是 CI/CD？作者：Izzy Azeri-让我们看一下 CI 和 CD，这是所有 DevOps 商店的基本基石，并看看如何利用这些概念来帮助更好地交付下一个项目。 什么是持续集成和持续交付？作者：Arnab Roy—我们深入探讨了 DevOps 环境的两个基本要素。 什么是持续交付？好处和最佳实践，作者：ATC 团队-看看持续交付如何适合 DevOps 流水线，它与持续部署有何不同以及一些最佳实践。 持续集成与持续交付，作者：Rebecca Pruess—持续集成和交付是最常
５分钟了解一个容器典型应用场景系列篇 关于容器解决方案的概念、架构、成功案例，笔者已经分享了很多了。为了使读者能够花更短的时间，迅速感性地解容器的典型应用场景。笔者从今天开始，推出“５分钟了解一个容器典型应用场景”系列片。每次分享一个场景，采用文字描述+视频展示的方式。本系列分享内容将分别是：灰度发布、CI/CD、开发自动化、微服务、业务弹性扩展。 声明：本实验基于红帽淡成等专家提供的实验步骤和实验环境/脚本整理而成。在此表示感谢。 本系列第一篇：火力全开 | 灰度发布 | 5分钟了解一个容器典型应用场
「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」提供了一个优秀的 DevOps 环境，持续集成（Continuous Integration）是Devops理念的一种实践过程，同时也是敏捷开发的具体表现形式。对于整个团队来说，好处与挑战并行。无论如何，频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。这里我们着重介绍持续集成过程中的测试自动化（Test Automation）,如果测试没有实现自动化的话，那么整个持续集成是不完善的，同时也不是高效的。因此自动化测试是持续集成过程中的重要一环。
持续继承的重点是将各个开发人员的工作集合到一个代码仓库中。通常，每天都要进行几次，主要目的是尽早发现集成错误，使团队更加紧密结合，更好地协作。
近几年微服务架构与容器化技术飞速发展，随之而来的是持续集成与持续交付的概念又重新不断被提及，越来越多的公司开始使用持续集成系统来解决频繁发布带来的质量问题，使用持续交付工具实现代码的自动部署。
“软件工程”这一学科出现于 1968 年，当时正值第一次软件危机。第一次软件危机是落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。人们试图借鉴建筑工程领域的工程方法来解决这一问题，以实现“按预算准时交付所需功能的软件项目"的愿望。
Jenkins是自动化领域非常重要的一个产品，它是基于Java语言的一个开源免费的自动化产品。
持续交付是一种可以快速，安全和自动化地将软件更改部署到生产中的实践。在持续交付中，发布新功能并不是一件令人痛苦的事件。在没有采用持续交付之前，公司的每个人都在代码完成之后的数周内停止工作，并在开始部署的时候紧张地等待着仪表板。相反向用户发布新软件应该是例行，无聊且容易的，以至于一天可能发生多次。
持续集成 尽可能快的把不同开发人员修改的代码集成到一起，通常一天进行多次 需要结合自动化单元测试，每次集成都运行一整套单元测试 目标是尽快发现代码问题 持续交付 持续的把改动的代码交给预演环境，接受QA检查，确保此套代码是可以随时部署的 持续交付比持续集成更进一步，持续集成是代码层面的测试，持续交付不仅把代码集成起来，还会把真实环境中需要的配置信息设置好，在预演环境中运行起来，进行整体业务逻辑检查 目标是保证代码处于可部署状态 持续部署 把所有通过测试的代码尽快部署到线上产品环境 持
本文主要澄清了敏捷开发、持续集成、持续交付1.0、持续交付2.0 、持续部署、DevOps、研发效能七个概念，以便我们在后续相关实践中能清楚地辨别。
DevOps 是敏捷开发的产物，也越来越受到谷歌、Facebook 或亚马逊等大型企业的关注。因此，当你要申请 DevOps 工程师岗位时，除了所需的专业技能外，准备充分的 DevOps 工作面试，对于成功拿到 Offer 也至关重要。
持续交付的目标就是从代码编译到可部署的二进包，甚至是部署这个很多都是依赖手工操作的过程自动化，流水线化。
近些年来，持续集成、持续交付以及持续部署这几个热词总是在大家的眼前晃来晃去！在招聘信息和面试过程中也会经常提及！在这里我就用三分钟时间来带大家了解他们！
一个软件从零开始到最终交付，大概包括以下几个阶段：规划、编码、构建、测试、发布、部署和维护，基于这些阶段，我们的软件交付模型大致经历了以下几个阶段。
Timothy Fitz 关于持续部署的博客文章(中文版)在我和 Dave 出版《持续交付》一书之前一年多就发表了。 为什么我们选择了不同的名字呢？ 是实际上有区别还是我们心血来潮？
上两周参加了部门项目敏捷培训，讲的是项目管理敏捷，内容很多，挑了一些点在团队中试运行，最终可落地的只剩下需求分解，看板管理两点。看起来，从技术角度看敏捷，通常讲的是项目研发层面的敏捷，涉及通过组织架构、流程机制、绩效管理、项目协同、产品研发、持续交付等层面的调整，推动业务技术相融合。由于各团队的现状不一样，很难采用一套标准化的敏捷协同模式，敏捷更多的是局部根据实际情况，悟出敏捷强调的“价值交付、适应变化、自组织、沟通、MVP”等的内涵，并进行落实。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
