Java持续交付

为什么我们要写这本书
我们俩已经从事 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 应用程序实施持续交付的完整过程，因此，我们无法重点深入讲解其中与架构、测试或者云计算相关的每个技术点。因为许多章节都可以拿出来单独写一本书，所以我们只能尽可能地介绍主要的内容。考虑到已经有人编写了相关主题的书籍，所以我们在附录中附上了这些书单，供你参考。

译者序
在软件、互联网行业工作十余年后，我越来越认识到，软件开发不仅仅是一项技术，更是一项复杂的工程。我们必须始终清晰地认识到，软件开发的终目的，是将软件的价值交付给客户，这需要我们调动所有的技能、知识和经验，（也许）才能做到。虽然这些年我们不断在拓展语言的能力，例如，从静态语言、动态语言到函数式编程，不断定义新的架构，例如，从单体架构、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软件开发的整个生命周期，还结合大量的成功实践经验，介绍了每个阶段可能会使用到的工具和技能。在基础设施已经极大完善的今天，本书还与时俱进地介绍了如何在Docker、Kubernetes、Cloud、FaaS等新兴环境下进行持续集成和持续交付。

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

第 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 
发布工程 ............................................................