Daniel Bryant 是Datawire 的独立技术顾问和产品架构师。他专注于通过发现价值流、创建构建管道以及实施有效的测试策略，在组织内实施持续交付。Daniel 在技术上擅长DevOps 工具、云计算/ 容器平台和微服务实现。他还是一名Java 社区领袖，为几个开源项目做出过贡献，也为InfoQ、O’Reilly 和Voxxed 撰写文章，并且会定期出席OSCON、QCon 和JavaOne 等国际会议。Abraham Marin-Perez 是一名Java 和Scala 开发人员，在金融、出版和公共部门等行业拥有超过10 年的经验。他还帮助管理伦敦Java 社区，并在Meet a Mentor London小组提供职业发展方面的建议。Abraham 喜欢与其他人分享他的经验，因此经常会在JavaOne 或者Devoxx UK 等国际活动上发表演讲，并在InfoQ 上发表Java 方面的新闻。他还是Real-World Maintainable Software (O’Reilly) 一书的作者。Abraham 目前居住在伦敦，喜欢在天气好的时候外出徒步，或者天气不好的时候在家烹饪。

张若飞，曾任多家互联网金融公司CTO，在宜人贷、雅虎北研、金山云等知名公司担任架构师。十余年互联网研发及技术管理经验，对搭建海量数据、大型分布式系统有丰富经验。著有十余本技术译著，包括《给大忙人看的JavaSE 8》《代码不朽：编写可维护软件的十大原则》《面向可伸缩架构》《云原生Java》等书，总计400余万字。

序一

自从Dave Farley和Jez Humble写了Continuous Delivery一书后，持续交付社区普遍开始认为工具并不重要。在现实中，已经存在大量优秀的编程语言，以及大量用来构建、测试和部署程序的优秀工具。因此，他们曾经的观点是，你使用什么工具并不重要，只要不去使用那些特别糟糕的工具。

这些年，这种观点被Nicole Forsgren博士、Jez Humble和Gene Kim的研究工作进一步发展。他们的著作Accelerate总结了他们在持续交付、IT效能等方面多年的研究成果。

其中的一个结论就是，一个团队是否能够选择适合自己的工具，对于持续交付有着绝对重要的影响。因此，现在这个观点已经变成：你使用什么工具并不重要，只要你有能力自己选择工具，并且不去使用那些特别糟糕的工具。

以我自己为例。我第一次在团队中实施持续交付，还是2007年在Elsevier公司工作期间。我们借助了一些极限编程的方式，例如TDD和CI，使用Java 6、Spring 2和Tomcat 6编写了一个旅行网站。构建工具使用的是Ant和Cruise Control。代码库始终处于可发布的状态，并且每隔一周就将代码部署到生产环境。

我第一次在整个公司中实施持续交付，是2008年在LMAX公司。我们使用极限编程和领域驱动设计，使用Java 6、Spring 3和Resin 3编写了一个艺术品交易平台。构建工具依然使用的是Ant和Cruise Control，以及许多自定义的仪表盘。代码库依旧始终处于可发布状态，每隔两星期部署到生产环境一次。

我肯定你已经看出了其中的共同点。聪明的人会选择紧密的合作，因此我们选择了极限编程，并规定了良好的设计准则，然后根据手上的工作来合理选择使用的工具。我记得在LMAX公司工作期间，研发部门的领导也正在写一本关于持续交付的书，不过我已经记不清他的名字是叫Dafydd、Dev还是其他什么了。我想说的是，不管你使用Java、PHP还是.NET，都可以成功地实施持续交付。你可以使用Solaris Zones或者Docker，也可以使用AWS、Azure或者自己的数据中心（也许你的平台负责人会一直认为它比AWS更便宜）。你只需确保为要解决的具体问题选择了合适的工具。此外，不要使用MKS进行版本控制，不要使用QTP进行测试，也不要使用其他任何商业的发布管理工具，因为它们都太难用了。

那么现在问题来了，如果你真的认为只要选择了合适的工具就行，为什么我还要写这篇序言呢？

实际上，如果我们仔细思考一下，就会发现这里面的细微差别。与持续交付的原则和实践相比，工具可能并不重要，但是它们依然有非常重要的作用。编程语言不仅可以帮助人们快速创建新的功能和补丁，降低产品开发过程中的延期风险，而且有助于构建一个可测试、可发布的应用程序架构，这同样也是持续交付的一个关键目标。良好的构建、测试和部署工具，可以帮助人们向着TDD、基于Trunk开发等正确的实践方向上前进。

当我最近在打扫童年卧室的时候，发现了大学时Ivor Horton写的Uderstanding Java 2一书，于是我想起了一些往事。从1999年开始接触Java，我已经度过了近20个年头。在我的印象中，Java是一门伟大的编程语言。在这些年里，Java、JUnit、Gradle、Spring以及其他许多工具，帮助我构建了许多测试良好的、可发布的应用程序，并鼓励人们不断去接受持续交付的概念。

随着云计算、容器化以及无服务器架构逐渐成为现在的趋势，我们都需要经验丰富的人来告诉我们，如何使用最新的工具来实施持续交付。在本书中，Daniel和Abraham介绍了如何使用Java和Spring Boot、Kubernetes及AWS EKS等流行工具，实现高频率地交付现代化的Web应用程序，从而满足市场需求。通过Daniel和Abraham的讲解，相信任何使用Java的IT人员都可以学会，如何通过一系列工具让应用程序实现可持续性的交付。

—— Steve Smith Continuous Delivery 咨询公司的持续交付顾问

序二

持续交付是一门重要的实践技术，每个工程团队都应该铭记于心。我们经常被问到，是什么样的关键因素，使我们成功地运营了jClarity公司，以及在adoptopenjdk.net上创建了OpenJDK/Java。答案是，我们可以每天以最大的信心进行部署，并且用最小的工程团队来完成此事。自从Dave Farley和Jez Humble在 2010年开创性地编写了Continuous Delivery: Reliable Software Releases through Build,Test, and Deployment Automation（Addison-Wesley Signature）一书后，人们虽然已经逐渐开始接受持续交付的概念，但是仍然缺少一本完整指南，告诉近1000万名Java开发者如何做到这一点。现在，它终于出现了。

Daniel和Abraham都是持续交付的践行者，他们的书中包含了一名Java开发者需要了解的所有有关持续交付的内容，同时又对某些内容进行了深入的讲解，包括“为什么”你希望遵守持续交付的实践原则，如何设计一个符合持续交付的应用架构，如何将构建、测试及部署管道集成到一起，甚至还包括如何在错综复杂的云计算和容器环境中进行部署。

在如今的Java行业中，“云原生”概念的影响范围越来越大，现代应用程序必须开始考虑如何连接大量的外部组件（包括JVM和其他组件），以及通过一种非常不同的方式，处理以往由本地操作系统提供的资源（例如I/O）。甚至连应用程序的生命周期，以及它们与物理机器的关系都在发生变化，例如不可变架构和无服务器架构等，都在要求所有Java开发者不断更新自己的知识，以充分利用这些新的应用交付能力。

在如今这个崭新的世界中，持续交付的技术及其背后的工具和设计理念，以及面向云计算开发的模式已经变得越来越重要。到目前为止，还没有一本专门为Java开发人员编写的指南，指导他们如何完整地实施持续交付，并从中获益，而本书弥补了这一点。

—— Martijn Verburg jClarity 公司 CEO 及 LJC 领导人

第 1 章　持续交付 ：为什么需要持续交付，什么是持续交付....................1
入门知识 .......................................................................................................................1
赋能开发者 ：为什么我们要持续交付 ..........................................................................2
快速反馈会减少上下文切换 .................................................................................2
自动化的、可重复的以及可靠的发布...................................................................2
定义“完成”的概念 .............................................................................................3
什么是构建管道 ............................................................................................................4
核心的构建管道阶段 .............................................................................................4
容器技术的影响 ....................................................................................................7
对当前架构的影响 ................................................................................................8
总结 ..............................................................................................................................9
第 2 章　Java 开发的演化..............................................................10
现代 Java 应用程序的需求 .......................................................................................... 10
对业务增长速度和稳定性的要求 ........................................................................ 11
API 经济的崛起 .................................................................................................. 11
云计算的机会和成本 ........................................................................................... 12
模块化归来 ：拥抱更小的服务 ............................................................................ 12
对持续交付的影响 .............................................................................................. 13
Java 部署平台的演化 .................................................................................................. 13
WAR 和 EAR ：应用服务器统治的年代 .............................................................. 13
可执行的胖 JAR 文件 ：十二要素风格应用的出现 ............................................. 14
容器镜像 ：不断增加的可移植性（以及复杂性） ................................................ 15
函数即服务 ：“无服务器”架构的出现 ............................................................... 16
平台对持续交付的影响 ....................................................................................... 17
DevOps、SRE 和发布工程 ......................................................................................... 17
研发和运维.......................................................................................................... 18
站点可靠性工程 .................................................................................................. 19
发布工程 ............................................................................................................. 21
共享责任、指标和可观察性 ............................................................................... 22
总结 ............................................................................................................................ 22
第 3 章　设计持续交付的架构..........................................................24
优秀架构的基础 .......................................................................................................... 24
松耦合 ................................................................................................................. 25
高内聚 ................................................................................................................. 25
耦合、内聚和持续交付 ....................................................................................... 26
面向业务敏捷的架构 .................................................................................................. 27
不好的架构会限制业务的发展 ............................................................................ 27
复杂性和变更成本 .............................................................................................. 28
API 驱动的应用程序的最佳实践 ................................................................................ 29
“自上而下”构建 API ......................................................................................... 29
良好的 API 有助于持续测试和集成 .................................................................... 29
部署平台和架构 .......................................................................................................... 30
设计符合“十二要素”的云原生应用程序 ......................................................... 30
培养机械同理心 .................................................................................................. 33
面向失败的设计和持续测试 ............................................................................... 33
越来越小的服务 .......................................................................................................... 34
交付单体应用程序的挑战 ................................................................................... 34
微服务 ：当 SOA 遇到领域驱动设计 .................................................................. 35
函数、lambda 表达式和纳米服务（Nanoservices） ............................................. 36
架构 ：“难以改变的东西” ........................................................................................... 37
总结 ............................................................................................................................ 38
第 4 章　Java 应用的部署平台、基础设施以及持续交付......................39
由平台提供的功能性 .................................................................................................. 39
基本的开发流程 .......................................................................................................... 40
传统的基础设施平台 .................................................................................................. 41
传统的平台组件 .................................................................................................. 41
传统基础设施平台面临的挑战 ............................................................................ 41
传统基础设施的好处 ........................................................................................... 42
传统基础设施平台上的 CI / CD .......................................................................... 42
云平台 ......................................................................................................................... 43
深入云计算.......................................................................................................... 43
云计算面临的挑战 .............................................................................................. 45
云计算的好处 ...................................................................................................... 46
云计算中的持续交付 ........................................................................................... 47
平台即服务 ................................................................................................................. 47
简单了解 PaaS 的原理 ......................................................................................... 48
PaaS 平台面临的挑战.......................................................................................... 48
PaaS 的好处 ........................................................................................................ 50
CI/CD 和 PaaS .................