\

本文要点

\\

• 持续交付（CD，Continuous Delivery）带来了快速的反馈循环，从而产生更简单的技术解决方案，它能得到更好的容错性，并且能够得到更简单的应用程序架构。\\t
• 对于新的软件项目，持续交付能够更快地实现增值，而现有项目的价值则需要以每一个案例为基础。\\t
• 在理想情况下，持续交付应该与测试周期的其余部分进行集成。负载测试、容量测试以及金丝雀部署（canary deployment）都完全适合持续交付管道，这使得人们可以把注意力集中放在那些可能难以量化的边缘案例和验收测试上。\\t
• 回滚部署、金丝雀部署以及蓝绿部署（blue-green deployments）变得越来越复杂，而那些由较小的、模块化的组件构成的系统更易于利用持续交付以及更便于集成。反之亦然，成功的持续交付就能够带来以这种方式设计的系统。\

\\

InfoQ：非常感谢您能接受InfoQ的采访。您能简单的介绍下自己吗？介绍下您在持续交付方面的背景以及您为什么要写这本书呢？

\\

\

我的名字是Eberhard Wolff。我是德国公司innoQ的一员。我们所做的行业是软件项目。我的工作重心不在于做项目，而是在于咨询和培训。

\\

我写这本书的原因是，我认为在开发软件的时候，持续交付是提高生产力和提高软件质量的最重要的工具。然而，人们却常常为了实现持续交付而焦头烂额。这本书给持续交付实践提供了一个非常实用的指南，其中涵盖了许多具体的技术案例。

\\

这本书有助于获得技术上的实际经验，然后开始实现持续交付。这本书还附带了一个可执行的应用程序示例，其中包括了持续交付中管道的每个步骤的实现。读者可以安装这个应用程序来获得一些有关技术的经验。

\

\\

InfoQ：组织或项目团队需要做什么样的分析才能决定什么时候实现持续交付以及在持续交付上需要实现什么呢？以及有哪些影响因素呢？

\\

\

持续交付最明显和最原始的目标是改善新特性推向市场的时间，从而获得更好的业务成果。但是持续交付还能带来更多好处：通过可重复的结果进行不断地测试，用这种高度的自动化测试提高了软件的质量。更频繁的部署和自动化的部署降低了部署的风险。这对软件开发以及IT都有着十分积极的影响。这些好处就是去实现持续部署最好的理由。

\\

你能通过持续交付走多远取决于对业务、软件开发、运维以及质量评估（QA）的投入。如果对业务的投入不够，你就无法得到更好的推向市场的时机。如果对于运维的投入不够，你就没办法扩展你的自动化管道使其直接投入生产。即便是你实现了一个不完全的持续交付也是值得的，当然了它也会不断完善。

\

\\

InfoQ：您能举一些具体的例子吗？谈谈您所看到的已经实现了的持续交付或者是集成到应用程序架构中的持续交付。它们都是什么样的？有哪些注意事项呢？

\\

\

人们总是觉得持续交付是有关于自动化集成的。但是持续交付的核心其实是测试和可靠性。我认为你永远不会进行非常多次的手工测试，当然了，手工测试也不会拥有极高的可靠性。

\\

对架构的影响是将其分成了单独的可部署模块：微服务。持续交付是采用微服务的一个重要驱动因素。这就是我现在主要关注架构和微服务的原因，也是我为什么写了一本关于微服务的书的原因。但是通常情况下，微服务体系结构设计的方式是，最终仍然需要将所有东西都部署到一起。这样做的话是无法利用持续交付的优势的。

\\

因此，我认为问题的关键不在于过分强调持续交付，而在于没有实现目标，或者只关注自动化部署，而不把测试考虑在内。

\

\\

InfoQ：您能详细谈谈持续交付对应用程序测试、对基础架构的测试以及对软件开发生命周期都有哪些影响吗？

\\

\

持续交付把重心放到了测试的自动化上。即便存在众所周知的困难，验收测试也应该是自动化的。这会使得测试的速度更快。因为持续交付的管道会频繁地被执行，因此许多很小的改动都会得到测试。这使得测试更加容易，并且能够提供更快的反馈。因此，持续交付不仅提高了对测试的关注程度，还改进了测试的方法。

\

\\

InfoQ：为什么验收测试如此重要呢？

\\

\

验收测试是为了使客户能够接受这个软件。客户通常会对软件进行手工测试。这种手工测试可能会持续几天甚至几周的时间，而且手工测试很容易出错。因此验收测试为软件的改进提供了巨大的潜力。如果这些测试是自动化的，那么整个流程就会更快、更可靠。

\\

然而，验收测试通常情况下很难自动化，因为客户必须要理解并信任自动化的验收测试，否则他们将会继续他们的手工测试。这本书向大家展示了一种技术，它实现了行为驱动设计（behavior-driven design）用以改进客户进行验收测试时的协作。书中还展示了一个基于UI的测试作为替代。最后，测试的重点应该更多地放在协作和信任上，而不是在技术上。

\

\\

InfoQ：您能谈谈探索性测试、金丝雀（canary）以及容量测试吗？因为它们都与持续交付有关。

\\

\

探索性测试基本上与持续交付平台分离了。例如，对一个软件的注册过程做可用性测试或性能测试。测试团队会通过手工的探索性测试来进行测试。由于现在大多数的测试都是自动化的，测试人员就可以将注意力集中在这些测试上。探索性测试并不能阻止软件的发布，它的目的是为了完善软件。

\\

金丝雀发布（Canary Releasing）的意思是该软件仅安装在集群中的几个服务器上。只有在这些服务器上能够正常工作之后，它才会被安装到其他服务器上。这通常是通过自动化部署实现的。但是，金丝雀部署（canary-deployment）是一种部署模式，它可以在部署过程中以不同的方式进行实现。在部署过程中，金丝雀发布能够降低风险。如果部署出现错误，只有少数服务器需要回滚。

\\

容量测试可以暴露出应用程序中存在的性能问题。通常情况下，测试只是在逻辑上发现问题。但是性能问题也可能使在生产环境中运行软件变得不可能。这只是持续交付管道的另一个阶段。

\\

然而，容量测试在测试环境中运行，而测试环境通常不像生产环境那样强大，而且通常只包含测试数据。因此，当在容量测试阶段中出现性能问题时，就应该实现像金丝雀部署那样的方法。

\

\\

InfoQ：您能谈谈负载测试框架吗？因为它们也与持续交付有关。还有，您能谈谈持续交付能给目前已经很好用的负载测试框架带来哪些独特的价值吗？

\\

\

这本书对Gatling进行了介绍。Gatling使用DSL来编写测试。因此，它支持将所有步骤自动化至生产的目标。Gatling可以通过使用分布式配置来确保生成足够大的负载。

\\

持续交付使得负载测试不再仅仅关注于性能，而且还确保了在性能优化过程中，通过执行包括验收测试在内的完整的测试套件使得性能优化过程不会出现错误。

\\

此外，持续交付还引入了基础架构自动化，并且它能使得为容量测试配置环境更加容易。特别是对于容量测试来说，对环境的配置可能会很复杂，因为容量测试耗时很长。在多个环境中并行地运行测试可能会有助于解决这个问题。

\

\\

InfoQ：持续交付平台具有哪些缺陷呢？有哪些缺陷会导致开发人员生产力的降低呢？

\\

\

根据持续交付的定义，它是跨组织的：它跨越了产品开发和软件工程团队、运维功能团队以及质量评估（QA）团队。在所有这些部门之间进行协作通常是很困难的。然而，我认为还有很多东西值得我们去做。即使在有限的协作条件下，你仍然可以改进自动化和测试，然后获得更好的软件质量。你可以分析软件是如何被投入到生产中去的，并在最需要投资的地方进行投资。除了能够提高生产力，你还能获得更好的软件质量。分析你们当前的流程并找出如何改进它们是一个很好的主意。这并不一定是一项战略投资，也可以是一些小的改进。

\

\\

InfoQ：在不使用持续交付工具的情况下，软件工程师们需要构建什么来实现蓝绿部署（blue-green deployments）和回滚呢？您能不能举几个例子来说明下持续交付在启用这些功能方面的优势吗？

\\

\

蓝绿部署和回滚是部署的基础架构的特性。Kubernetes和Paas（例如Cloud Foundry）支持这一点。蓝绿部署和回滚也取决于被部署软件的大小。基本上它们不可能适用于非常庞大的系统。因此，使用蓝绿部署是另一个将系统分割成小单元的原因，这些小单元可以单独进行开发——这就是微服务。

\

\\

关于作者

\\

Eberhard Wolff 拥有超过15年的架构和咨询经验，专注在业务和技术之间的领域。他在德国innoQ咨询公司工作。作为一个演讲者，他在很多国际性会议上呈现演讲。作为一个作者，他发表了100多篇文章，并出版了微服务相关书籍。他最新的著作是一本有关微服务的书。他专注于现代架构技术，包括云计算、持续集成、DevOps、微服务或NoSQL。他还是《Microservices: Flexible Software Architecture》一书的作者。

\\

查看英文原文：Q\u0026amp;A With Eberhard Wolff On the Book “A Practical Guide to Continuous Delivery”