测试自动化和交付管道
你已经了解了软件和服务的持续部署和交付，但这两者实际上是“三件套”的一部分。 DevOps 实践旨在实现持续的集成、部署和交付。
现在，可以备份并讨论其中的第一项：集成。 这是开发过程的一部分，在部署之前进行。 DevOps 建议一种开发实践，其中团队成员经常将代码集成到包含单一“main”或“trunk”代码库的共享存储库中。 目标是让每个人都参与要发布的代码，而不是对其副本进行工作，并仅在最后一刻将所有内容汇总在一起。
然后，自动测试可以验证每个团队成员的集成。 在每次更改和添加之后，该测试有助于确定代码是否“健康”。 该测试是我们通常称为“管道”的过程中的一部分。 由于本单元将重点介绍集成的测试和交付管道，因此我们将稍后介绍管道。
持续交付管道
要了解自动测试在持续交付部署模型中的作用，需要查看它在交付管道中的适合位置。 持续交付管道是在开发过程中经历更改的步骤代码集的实现，然后再将该步骤代码集部署到生产。 以下是简化交付管道中示例步骤的图形表示：
让我们分步介绍此管道。
当代码或基础结构更改提交到代码存储库（可能使用拉取请求）时，管道实例开始。
接下来的单元运行的可能是集成测试或端到端测试，在理想情况下，这些测试结果将传回请求方。
此时，系统可能会扫描存储库中的代码以查找机密信息、漏洞和配置方面的内容。
在所有内容检查完毕后，便会生成代码并为部署做好准备。
接下来，将代码部署到测试环境。 某人可能会收到有关新部署的通知，以便对生产前解决方案有所了解。 然后，该人员可以批准或拒绝用于生产的部署，这将启动将代码发布到生产的部署过程的最后一部分。
在此管道中，可以看到集成和部署之间的界限。 红色标记指出了一些逻辑位置，可以在其中通过包括的逻辑和自动化甚至可能的人为干预来停止管道。
用于持续集成和交付的工具：Azure Pipelines
要使用持续集成和持续交付，需要使用正确的工具。 Azure Pipelines 是 Azure DevOps Services 的一部分，可用于自动生成和一致地测试代码。 还可以使用 Azure Pipelines 将代码部署到 Azure 服务、虚拟机以及云中和本地的其他目标。
管道的输入（我们的代码或配置）驻留在版本控制系统中，例如 GitHub 或其他 Git 提供程序。
Azure Pipelines 在一段计算上运行，例如虚拟机或容器，提供运行 Windows、Linux 和 macOS 的生成代理。 它还提供与测试、安全性和代码质量插件的集成。最后，它易于扩展，因此你可以将自己的自动化功能引入 Azure Pipelines。
管道是使用 YAML 语法或通过 Azure 门户中的经典用户界面进行定义的。 使用 YAML 文件时，可以将该文件与代码一起存储。 管道还提供了可用于轻松创建管道的模板；例如，用于生成 Docker 映像或 Node.js 项目的管道。 还可以重复使用现有 YAML 文件。
无论你使用的是 YAML 文件还是经典界面，下面的步骤都是基本步骤：
- 将 Azure Pipelines 配置为使用 Git 存储库。
- 通过编辑 azure-pipelines.yml 文件或使用经典编辑器都可以定义生成。
- 将代码推送到版本控制存储库。 该操作将触发管道生成并测试代码。
在更新、生成并测试代码后，即可将该代码部署到所需的任何目标。
有些功能（例如运行容器作业）仅当使用 YAML 时才可用，而其他功能（例如任务组）仅在使用经典界面时才可用。
Azure 管道构建
管道的结构如下所示：
作业：作业是在一个生成代理上运行的一组任务或步骤。 作业是可计划运行的最小工作组件。 作业中的所有步骤按顺序运行。 这些步骤可以是你想要的任何类型的操作，包括生成/编译软件、准备要测试的样本数据、运行特定测试等等。
阶段：阶段是相关作业的逻辑分组。
每个管道至少有一个阶段。 使用多个阶段将管道组织为主要部分，并在管道中标记可以暂停和执行检查的点。
管道可以很简单，也可以很复杂。 有一些关于管道构建的优秀教程，这些教程是“使用 Azure DevOps 构建应用程序”学习路径中的一部分。
环境可跟踪性
管道的另一方面涉及可靠性，值得一提。 可以采用如下方式构建管道：即可以将生产中运行的内容与特定生成实例相关联。 理想情况下，我们应能够将生成追溯到特定 PR 或代码更改。 在事件发生期间或之后的事后评审中，如果你尝试确定导致问题发生的更改，则这种做法可能非常有用。 某些 CI/CD 系统（例如 Azure Pipeline）使执行此操作变得容易，而另一些 CI/CD 系统则要求你手动构建一个在所有阶段中传播某类“生成 ID”的管道。