简介
本模块介绍部署模式，说明微服务的体系结构，以帮助改进部署周期，并探讨经典部署和新式部署模式。
持续交付是持续集成的扩展。 持续集成与快速向客户推出更改和使用可持续方法相关。
持续交付则更进一步，是将通过生产管道传递的更改发布给客户。
持续交付不仅涉及发布管理。
持续交付涉及确保按需交付软件所需的流程、人员和工具。
部署只是持续交付过程中的一个步骤。 若要每天按需或多次进行部署，需要满足所有先决条件。
例如：
测试策略
须制定好测试策略。 如果需要运行许多手动测试来验证软件，这将成为按需交付的瓶颈。
编码规范
如果软件不是以安全且可维护的方式编写的，则有可能无法保持较快的发布节奏。
如果软件因大量技术债务而变得复杂，就很难快速可靠地更改代码。
编写高质量的软件和高质量的测试是持续交付的重要环节。
体系结构
应用程序的体系结构始终很重要。 但在实现持续交付时，可能更是如此。
如果软件是一个其中各组件之间有许多紧密关联的整体，那么持续交付软件会比较困难。
经过更改的部分可能会影响其他未经过更改的部分。 可通过自动执行的测试来跟踪许多意外的依赖项，但仍然会很困难。
与不同的团队合作时，还存在时间方面的问题。 当团队 A 依赖团队 B 的服务时，团队 A 只能等到团队 B 完成相关工作时才能交付。 这会为交付带来另一个限制。
大型软件产品的持续交付非常复杂。
较小部分的交付相对简单。 因此，在许多情况下，将软件分解为较小的独立部分是一个不错的解决方案。
解决这些问题的一种方法是实现微服务。
持续集成是 DevOps 的关键核心之一。
在版本控制系统中引入代码后，需要一种自动化方法来持续集成代码。
可以使用 Azure Pipelines 创建功能齐全的跨平台 CI 和 CD 服务。
它可处理你首选的 Git 提供程序，并可部署到最主要的云服务（包括 Azure）。
此模块详细介绍了持续集成做法，以及用于在开发生命周期中实现它的核心、其优点及属性。
学习目标
完成本模块后，学生和专业人员能够：
- 介绍部署模式。
- 说明微服务体系结构。
- 了解经典部署模式和新式部署模式。
- 规划和设计体系结构。
先决条件
- 了解什么是 DevOps 及其相关概念。
- 熟悉版本控制原则会有所帮助，但这不是必需的。
- 如果有过在提供软件的组织中工作的经验，会很有帮助。