AZ-400管道风格对比：YAML管道vs经典管道、托管代理vs自托管代理，到底怎么选？

AZ-400管道风格对比：YAML管道vs经典管道、托管代理vs自托管代理，到底怎么选？

【免费下载链接】AZ400-DesigningandImplementingMicrosoftDevOpsSolutionsAZ-400 Course Repository for Labs and Demos.项目地址: https://gitcode.com/gh_mirrors/az/AZ400-DesigningandImplementingMicrosoftDevOpsSolutions

备考AZ-400（Designing and Implementing Microsoft DevOps Solutions）或刚接手Azure DevOps项目时，几乎每个人都会遇到同一个灵魂拷问：管道（Pipeline）到底用YAML管道还是经典管道？代理（Agent）到底用托管代理还是自托管代理？这两个选择看似简单，却直接决定了你的CI/CD架构、维护成本和团队协作方式。本篇文章基于AZ-400官方实验仓库，用最直观的对比表格和实战步骤，帮你彻底搞懂四种组合的适用场景，一次选对不返工。

为什么管道风格和代理选择如此重要

Azure DevOps的CI/CD体系由两大部分组成：管道定义（Pipeline Definition，描述构建和发布流程）和代理池（Agent Pool，提供实际执行任务的计算资源）。AZ-400考试大纲中，这两块内容分别对应配置代理池和理解管道风格与以YAML配置管道即代码两个核心实验。选错任何一项，轻则维护成本翻倍，重则让整个发布流程陷入"黑盒"困境。

一、YAML管道 vs 经典管道：两种管道风格全面对比

YAML管道（Pipeline as Code）凭什么成为主流

YAML管道把CI/CD流程写成仓库里的.yml文件，与源代码放在一起管理。它的核心优势非常明显：

• 版本可控：管道定义和代码同仓库、同分支、同Pull Request评审，每一次改动都有历史记录。
• 复用性强：支持模板（Templates）、变量组和条件表达式，多项目间可以共享管道片段。
• 多阶段编排：一个YAML文件即可串联构建（Build）、部署（Deploy）多个Stage，还支持环境审批（Approvals）等检查机制。

在配置管道即代码实验中，你只需要把eshoponweb-ci.yml提交到仓库的.ado目录，然后在 Pipelines 界面选择"Existing Azure Pipelines YAML File"即可完成管道创建，全程零界面拖拽。

经典管道（Classic Release Pipeline）还有用武之地吗

经典管道采用可视化设计器（Visual Designer）拖拽任务，构建和发布分离管理。虽然看起来"过时"，但在以下场景依然有优势：

• 团队完全没有代码化习惯，业务人员也能上手维护。
• 依赖成熟的发布门禁（Quality Gates）、手动审批流等高级功能。
• 历史遗留项目迁移成本过高。

值得注意的是，在使用发布门禁控制部署实验中提到，Azure DevOps可以在项目设置中关闭"经典发布管道创建"开关，微软推动YAML化的意图非常明显。新项目无脑选YAML管道，老项目视维护成本决定迁移时机。

YAML管道 vs 经典管道快速对比表

二、托管代理 vs 自托管代理：代理池选择指南

无论选哪种管道风格，最终都需要代理（Agent）来跑任务。代理可以运行在宿主机的操作系统上，也可以运行在容器里，而代理的来源只有两种：微软帮你管好的托管代理，和你自己搭的自托管代理。

托管代理（Microsoft-hosted Agent）的最大优点

在YAML管道中，一行vmImage就能指定托管代理，例如：

pool: vmImage: ubuntu-latest

托管代理的优势在于零运维：微软维护操作系统镜像、预装常用SDK和工具，用完即走、按分钟计费。对于标准化的构建任务（如.NET还原、编译、测试、发布），托管代理是最省心的选择。AZ-400实验中的CI管道默认就使用ubuntu-latest镜像。

自托管代理（Self-hosted Agent）适合什么场景

当你遇到以下情况，就该考虑自托管代理了：

• 需要特定软件或证书：比如内网私有源、专用编译工具链、商业许可证校验。
• 数据合规要求：代码和构建产物不允许离开公司网络。
• 构建任务耗时且频繁：长期跑满托管代理配额，自托管代理的固定成本更划算。
• 需要访问内网资源：数据库、测试环境、Kubernetes集群等内网服务。

如何创建自托管代理池（保姆级步骤）

1. 准备一台机器：可以是Azure VM（参考创建虚拟机），也可以是本地服务器。

2. 在Azure DevOps中创建代理池：进入项目设置 → Pipelines → Agent Pools → Add pool，选择Self-hosted类型，命名如eShopOnWebSelfPool。

3. 下载代理并配置：在代理池的 Agents 标签页点击 New agent 下载对应平台安装包，解压后运行config.cmd（Windows）或config.sh（Linux），依次填入组织URL、PAT令牌和代理池名称。

4. 验证代理状态：回到 Agents 标签页，看到绿色圆点且状态为 Idle（空闲），说明自托管代理已就绪。

在YAML管道中指定自托管代理池

把vmImage替换为代理池名称即可，甚至可以加上demands精确匹配特定代理：

pool: name: eShopOnWebSelfPool demands: Agent.Name -equals eShopOnWebSelfAgent

三、AZ-400实战：结合eShopOnWeb项目一次练会四种选择

纸上谈兵不如动手验证。你可以直接克隆AZ-400实验仓库https://gitcode.com/gh_mirrors/az/AZ400-DesigningandImplementingMicrosoftDevOpsSolutions，按以下顺序完成练习：

1. 先体验托管代理：完成启用Azure Pipelines持续集成实验，用ubuntu-latest跑通CI，理解YAML管道的基础语法和PR验证。
2. 再挑战自托管代理：完成配置代理池和理解管道风格实验，亲手搭建VM、创建代理池、把管道切换到自托管代理并观察运行差异。
3. 最后打通多阶段部署：在配置管道即代码实验中，给YAML管道添加Deploy Stage和环境审批，体验完整的CI/CD闭环。

总结：四种组合到底怎么选

最后给一个AZ-400备考小贴士：考试中关于"管道风格"和"代理类型"的题目，本质都在考察可维护性与成本的权衡。牢记"新项目选YAML、标准构建选托管、特殊依赖选自托管"这个口诀，选择题基本不会丢分。现在就去克隆实验仓库动手跑一遍吧，实践一次比背十遍文档都管用！

【免费下载链接】AZ400-DesigningandImplementingMicrosoftDevOpsSolutionsAZ-400 Course Repository for Labs and Demos.项目地址: https://gitcode.com/gh_mirrors/az/AZ400-DesigningandImplementingMicrosoftDevOpsSolutions