持续集成、交付与部署：区别以及如何配合运行

尽管"持续“这个词被广泛使用，但它到底是什么意思？当用在持续交付、持续部署和持续集成等概念中时，其含义有何变化？三者到底有什么区别？企业、开发人员和项目经理如何才能在单个集成化的环境中更好地使用这些定义?

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

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

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

在考察多个DevOps概念的细节时，我们首先要解释持续在软件领域的含义。

什么是持续？

简言之，持续指软件在管道中以永不停止且完全连续的方式变化。

当然，这是DevOps人员的夸张说法，因为交付、部署和集成几乎不可能做到100%持续。事实上，持续集成的应用可能接近每24小时就要重构和交付，而不是在每次代码更改时进行。尽管这一速度并不像开发人员所承认的那样具有即时性，但它仍然比DevOps出现之前常见的交付管道快得多。

什么是CI（持续集成）？

持续集成是敏捷交付实践的关键组件。它是一种DevOps软件开发实践，在这个过程中，代码的更改在测试后定期合并到一个中央库中。持续集成的主要目的是更快地查找并修复潜在问题，提高软件质量，并且缩短发布新的更新的时间。

在持续集成实践广泛应用之前，开发人员一般以孤立的方式编写代码，在个人的工作完成后，仅尝试将更改合并到主分支中。这种将多个代码拼凑在一起的方法使得合并极为困难，而且非常耗时。

通过持续集成，开发人员可以频繁地向中央库分享，在集成前对代码进行本地的单元测试。持续集成服务器然后自动测试开发人员编写的代码，以保证代码可以合并到主代码库中，而不会出现任何功能或集成错误。通过自动执行这个流程，服务器可帮助开发人员几乎连续编写并测试少量代码，这最大程度降低了严重错误出现的风险。

持续集成的优点：

• “快速失败”，在对产品没有风险的情况下进行测试，并快速响应；

• 最大限度地减少风险，降低修复错误代码的成本；

• 将重复性的手工流程自动化，让工程师更加专注于代码；

• 保持频繁部署，快速生成可部署的软件；

• 提高项目的能见度，方便团队成员了解项目的进度和成熟度；

• 增强开发人员对软件产品的信心，帮助建立更好的工程师文化。
  

做好持续集成，可为持续交付与持续部署打好坚实基础。

什么是持续交付？

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

在大多数情况下，持续交付是一系列实践，其设计目的是以几乎连续的方式向用户交付软件。这些实践保证了代码可以快速部署到生产环境中，同时保证业务应用按预期运行。这种接近持续的更新交付方式由于在部署流程早期的优化而有可能实现。

一旦开发人员认为少量代码已经准备就绪，他或她就可以将代码发送给质量保证 (QA) 团队进行测试和监控。由于应用基本上采用小批量单独发送的方式，QA团队可以快速检查代码，并找出可能出现的错误。在QA团队进行这种评估的同时，构建的成果也发送到类生产环境中，经过严格测试后发布更改的结果。在完成所有评估后，软件可以轻松部署。

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

持续交付使新功能的引入能够以快速且可靠的方式实现，而且这对于试用新特性并立即看到客户如何反应极有帮助。通过逐一提出新的想法，您可以知道该想法是否明确地传达了预期的行为，而且能够看到它是否正确运行，而不必发布大型的新系统。

持续交付的其他一些好处包括以下能力：

• 在后端安装新特性，了解其在系统上的运行情况

• 迅速响应市场变化

• 根据业务战略的改变而快速修改

• 减少错误，提高预测准确度

• 远远领先竞争对手

什么是持续部署？

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

持续交付和持续部署两者都简称CD，有些人将两者互用，但二者有明显的区别，需要明确理解和认识。

正如前文所述，持续交付是指几乎连续地向用户发布更新，然而，这些更新必须由DevOps团队手动发布。与此相反，持续部署管道则完全自动运行。这样，用户能够在编写和测试代码后尽快收到更新，而不必等待开发人员的手动干预。所需的任何测试在类生产环境中进行，并且在合并到主线分支之前完成。

随着Docker等技术使得应用部署自动化更加轻松，持续交付和持续部署的区别肯定会越来越重要。这种易用性允许DevOps团队将容器镜像放到生产环境中，让其自动部署。这种自动化流程是持续交付的关键，因为这个流程可由任何人在几分钟内完成。一旦开始部署，检查日志并确定关键指标是否受影响非常重要，无论是正面还是负面影响。

在某些情况下，使用持续交付可能不太实际，例如IT人员必须等待新特性上线的情况。尽管应用特性切换在有些情况下可以解决这个问题，但这并非始终可行。对于这一问题，关键在于公司必须根据业务需求而确定持续部署是否有意义，而不是根据IT限制。

持续部署的优点

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

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

总结：如何配合运行

 一旦进入到持续部署流程，您就有了多个自动化组件。持续集成和持续交付必须自动实现，而且您需要有能力自动将代码部署到生产环境中。

理想的流程如下：

1. 开发人员将代码提交到开发分支。

2. 持续集成服务器收到更改，将其与主线合并。服务器对代码更改执行单元测试，并在测试成功后合并到暂存环境中。

3. 开发人员将代码部署到暂存环境中，由QA对环境进行测试。代码被移到生产环境，持续集成服务器再次接收，进行测试后合并到生产环境中。

4. 将更改部署到生产环境。

最后，所有这些“持续行动”都有助于消除部署流程的开销。合并代码、合并后对特性进行重新测试、手动部署等任务一般会为服务带来价值，因此，持续交付、部署和集成旨在从流程中消除这些费用。

如果您的公司与Flickr类似，每天部署多个更新和更改很有必要。另一方面，如果您是银行这样的机构，过于频繁地在软件中增加不同的特性和功能会使客户感到困惑，并与您的业务战略相悖。因此，您的公司要先确定DevOps的持续交付、持续部署和持续集成实践的采用是否有益。

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