前言

定义与概述

持续交付使软件能够比以前更快、更可靠地投入使用。这些改进的基础是一条持续交付流水线,它在很大程度上使软件的发布过程自动化,形成一个可重复、低风险的新版本发布过程。

“持续交付”一词从何而来?

敏捷宣言是这样陈述的:“我们的首要目标是,尽早交付并持续交付有价值的软件,并让客户满意。”

因此,持续交付是一项敏捷技术。

本书介绍了如何在实际工作中构建这样的流水线,以及会用到哪些技术。其关注点不仅仅是软件的编译和安装,还包括确保高质量软件所需的各种测试。

同时,本书以实例说明了持续交付在DevOps 环境中对开发和运维之间的相互作用的影响,并阐述了它对软件架构的影响。本书不仅讨论了持续交付背后的理论,还介绍了它所涉及的技术栈,包括构建、持续集成、负载测试、验收测试和监控。本书针对每项技术都提供了示例项目,以帮助读者获得实践经验。虽然本书只是大致介绍技术栈,但也特别强调了如何在不同的主题上获得更加全面的知识,还针对实验和实操给出了建议。按照以上方式,读者可以在指导下一边学习所讲的主题,一边完成开发实践。书中的示例项目既可以用于独立实验,也可以用于构建持续交付流水线。

本书网站中含有更多详细信息、勘误表①和示例链接,网站地址为http://continuous-deliverybook.com。

为什么要使用持续交付

为什么要使用持续交付呢?让我们用一则小故事来回答这个问题。当然,故事的真实性是另外一回事。

① 本书中文版勘误请到http://ituring.cn/book/2446 查看和提交。——编者注

一则小故事

某个企业(我们姑且称之为“大财团在线商务公司”)的市场部,决定修改其电子商务网站的注册流程,目的是吸引更多的客户,从而增加销量。于是,一组开发人员随即着手实现。不一会儿,这个小组就完成了任务。

首先,所有变更必须经过测试。为了测试,大财团在线商务公司历经千辛万苦终于搭建了一个测试环境。软件必须在这个测试环境中接受手动测试。倒霉的是,测试竟然发现了一些错误。但此时,开发人员已经在进行下一个项目了,他们必须先重新熟悉旧项目,然后才能修复错误。此外,因为进行的是手动测试,所以有些“错误”其实是由测试人员造成的,他们没有按正确的方式测试。还有一些“错误”出于某些原因而无法重现。

接下来,需要将代码部署到生产环境中。经过多年的发展,大财团在线商务公司的电子商务网站已经变得非常复杂了,所以部署新版本要执行非常复杂的流程。一次部署只交付一个特性太不划算了,因此按计划每个月只部署一次。毕竟,这个注册流程的变更可以和上个月所做的其他变更一起发布。因此,团队为所有变更的部署预留出一个晚上。然而,在发布过程中出错了。开发团队开始分析问题,但事实证明,问题没那么简单,结果到了第二天早上系统仍然无法使用。此时,开发人员已经疲惫不堪,而且承受着巨大的压力,因为系统失效的每一分钟都会造成经济损失。由于部署中的一些修改无法轻易撤销,因此不能回退到旧版本。特别工作组经过一整天全面的错误分析,终于解决了这个问题,使网站恢复使用了。原来,在测试环境中曾经修改过一项配置,但是在部署生产环境时忘了修改。

现在,万事大吉了吗?并没有,有个错误从一开始就被忽略了。这个错误本应该在手动测试时就被找出来,但检测这个错误的测试并没有显示异常。问题在于,测试期间修复过一些错误,而这个测试只在做这些修复之前执行过。恰巧,这个错误正是因为其中一个修复造成的,由于在这次修复之后没有重新执行测试,就把错误遗留到了生产环境。

结果,第二天才偶然发现,网站的注册功能根本用不了。直到一个潜在客户打电话投诉,大家才意识到这个问题。糟糕的是,此时不知道因为这个错误已经错失了多少潜在客户,网站根本就没统计这个数据。在这次注册流程优化后,不知道多久才能把这些损失弥补回来。而且,优化后的注册数很有可能并没有像预计的那样增加,反而减少了。除此之外,这个新版本还特别慢,这种情况也没有人预料到。

于是,大财团在线商务公司开始了下一轮优化和功能的实现,希望在下个月再推出一个新版本。那么,有什么方法可以改善这次部署吗?

持续交付的作用

持续交付能够通过以下措施来解决上述问题。

□ 更频繁地部署——达到每天几次,让用户更快用上新特性。

□ 频繁地部署还能让新特性和代码修改得到更快的反馈,开发人员不必去回忆一个月前实现的特性。

□ 为了能够更快地部署,测试环境的搭建和测试必须在很大程度上实现自动化,否则工作量就太大了。

□ 自动化带来可重复性:一旦成功搭建了测试环境,就可以使用相同的自动化方式来构建生产环境,它们实际上用的是相同的配置。因此,不会出现由生产环境配置错误导致的问题。

□ 自动化带来了更大的灵活性,可以按需搭建测试环境。例如,某个时间段为了营销重新设计了用户界面,那就可以为此搭建一个单独的测试环境。此外,进行全面的负载测试时,可以生成一个类似于生产环境的额外环境。在测试之后,可以销毁这个环境,这样就不需要对硬件进行永久性投资了(例如,使用云计算)。

□ 自动化测试更易于重现错误。因为每个测试执行的步骤完全相同,所以发现的错误与测试的运行无关。

□ 如果测试实现了自动化,那么可以更频繁地运行它们,而无须做额外的工作。因此,可以让所有修复都经过完整的测试,这样注册流程中的那个错误就不会在投入使用后才被发现了。

□ 在向生产环境部署代码时,采取一定的措施,使系统在必要时能够轻松地回退到旧版本。这可以进一步降低与新版本相关的风险,并避免故事中提到的那次生产事故。

□ 最后,应用程序应该基于领域进行监控,这样像注册之类的流程一旦发生故障就会有人注意到。

总之,持续交付为业务提供了能够更快应用的新特性和更可靠的IT 系统。可靠性的提升对开发人员自己也有好处,因为谁也不想在晚上或周末高度紧张地发布新版本和修复新出现的错误,这样的日子了无生趣。此外,对于IT 系统和企业来说,在测试过程中就检测到错误,肯定好于在生产环境中暴露错误。

实现持续交付的技术和技巧有很多。持续交付会影响方方面面,甚至会影响应用程序的架构。这些就是本书要讨论的主题。本书旨在创建一个可以快速、可靠地交付软件的过程。

目标读者

本书适合想要引入持续交付和DevOps 的经理、架构师、开发人员和管理员阅读。

□ 在本书的理论部分,经理将了解持续交付背后的流程,以及它对企业的要求及其优势。此外,他们还将学会评估持续交付的技术影响。

□ 在本书的技术部分,开发人员和管理员将全面学习实现持续交付和构建持续交付流水线所需的技能。

□ 除了技术方面,架构师还可以了解到持续交付对软件架构的影响,详见第11 章。

本书将介绍实现持续交付的各种技术。我们将以一个Java 项目为例。在某些技术领域(例如验收测试的实现),有一些使用其他编程语言实现的技术。本书在这些上下文中会提到替代方案,但仍以Java 为主。自动分配基础设施的技术与使用的编程语言无关。本书特别适合Java 领域的读者,而使用其他技术的读者可能需要自己举一反三。

本书结构

本书由三部分组成。第一部分介绍持续交付的基础知识。

□ 第1 章“持续交付:是什么和怎么做”,介绍“持续交付”这个术语,并解释持续交付解决了哪些问题以及如何解决这些问题,还对持续交付流水线进行了初次介绍。

□ 持续交付需要自动部署基础设施,因为无论如何软件都是要安装到服务器上的。第2 章“提供基础设施”,介绍自动部署基础设施的方法:Chef 用于自动化安装;Vagrant 用于在开发人员的机器上搭建测试环境;Docker 不仅是一个非常有效的虚拟化解决方案,而且可以用于软件的自动化安装。第一部分的最后概述了将PaaS(平台即服务)云解决方案用于持续交付的方法。

第二部分详细描述持续交付流水线的不同组件。在介绍完概念之后,列举了一些具体的技术,可以应用这些技术来实现流水线中的各个部分。

□ 第3 章“构建自动化和持续集成”,由Bastian Spanneberg 编写,重点介绍提交新软件版本过程中的相关内容。这一章介绍Gradle 和Maven 之类的构建工具,概述单元测试,讨论与Jenkins 的持续集成,并介绍使用SonarQube 进行静态代码检查以及Nexus 和Artifactory之类的存储库。

□ 第4 章“验收测试”,介绍JBehave 和Selenium,它们可以用于基于图形用户界面的自动化验收测试和文本验收测试。

□ 第5 章“容量测试”,通过容量测试介绍性能。这一章以Gatling 作为示例技术介绍容量测试。

□ 第6 章“探索式测试”,介绍探索式测试,这种测试方式用于手动检查应用程序中的新特性和普通问题。

以上各章讨论了持续交付流水线的起始阶段,这些阶段会对软件开发产生主要影响。以下各章重点介绍在持续交付流水线中贴近生产环境的阶段使用的技术和技巧。

□ 第7 章“部署:在生产环境中发布版本”,描述在生产环境中发布软件的过程中尽可能降低风险的方法。

□ 在应用程序的运维期间,可以收集各种数据以获得反馈。第8 章“运维”,介绍辅助收集和分析数据的技术:用于分析日志文件的ELK(Elasticsearch、Logstash、Kibana)Stack 和用于监控的Graphite。

本书为这些章节中所述的各种技术提供了一些示例,读者可以在自己的计算机上进行尝试和实验,获得实际的操作经验。由于基础设施是自动化的,因此很容易在自己的计算机上运行这些示例。

最后要回答的问题是:如何引入持续交付?它有什么影响?本书的第三部分对此展开了讨论。

□ 第9 章“引入持续交付”,介绍如何在组织中引入持续交付。

□ 第10 章“持续交付和DevOps”,介绍将开发(Dev)和运维(Ops)合并为一个组织单元(DevOps)。

□ 第11 章“持续交付、DevOps 和软件架构”,讨论持续交付对应用程序的架构的影响。

□ 第12 章“总结:收益是什么”,对本书进行了总结。

阅读路径

不同读者的阅读路径可能有所不同,建议读者按照各自的需求来安排阅读顺序(如图P-1 所示)。第1 章是所有读者都应该阅读的,这一章阐明了持续交付的基本术语,并讨论了持续交付的动机。

图像说明文字

各章的重点如下。

□ 开发人员对于涉及提交和测试的章节更感兴趣。除了开发,这些章节还讨论了质量保证和构建,并且展示了持续交付对这些工作的影响。此外,它们还提供了来自Java 领域的具体代码和技术示例。

□ 管理员和运维人员尤其需要了解部署、基础设施分配和运维等主题,这些领域也会受到持续交付的影响。

□ 从管理的角度来看,“引入持续交付”和“持续交付与DevOps 之间的关系”是最重要的信息。第9 章和第10 章介绍了持续交付对组织的影响。

□ 架构师必须有开阔的视野。探讨软件架构的第11 章无疑是他们的主要关注点;然而,由于他们通常还对技术细节和管理视角感兴趣,因此可能还需要读一读与这些主题相关的章节。

□ 最后,专门用一章对本书进行了总结。

说明

请在informit.com上注册本书,以便获取可下载的内容、更新内容以及勘误。若要注册,请访问informit.com/register,登录或创建一个账户。然后输入产品ISBN“9780134691473”,点击“Submit”。完成这一流程之后,即可在“Registered Products”下找到所有附加内容。

目录

  • 前言
  • 第1章 持续交付:是什么和怎么做
  • 第2章 提供基础设施
  • 第二部分 持续交付流水线
  • 第3章 构建自动化和持续集成
  • 第4章 验收测试
  • 第5章 容量测试
  • 第6章 探索式测试
  • 第7章 部署:在生产环境中发布版本
  • 第8章 运维
  • 第三部分 持续交付的管理、组织和架构
  • 第9章 引入持续交付
  • 第10章 持续交付和DevOps
  • 第11章 持续交付、DevOps和软件架构
  • 第12章 总结:收益是什么