Java持续交付

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余万字。

适读人群 ：学生，包括研究生和本科生，还有专业人士。

持续交付为业务的持续发展和整个软件的交付周期增加了巨大的价值，但是掌握这项技术就意味着普通开发人员要跳出舒适区，学习很多新技能。本书以实践为基础，作者 Daniel Bryant 和Abraham Marín-Pérez通过大量的实践指导，帮助Java开发人员掌握针对不同平台的架构设计、自动化质量保证， 以及打包和部署的技巧。
· 你将获得一些理解核心概念的帮助，以及有助于向持续交付迁移的指导意见。
· 你将学会如何设计能在不同平台上持续交付Java应用程序的架构。
· 你将学会如何构建应用程序构件，包括胖JAR文件、虚拟机镜像，以及操作系统容器（Docker）镜像。
· 你将学会如何使用Jenkins、PMD和FindSecBug等持续集成工具自动化地进行代码质量检查。
· 你将学会如何创建一个复杂的构建管道，以及如何设计独立的部署和发布流程。
· 你将了解为什么功能测试和系统质量属性测试对于开发和交付非常重要。
· 你将学会如何在本地有效地构建和测试应用程序，以及监控生产环境中运行的应用程序。

译者序
在软件、互联网行业工作十余年后，我越来越认识到，软件开发不仅仅是一项技术，更是一项复杂的工程。我们必须始终清晰地认识到，软件开发的最终目的，是将软件的价值交付给客户，这需要我们调动所有的技能、知识和经验，（也许）才能做到。虽然这些年我们不断在拓展语言的能力，例如，从静态语言、动态语言到函数式编程，不断定义新的架构，例如，从单体架构、SOA 到微服务，不断开发更好用的框架，例如，从Java EE、Spring 到 Spring Boot 等，甚至不断努力学习更多的方法论，例如，从瀑布模式、敏捷模式到各种混杂的开发模式，我们却依然不得不承认，软件开发是一件很难的事情，经常会超出我们的掌控范围。究其原因，终究还是因为这是一项工程，意味着我们必须时刻关注它的过程，而不仅仅是结果。在这个过程中，会夹杂很多不可控的因素，例如，能力、需求、环境、甚至人的情绪等，我们需要不断调整、修正这个过程，才可能让它始终保持在一个方向正确但是不那么笔直的道路上。
很难说清楚，如今的软件开发究竟是越来越分工化，还是越来越全能化，在中国的特殊情况下，也许两者都对。对于 Java 开发人员来说，我们现在很少会希望他们去开发前端代码，但是需要他们越来越懂得如何部署、运行自己的程序。基础设施的升级让我们不太可能在本地环境上运行自己的程序，而是需要在 Docker、Kubernetes、Cloud 等环境上运行。这同时也在考验我们持续交付软件价值的能力，让我们不得不与时俱进地引入新的工具、提升新的技能。如果 Java 开发人员能够越早跳出自己的舒适区，并从宏观和细节层面了解开发软件的生命周期，就越能够快速在开发过程中不断地得到反馈和进行构建。他们无疑将会更好地跟上时代发展的潮流，更好地提升自己的业务水平。
我很高兴能有这样一本书，不仅完整介绍了软件开发的各个阶段，还能够详细介绍各个阶段需要使用的工具，从而将理论和实际很好地结合在一起。无论你是开发经验丰富的Java 熟手，还是希望了解 DevOps 的新人，我相信你都能从这本书中获得宝贵的知识和经验。鉴于个人经验和能力的不足，如有遗漏和错误之处，还请各位读者包涵、批评和指正。
感谢我的家人对我无微不至的照顾，感谢身边的同事和朋友对我的支持。
——张若飞 2019 年 8 月 北京

序一
自从 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 领导人
—— Ben Evans 作家及咨询公司 CTO

前言
为什么我们要写这本书
我们俩已经从事 Java 开发很多年了，也见证了行业内的几次变迁。从我们编写第一行Java 代码算起，Java 语言已经有了长足的发展 ：Java 1.4 增加了非阻塞 I/O，Java 8 增加了 streams 和 lambda 表达式，Java 9 引入了模块化，以及 Java 10 最终引入了局部变量类型推断。部署平台也有了突飞猛进的发展，云计算和容器的出现带来了许多机会和挑战。但是，有一件事始终没有发生过变化，那就是将价值交付给终端的用户和顾客。我们需要尽可能地使用所有的技能、工具和经验，将软件尽可能有效（以及有趣）地交付给用户。也许更重要的是，我们需要相互合作，带领我们的团队一起来承担这一责任。
围绕着软件开发、架构和部署平台，出现了越来越多的“最佳实践”，开发人员通常都认可这一观点 ：持续集成和持续交付，为软件交付的生命周期带来了巨大的价值。随着客户对交付速度和稳定性的要求不断增加，你需要一个能够快速得到反馈，并且能够自动完成质量保证和部署流程的框架。然而，现代软件开发人员所面临的挑战来自多个方面，当我们试图引入一种新方法时，例如持续交付（它涉及软件设计和交付的许多方面），就意味着某些开发人员必须跳出当前的舒适区，去学习一些自己不熟悉的新技能。
随着职业上的发展，我们经常会发现自己已经站在了前人的肩膀上，因此，我们经过不断地总结经验，已经知道，以下三个关键技能对成功实施持续交付至关重要。
· 架构设计：正确实现一个松耦合、高内聚的系统架构，会对持续测试和组件部署产生巨大的帮助作用。
· 自动化质量保证：架构会随着不断增长的业务需求变化（例如单体架构、微服务、函数即服务等），意味着我们现在通常都在测试各种分布式的、环境复杂的系统。这些系统通常无法用传统的手工方式重复、有效地进行验证和校验。
· 部署应用程序：云计算和容器技术的出现重新定义了 Java 应用程序的部署方式，为了能够创建自动化、安全的部署和发布流程，我们需要学习很多新的技能。本书将我们要学习的内容进行了提炼，并且为学习这些新技能提供了指导。
为什么你应该阅读本书
如果你是一名希望了解持续交付，并且目前受困于如何交付软件的 Java 开发人员，那么本书就是为你量身定制的。我们不仅会告诉你如何使用持续交付的各种工具和实践“方法”，还会告诉你“为什么”。我们相信这一点对你非常重要，因为一旦理解了背后的动机，你就会明白它们是否真的适合你。理解了方法背后的原因，也会帮助你建立扎实的基础，有助于你将这些想法分享或传授给其他人。正如日本诗人松尾芭蕉（Matsuo Bashō) 所
说，“不要追随智者的脚步，去寻求他们所寻求的东西。”
同时，我们编写本书也是为了给读者敲响一个警钟，作为一名 Java 开发者，应该早日跳出自己的舒适区，去学习更多有关架构、自动化和运维的知识。在如今的软件开发行业中，我们看到纯 Java 编程的职位已经变得越来越少，而许多新职位都需要掌握持续交付、平台和运维工具等知识。通过不断增加软件开发的知识和技能，你获得的将不只是更多的工作机会，还会成为一个更好的编程人员。
在编写本书的过程中，我们只想象着读者是一名 Java 开发者，并没有考虑其他的可能，但是相信以下几类读者也会感到共鸣。
· 传统的企业级 Java 开发者：你多年都在编写 Java EE 或者 Spring 应用程序，但是现在意识到，公司里新的应用程序都在围绕微服务化的架构来设计，同时系统管理或运维团队正在尝试使用云计算、Docker 和 Kubernetes。你迫切希望了解更多与构建 Java 应用相关的变化，以及如何通过自动化方法来简化测试和部署工作。
· 希望拥抱 DevOps 的 Java 开发者：你开发 Java 应用程序已经有几年了，并且关注了一些介绍云计算、DevOps 和网站可靠性工程（Site Reliability Engineering，SRE）的博客、书籍和会议演讲。你可能很羡慕像 Netflix、Google 或者 Spotify 这些公司的开发实践，但是你明白他们所做的事情并非都适合你和你的团队。不管怎样，你渴望了解更多，以及如何利用相关技术向 DevOps 转型。
· 刚刚毕业的大学生：你刚刚开始第一份软件开发的工作，虽然之前在学校中学习了很多具体的编程技能，但是你认识到，你还不知道如何将这些技巧和工具结合起来，有效地交付软件。你希望了解更多有关整个软件交付流程的知识，以填补你知识体系中的空白，并且将所有已会的技能结合起来，从而促进职业生涯的发展。
这本书不包括什么内容
本书重点介绍对 Java 应用程序实施持续交付的完整过程，因此，我们无法重点深入讲解其中与架构、测试或者云计算相关的每个技术点。因为许多章节都可以拿出来单独写一本书，所以我们只能尽可能地介绍主要的内容。考虑到已经有人编写了相关主题的书籍，所以我们在附录中附上了这些书单，供你参考。

第 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 .................