持续交付(CI)：从持续集成 (CD)中逐步提升

介绍

根据持续交付权威Martin Fowler的说法，您在以下情况下持续交付：

• 您的软件可在其整个生命周期内进行部署
• 您的团队优先考虑保持软件可部署而不是处理新功能
• 任何人都可以随时获得有关系统生产准备情况的快速自动反馈
• 您可以根据需要对任何版本的软件执行按钮部署

他还阐明了持续交付与持续部署不同，往往被误认为是同一个。

 

“持续部署意味着每个变更都会通过管道自动投入生产，每天都会进行大量的生产部署。持续交付只是意味着您可以经常部署但可能选择不这样做，通常是因为企业更喜欢较慢的部署速度。“

 

为什么持续交付 (Continuous Deployment)？

在上面链接的上述帖子中，我们已经看到为什么CI已成为任何软件开发公司的强制性投资，因为它为开发人员和客户提供了可衡量的利益。这些可衡量的变量包括软件质量，更快的上市时间，更快的缺陷反馈周期，更低的开发成本以及整个软件开发过程中集成问题的发生率降低。

但这足以激发信心吗？

• 是的，测试通过，CI服务器仪表板全部为绿色。
• 是的，在它到达客户之前已经发现了一个令人尴尬的错误。
• 我们能否充满信心地说，软件在生产环境中不会失败？不，那是因为CI的界限在开发组织内。
• 开发人员和运营商之间存在边界，并且该边界尚未被破坏。
• 开发人员将他们推出的代码清洗干净，安全地知道球现在在别人的手上。

由于大多数公司的开发组织和运营组织之间几乎没有任何沟通，因此需要进行“切换”。开发人员在客户的操作环境方面做出的假设通常在这里被认为是不正确的，或者充其量是开发组织对客户世界的良好假设。

想象一下大多数公司运营团队的困境。他们收到了一组开发人员的软件交付，他们对客户的安装环境几乎一无所知。开发人员机器中的“工作”并不能保证在客户的复杂生产环境中工作。这就是CD的用武之地。

持续交付是一种软件工程方法，团队在短时间内生成软件，确保软件可以随时可靠地发布。它旨在以更快的速度和频率构建，测试和发布软件。

部分原因是测试您所做的每一项更改（即持续集成）。此外，您还努力打包将要部署的实际工件 - 可能您已经将这些工件部署到暂存环境中。

因此，持续交付实际上需要持续集成 它依赖于相同的基本原则。在下图中很好地捕捉到了这些差异。

（图片来自  collab.net  -  http://www.collab.net/solutions/devops）

持续整合向持续交付的转变

通常，CI已经建立并运行，例如作为引入敏捷开发方法的一部分。持续集成通常是指在开发环境中集成，构建和测试代码。持续交付以此为基础，处理生产部署所需的最后阶段。

大多数组织都是从持续集成（CI）开始，这是关于开发人员每天多次将代码更改合并到存储库。每次合并都会触发项目的自动构建和测试序列。然后自动化测试验证代码，开发人员立即修复任何损坏的测试。CI充当安全网，允许开发人员在到达最终用户之前预防许多问题。

CD建立在持续集成的基础之上，在构建阶段之后将所有代码更改部署到测试环境和/或生产环境。在正确实施持续交付时，开发人员将始终拥有已通过标准化测试流程的部署就绪构建工件。

持续交付管道

通过部署管道启用持续交付。部署管道的目的有三个组件：可见性，反馈和持续部署。

• 可见性 - 团队的每个成员都可以看到交付系统的所有方面，包括构建，部署，测试和发布，以促进协作。
• 反馈 - 团队成员在问题发生时尽快了解问题，以便他们能够尽快解决问题。还有用户反馈。越早越频繁地在真实用户面前获得工作软件，您就能更快地获得反馈，以了解其实际价值
• 持续部署 - 通过完全自动化的流程，您可以将任何版本的软件部署并发布到任何环境。由于您正在部署较小的更改，因此出现问题的可能性较小，如果出现问题则更容易修复。

在产品层面，转向CD模型不是一夜之间的工作。必须对代码做出重大改变，这不仅涉及对工具的重大投资，而且涉及现有系统本身的核心方面。他们之中有一些是：

自动化测试

如果您已成功实施CI，您的开发团队将能够将代码合并到主分支，每天最多几次。
每次将代码合并到主分支时，自动化测试应该能够检测到错误。如果没有自动化构建和测试，就无法以持续交付所需的速率查找和修复问题。

产品架构

CD不仅仅是一个流程改进问题 - 它是一项高度技术性的举措。CD管道的设计应该密切反映产品的架构。

例如，了解产品的优势和局限是至关重要的，如果经常交付是否引起关注？
是否存在回滚机制，如果出现问题，可以轻松恢复最新部署？

如何处理特定于环境的配置和部署？

代码库是单片吗？应用程序应以何种方式拆分为较小的部分，这些较小的部件如何在运行时等部署和交互。

部署是否可以完全自动化？系统的某些部分是否需要手动干预或手动设置？

通过对产品架构的正确投资，为客户频率和小批量交付价值的目标显着增加。

摘要

总之，这里是对最重要术语的回顾。持续集成是DevOps软件开发实践，旨在提高代码质量并实现代码的快速交付和部署。代码更改会自动构建，测试并准备好发布到生产中。

持续交付是持续集成概念的延伸。没有CI，你就不能拥有CD。CI处理每个版本的开发周期的构建和测试部分，CD侧重于在该点之后的承诺更改所发生的事情。通过持续交付，任何通过自动化测试的提交都可以被视为发布和部署到生产环境中的有效候选者。

理论上，通过持续交付，您可以决定每天，每周，每两周或任何适合您业务需求的发布。您可以更频繁地发布，从而加快与客户的反馈循环。部署软件的复杂性已被剥夺。您的团队不再需要花费数天时间准备发布。

---

其他推荐的scrum文章

敏捷宣言和十二項原則

All Agile Software Development Methodologies (SCRUM, Kanban, XP) contain the Agile Manifesto (Core Values) and 12 Agile Principles, which represent a set of values to guide people in an organization how to behave with each other. ( 所有敏捷軟件開發方法（SCRUM，看板，XP）都包含敏捷宣言（核心價值觀）和12個敏捷原則，它們代表了一系列價值觀，用於指導組織中的人們如何相互行事。)

Timeboxing 在 Scrum中是什么含义？

The goal of timeboxing is to define and limit the amount of time dedicated to an activity. Scrum uses timeboxing for all of the Scrum events and as a tool for concretely defining open-ended or ambiguous tasks. (时间装箱的目标是定义和限制专用于活动的时间量。scrum 将时间装箱用于所有 scrum 事件, 并用作具体定义无期限或不明确任务的工具。)

极限编程（XP）vs Scrum

Scrum is a framework for product development, which is a container where you can add other practices. XP is one of those practices that you can do within Scrum framework. This article shows you the similarities and differences between them and there are no reasons why a team need choose between Scrum and XP exclusively. (Scrum是一个产品开发框架，它是一个容器，您可以在其中添加其他实践。XP是可以在Scrum框架内完成的实践之一。本文向您展示了它们之间的相似性和差异，并且没有任何理由说明团队需在Scrum和XP之间进行选择。)

精益生产中的8种浪费 – 如何定义？

A lean organization understands customer value and focuses its key processes to continuously increase it. The ultimate goal is to provide perfect value to the customer through a perfect value creation process that has zero waste. This article shows you how to identify those wastes (精益组织了解客户价值, 并专注于其关键流程以不断提高客户价值。最终目标是通过一个零浪费的完美价值创造过程, 为客户提供完美的价值。本文向您展示了如何识别这些浪费)

最好的免费和商业敏捷工具 – 每个Scrum团队都需要

In this article you will get a list of 10 latest and efficient Agile Project Management tools that would help your team in the entire scrum development process. You need some agile toolset for enhancing the productivity of your team and help ease the pain points even if you have remote employees. (在本文中，您将获得10个最新，最有效的敏捷项目管理工具列表，这些工具可以帮助您的团队完成整个Scrum开发过程。您需要一些敏捷的工具集来提高团队的工作效率, 并帮助缓解难题, 即使您有远程员工也没关系。)

为什么选择Scrum？Scrum如何克服我们总是面临的8个痛点？

What you need to know in a nutshell — the 8 pain points we most often see in Scrum project planning and analysis. This article shows you how to using Scrum and Agile to overcome them. (你需要知道的是–scrum 项目规划和分析中我们最常看到的8个痛点。本文向您展示了如何使用 scrum 和敏捷来克服它们。)

什么是Scrum框架中的3355？

using four simple facts (3355) to help us to understand and recap the key concepts of scrum (使用四个简单的事实（3355）来帮助我们理解和概括Scrum的关键概念)

Scrum vs 瀑布 vs 敏捷 vs 精益 vs 看板

There are a number of different approaches in the software development industry – some are new takes on old methods and others have adapted a relatively new approach. The two most commonly used methods in this field are the Agile such as, Scrum, Kanban and Lean and etc., and traditional Waterfall models such as structured methods or newer RUP. ( 软件开发行业有许多不同的方法 - 一些是旧方法的新方法，另一些方法采用了相对较新的方法。该领域中最常用的两种方法是敏捷，如Scrum，Kanban和Lean等，以及传统的瀑布模型，如结构化方法或更新的RUP。大多数遵循这两种模式的软件公司都认为他们选择的方法在方面是优越的，所以在我们回答这个问题之前，“哪一个更成功？我们应该看看它们的主要区别。)

如何保持Scrum的透明度？

Transparency is vital to the Scrum process, as it allows everyone to see and understand what is really happening in each sprint, achieving a bigger and better communication and trust on the team and in this methodology. This Article shows you how to do it. ( 透明性对于Scrum过程至关重要，因为它允许每个人看到和理解每个Sprint中实际发生的事情，从而在团队和这种方法中实现更大、更好的沟通和信任。这篇文章向您展示了如何做到这一点。)

Scrum: 经验过程控制vs定义过程控制

In empirical process control, you expect the unexpected. With defined process control, every piece of work is understood. In Scrum, an empirical process is implemented where progress is based on observation and experimentation instead of detailed, upfront planning and defined processes. (在经验过程控制中，你期待着意想不到的结果。通过定义的过程控制，可以理解每一件工作。在Scrum中，实现了一个经验过程，其中进度是基于观察和实验，而不是详细的预先规划和定义的过程。)