Java持续交付 - (EPUB全文下载)

文件大小：0.36 mb。
文件格式：epub 格式。
书籍内容：

Java持续交付
第1章　持续交付：为什么需要持续交付，什么是持续交付
第2章　Java开发的演化
第3章　设计持续交付的架构
第4章　Java应用的部署平台、基础设施以及持续交付
第5章　构建Java应用程序
第6章　其他构建工具和技巧
第7章　打包应用程序
第8章　在本地环境中工作（就像在生产环境中一样）
第9章　持续集成：创建构建管道的第一步
第10章　通过管道进行部署和发布
第11章　功能性测试：正确和接受度
第12章　系统质量属性测试：验证非功能性需求
第13章　可观察性：监控、日志和跟踪
第14章　迁移到持续交付
第15章　持续交付和持续改进
第1章　持续交付：为什么需要持续交付，什么是持续交付
在本章中，你将了解到持续交付的核心概念，以及它能够带给开发人员、QA、运维和业务团队的好处。在开始改变工作方式之前，我们必须问一个重要的问题—为什么。在这一章中，你将学习到如何通过快速反馈来减少上下文切换， 如何通过自动化的、可重复的、可靠的发布流程，减少软件交付过程中的压力和挑战，以及如何定义“完成”的概念，使得快速验证和审计变成可能。最后，你将了解到一个典型的Java持续交付构建管道是什么样子的，以及有关管道中每个阶段的基本知识。
入门知识
基本上来说，持续交付（Continuous Delivery，CD）是一套实践和准则，能够让团队在短时间内交付有价值的、稳定的软件。我们要小心确保每次增加的功能不能太多，才可以保证软件随时可以发布。从业务和技术角度来看，这最大限度地增加了快速反馈和学习的机会。在2010年，Jez Humble和Dave Farley出版了他们开创性的著作Continuous Delivery （Addison-Wesley）（https://continuousdelivery.com/），该书整理了他们在全球范围交付软件项目的经验，并且目前依然是持续交付领域的首要参考材料。而本书从技术和组织的角度，提供了一系列有价值的技术、方法和建议。
在过去的二十年中，软件开发和交付领域发生了很大变化。首先是业务的需求和期望发生了巨大变化，重点开始关注创新、速度和投入市场的时间。架构师和开发人员随后也做出了相应的改变，并且设计了新的架构来满足这些需求。新的部署功能和平台不断出现，并与DevOps、发布工程（Release Engineering）和站点可靠性工程（Site Reliability Engineering，SRE）等新方法共同发展。除了这些变化之外，创建持续交付构建管道的最佳实践也在发展。持续交付的核心是，对于所交付软件的任何功能变更，在决定将它部署到生产环境之前，一定要经过构建、集成、测试和验证的过程。
在本书中，你将专注于如何为现代的Java应用程序—无论是单体架构、微服务架构或者是函数即服务（FaaS）架构的应用程序，创建一个有效的构建管道。
赋能开发者：为什么我们要持续交付
在我们开发任何一个主要功能之前，都应该问一个重要的问题，“为什么”。作为一名Java开发人员，我们为什么要将宝贵的时间用在持续交付和创建构建管道上呢？
快速反馈会减少上下文切换
反馈对于处理复杂系统至关重要，而现在几乎所有的软件应用程序都是复杂的可适应性系统。对于如今基于组件的Web应用更是如此，基本上都是分布式的系统。翻一下过去20年的IT杂志就可知道，只有在发生大型的（昂贵的）故障时，才会暴露出软件开发过程中的问题。持续、快速和高质量的反馈能够更早地发现和修复错误。这也使得问题的影响范围更小、代价更低，并且更容易被修复。
快速反馈可以增加业务的竞争优势
在Accelerate （IT Revolution Press）（https://itrevolution.com/book/accelerate/）一书中，Nicole Forsgren、Jez Humble和Gene Kim认为，所有行业的组织都会逐渐抛弃交付周期较长的大型项目，转为采用短周期的小型团队，通过不断收集用户的反馈意见，打造能够满足客户需求并快速交付价值的产品。除了技术方面的指标，你还可以与业务团队密切合作，收集反馈，从而确定需要实现的关键绩效指标（KPI）和相关指标。
从开发人员的角度来看，快速反馈的一个显著优势是，降低了上下文切换的成本，并且避免了用一段包含bug的代码来记录工作。显而易见的是，我们解决一个5分钟前的问题，肯定要比解决一个5个月之前的问题要容易得多。
自动化的、可重复的以及可靠的发布
为了让开发团队尽量在白天工作时间完成工作，构建管道必须为开发团队提供快速的反馈，并且对管道的操作必须具有高度的可重复性和可靠性。因此，我们普遍采用自动化方式来构建管道，目标是使其尽可能达到100%的自动化操作。以下事项都是应该被自动化的：
·软件编译和代码质量静态分析。
·功能性测试、包括单元测试、组件测试、集成测试以及端到端测试。
·所有环境的配置，包括日志集成、监控和报警。
·将软件构件部署到所有环境的过程，包括生产环境。
·数据存储迁移。
·系统测试，包括容错测试、性能测试和安全测试等非功能测试。
·变更历史记录的跟踪和审计。
用“左移”原则思考和测试
在持续交付的安全验证或者验收测试阶段，我们经常听到别人谈论“左移（Shifting Left）”原则。“左移”原则的核心思想是，将那些通常在较晚阶段完成的工作，尽早提前完成，这样可以提高交付的质量，或者降低那些在交付最后阶段发现的问题的修复成本。在我们的示例中，相当于在开始设计某个新功能之前，先去咨询InfoSec团队或者建立某些风险模型，或者鼓励开发人员先去实现自动化的验收测试，以便可以在构建管道的测试阶段自动运行。持续集成可以促进我们使用“左移”原则思考问题，因为构建管道不仅提供了一个可视化的手段，可以用来验证从编码到部署等的过程，还提供了一个可以实现自动化验证的框架。
在发布流程实现了自动化（可以重复并且可靠地执行）之后，开发人员或者运维人员就可以自信地不断发布新的 ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。