Azure DevOps Pipeline 入门：从零搭建你的第一条 CI/CD 自动化流水线

简介：《Azure DevOps Pipelines 操作手册》是一份面向开发与运维人员的 Azure DevOps CI/CD 实战文档，针对需要构建持续集成与持续交付流程的团队，系统讲解从创建第一个管道到多环境部署的全流程。内容涵盖经典发布管道、YAML 架构、代理配置、条件与表达式、作业/阶段/任务/模板/触发器核心概念，并提供 GitHub、Azure Repos、Bitbucket 等仓库集成，以及容器、.NET Core、Java、Python、Node.js、Android、AKS 等多语言与多平台生态的示例。同时包含代理池管理、服务连接、设置保留策略、与 Slack/Teams 集成及疑难解答等扩展实践，既适合初学者快速入门，也能帮助中级人员查漏补缺。资源包以 1 个 PDF 文件收录，整体约 106.6MB，文档结构清晰，便于按需检索浏览。已有 412 人查阅学习，对于希望系统掌握 Azure Pipelines 各模块并直接参考官方方法落地 CI/CD 的读者，是值得收藏的高质量手册。

1. 先搞懂它是谁：一条帮你自动干活儿的管线

第一次接触 Azure DevOps Pipeline（azure devops pipeline）的人，十有八九会被“持续集成”“持续交付”这两组词吓住，以为又是什么高深的理论。其实它的核心只有一句话：让一台远程机器一直盯着你的代码仓库，只要你有代码提交上去，它就自动开始编译、跑测试、打包，甚至按设定把成品部署到服务器。这套自动化的过程，就是持续集成（CI）与持续交付（CD），而 Azure Pipelines 就是把这些步骤串成一条自动流水线的工具。它支持 Node.js、Python、Java、.NET 等几乎所有主流语言，还能直接对接你现有的代码仓库。如果你正被“每次改完代码都要手动打包、传服务器、重启服务”折磨，这篇文章就是给你写的：从零讲起，直到你亲自跑通第一个管道。

2. 为什么要学 CI/CD：先摆脱“手动上线”这口锅

先说一个场景。你写了个小网站，本地跑得好好的，要上线了：先在本地打包，压缩成 zip，打开终端用 ftp 或者 scp 把文件传上服务器，登录服务器，停掉旧进程，解压覆盖，再重启服务。这一套流程你一周可能要重复七八次。第一次做觉得新鲜，第十次开始烦，第三十次就会忍不住想：能不能让机器替我做？

CI/CD 解决的就是这件事。它把“从代码提交到部署上线”这条路上所有机械的、重复的、容易手抖出错的步骤，全部交给自动化管线执行。你只负责写代码和提交代码，剩下的编译、测试、打包、部署，由管道代劳。听起来很美好，但很多新手直接上手时会被概念术语劝退。所以这一章先不讲术语，只讲三件事：持续集成是什么、持续交付是什么、以及什么样的人现在就该学。

2.1 持续集成不是玄学：它是“每次提交都有人帮你体检”

持续集成（Continuous Integration，缩写 CI）翻译成大白话就是：每次你把代码推送到代码仓库，系统就自动帮你做一次体检——能不能编译通过，测试跑不跑得过去，有没有明显问题。

想象一下你和一个同学合写一份报告。你们约定每人写一章，最后合并。如果俩人都闷头写了两周才合到一起，结果格式对不上、数据口径不一致，改起来天翻地覆。换一种方式：每写完一小节就立刻合并一次，合并完马上做一遍自动检查，有问题当场改。第二种方式看起来麻烦，实际上才是真正省时间的。CI 就是这个“每写完一小节就自动检查一次”的机制，只是它检查的是代码：能不能编译、测试是否通过、有没有引入新的错误。

Azure Pipelines 在这里扮演的角色是一个不知疲倦的检查员。你推代码，它就跑一遍构建和测试；你的团队里任何一个人推了代码，它也跑一遍。这样代码一旦出现问题和漏洞，往往在提交后几分钟内就会暴露出来，而不是上线前夜才惊悚地发现。

这带来的直接好处是：修复成本大幅降低。开发周期早期发现一个 bug，可能改一行代码就解决了；等上线后用户发现了再修，得走完排查、定位、修复、验证、发布一整套流程，成本高好几倍。CI 的目的就是把这个发现时机尽量往前提。

2.2 持续交付也没那么高深：把“最后一公里”一并自动化

持续交付（Continuous Delivery，缩写 CD）是 CI 的下半场。CI 帮你完成“体检”，把项目变成可发布的产物；CD 负责把这个产物自动送到目标环境，比如测试服务器、预发布环境，甚至生产环境。

打个比方。CI 就像厨房里的自动洗菜切菜机，把食材处理得干干净净装进盘里；CD 则像传菜机，自动把菜送到指定餐桌。你不需要亲自端盘子跑厨房，只需要设定好“这道菜送到几号桌”，剩下的事它自己完成。

实际开发里，一个应用往往要经历多个环境：开发环境、测试环境、预发布环境、生产环境。手动往每个环境部署一遍，又慢又容易出错——漏改一个配置、传错一个包、忘记更新数据库对接地址，都是经典翻车原因。CD 的价值在于，让同样一套构建产物在不同环境之间流转，每个环境执行差不多的部署脚本，配置不同而已。这样“测试环境验证过的东西”和“上生产的东西”是同一个产物，最大程度避免“测试没问题、上线就出错”的尴尬。

当然，“自动部署到生产环境”这件事对不同团队有不同的尺度。有些团队追求完全自动发布，有些团队会保留一个“人工审批”步骤：管道把一切准备好，最后一步必须由负责人点一下确认才真正生效。Azure Pipelines 里这个机制叫审批，就是你可以在某个阶段前设一道门槛，必须是特定的人确认后才能继续。对新手来说，这反而是一种安全网：自动化程度可以循序渐进，没必要一上来就把所有环节都放开。

2.3 三种人最适合现在就上手

既然 CI/CD 听起来这么好，那到底值不值得现在学？结合我见过的情况，下面三类人收益最大。

第一种是独立开发者或做课程项目的新手。一个人维护项目时，版本管理往往比较随意，更没有“测试、构建、发布”的规范流程。引入一条简单的管道，等于强制自己把流程立起来。哪怕只是“每次提交代码后自动跑一遍测试”，长期坚持下来代码质量也会明显提升。

第二种是小团队成员。几个人同时向一个仓库里推代码，手工合并、手工打包、手工部署，时间都耗在这些重复动作上。把构建、测试、发布流程用管道自动化之后，大家的工作重心就能回到写代码本身。

第三种是准备往 DevOps 方向走的人。现在很多岗位描述里都写着“熟悉 CI/CD，了解持续集成和持续交付”，而 Azure Pipelines 是工业界应用非常广泛的一套方案，生态完善、文档齐全，用它入门 CI/CD 概念，再去看 Jenkins、GitHub Actions 等同类工具会轻松很多。

所以，学 Azure Pipelines 不是赶时髦，而是补一个现代开发者的基本功。接下来我就带你从注册开始，一步步把第一个管道跑起来。

3. 跑前准备：注册一个组织，把代码放进版本控制

在动手写管道之前，需要先备齐三样东西：一个 Azure DevOps 组织、一个代码仓库、一个想清楚的项目类型。这三件事都不难，但顺序搞反了容易多走弯路。我见过不少新手一上来就直接在网页里新建 Pipeline，结果发现没有代码仓库可选，又返工去建仓库。所以这一章按正确顺序给你铺路。

3.1 注册 Azure DevOps：十分钟拿到一个组织

Azure DevOps 是 Azure 提供的一套开发协作服务，Azure Pipelines 只是其中的一个模块。你不需要装任何本地软件，所有操作都在网页上完成。注册方式很灵活：支持微软账号，也支持 GitHub 账号。

整个注册流程比想象中简单。打开 Azure DevOps 的官网页面，点击“免费启动”或者“Start free”按钮，之后按下面的步骤走：

第一步，选择登录方式。用微软账号的话，直接登录并确认账号信息；用 GitHub 账号的话，需要先授权让 Azure DevOps 读取你的 GitHub 身份。这一步就像你用微信授权登录一个网站，点“授权”就行。

第二步，创建组织。系统会要求你填一个组织名称，这个名字会出现在你的访问地址里，例如https://dev.azure.com/你的组织名。选一个正式点的名字，因为它相当于你在 Azure DevOps 里的“主空间”，之后创建的所有项目都放在这个空间下面。

第三步，选择主机区域。系统会列出几个区域供选择，选一个离你近的就行，这个设置后期也能改。区域主要影响数据的存放位置和访问速度，对功能没有影响。

第四步，创建第一个项目。注册完组织后，系统会引导你创建一个项目（Project），项目名建议跟你的代码仓库同名或者相关，方便后续对应。访问级别选“私有”或者“公开”都行，这个我在后面的小节里详细说。

完成这四步，你就拥有了一个可用的 Azure DevOps 组织。整个过程撑死十分钟，而且新用户注册后，系统就给你提供了基本的免费额度：私有项目每月有 1800 分钟（30 小时）的管道运行时长，公共项目则完全免费。对于个人学习和开发来说，这个额度绰绰有余。

3.2 代码先放进版本控制：管道只认仓库里的东西

Azure Pipelines 有一个硬性要求：你的源代码必须已经存在于版本控制系统（Version Control System，缩写 VCS）中。原因也很朴素——管道要自动读取你的代码，它总得有一个固定的“取件地址”。没有代码仓库，管道就是空转。

Azure DevOps 本身就对两种主流的版本控制方式提供了支持：Git 和 Azure Repos。Git 是最通用的选择，如果你完全没有用过 Git，我建议用最简练的方式理解它：Git 是一个跟踪代码历史变更的工具，你每次把代码提交（commit）到仓库，它就记下一个快照，之后任何时候都能对比或者回退。

如果你是个人项目，而且之前从来没建过 Git 仓库，最简单的做法是直接在 Azure DevOps 的项目里新建一个空仓库。打开项目主页，找到“仓库”或“Repos”入口，点“新建仓库”，填个名字，选择 Git 类型，仓库就建好了。然后把你本地的代码推上去：

在本地项目文件夹里打开终端，先初始化 Git 仓库：

git init

接着把本次改动加入暂存区：

git add .

再提交一次初始版本：

git commit -m "first commit: init project"

最后把本地仓库和 Azure DevOps 上的远程仓库关联起来。关联方式在 Azure DevOps 仓库页面里会直接给出，包括 HTTPS 和 SSH 两种地址，这里以 HTTPS 为例：

git remote add origin https://dev.azure.com/你的组织名/你的项目名/_git/你的仓库名 git push -u origin main

如果你用的是 GitHub 仓库，也不用担心。Azure Pipelines 支持直接对接 GitHub、Bitbucket Cloud、Subversion 等外部仓库，在新建管道时选择对应的代码来源就行。也就是说，你完全可以把代码放在 GitHub 上，把构建和部署交给 Azure Pipelines 处理，两个平台互不冲突。对新手来说，我建议这一步就用 Git 仓库，不碰其他类型的版本控制，免得概念混淆。

3.3 公共项目还是私有项目：先选对再动手

很多新手容易忽视项目类型这个选择，但其实它和费用、权限都挂钩，值得在开始前想清楚。

在 Azure DevOps 里，“项目”有两种可见性。公共项目意味着这个项目里的代码、管道、工作项对所有人都可见，互联网上任何人都能浏览。私有项目则相反，只有你显式添加的成员才能看到内容。收费规则也不同：公共项目可以免费无限制地使用 Pipelines；私有项目则基于运行时长计费，免费额度是每月 1800 分钟。

对刚开始学习的个人开发者，我的建议是：如果你的项目不打算开源，就先选私有项目。因为代码仓库里免不了存一些密钥、配置信息、内部逻辑，一旦项目设成公共，这些就全部暴露了。新手对权限边界不熟悉，很容易出现“以为只有自己能看到，其实全世界都在看”的情况。

反过来，如果你本来就想开源，那么公共项目反而是很好的选择。代码公开后，你还可以借着互联网的力量获得反馈，而且构建资源免费，练习起来没有心理负担。唯一要牢记的是：即使项目是公共的，服务连接、变量组里的机密信息也不会公开，这些数据在 Azure DevOps 里有独立的权限模型，所以不会因为项目公开而泄露。

到这里，组织、项目、仓库都齐了。下一步就是这一篇的重头戏：创建你的第一个管道。

4. 第一个管道：用 YAML 文件把构建流程串起来

Azure Pipelines 有两种定义管道的方式：一种是 YAML 管道，一种是经典编辑器（Classic Editor）。对新手而言，YAML 是更值得先学的那条路。原因在于，YAML 管道以代码的形式存放在你的仓库里，跟着代码一起版本化，你怎么管理代码就怎么管理管道；而经典编辑器是在网页里用鼠标拖拽配置，配置结果不能放进 Git 里跟随版本。如今官方重点推荐的方向也是 YAML，所以这篇直接带你从 YAML 入手，绕开弯路的可能性。

4.1 管道文件长什么样：先看懂这个 YAML 骨架

YAML 是一种以缩进和冒号表达结构的配置文件格式。你不用把它当成一门编程语言，它更像是一份“照着填就能用”的清单。

一个最简单的 Python 项目管道文件azure-pipelines.yml长这样：

trigger: - main pool: vmImage: 'ubuntu-latest' steps: - task: UsePythonVersion@0 inputs: versionSpec: '3.11' displayName: 'Set up Python 3.11' - script: | pip install -r requirements.txt displayName: 'Install dependencies' - script: | python -m pytest displayName: 'Run tests'

别被这几段配置吓到，一行一行拆开看就非常简单了。

trigger是触发条件。它指定了“哪些分支上的提交会触发这条管道运行”。这里写的是main，意思就是只要有代码推送到main分支，管道就会自动开始跑。如果你用的是master分支，记得改成master。

pool是代理池配置。管道不是在你自己电脑上跑的，而是由一台专门的代理机器执行的。vmImage: 'ubuntu-latest'表示使用 Azure 官方提供的 Ubuntu 虚拟机镜像。代理是每次运行都在一台全新机器上执行，好处是环境干净、可重复，坏处是这台机器上没有你本地那些已经装好的依赖，所以需要任务里显式安装。

steps是任务列表，也就是管道实际执行的步骤。第一条task: UsePythonVersion@0是“选一个 Python 版本”，versionSpec指定版本号；第二条script执行pip install -r requirements.txt安装项目依赖；第三条script执行python -m pytest运行测试。displayName只是给每一步起一个更友好的名字，方便你在日志里识别，不写也行但推荐写上。

从这个例子能看出，一个管道的骨架就是：什么时候跑（trigger）、在哪跑（pool）、跑什么（steps）。所有复杂的管道结构都是在这个骨架上扩展出来的。

4.2 创建管道：从仓库到第一次运行

理论基础够了，现在开始实战。假设你已经把一个小项目推到了 Azure DevOps 的 Git 仓库里，项目里至少包含一个 Python 文件和一个requirements.txt。

第一步，进入 Azure DevOps 项目主页，左侧导航栏找到“Pipelines”，点击“新建管道”（New Pipeline）。

第二步，选择代码来源。系统会问你的代码放在哪，这里选“Azure Repos Git”，然后选中你刚才创建的那个仓库。如果你代码在 GitHub，也可以选 GitHub，授权后选择对应仓库，效果一样。

第三步，选择管道类型。系统会询问你使用 YAML 还是经典编辑器，选择“YAML”。

第四步，创建azure-pipelines.yml。页面会跳出一个在线编辑器，里面已经预置了一些模板。你可以直接清空，把我们上面那段 Python 示例粘贴进去，然后点击“保存并运行”（Save and run）。这一步会把azure-pipelines.yml文件提交到你的仓库里，并立刻触发第一次管道运行。

第五步，观察运行。保存后页面会自动跳转到运行日志界面。你会看到管道在初始化、准备机器、安装依赖、运行测试这几个阶段之间切换。第一次跑可能需要一两分钟，因为代理要下载镜像环境。等所有步骤都显示为绿色对勾，恭喜你，你的第一个管道已经成功跑通了。

如果某个步骤红了，也别慌。点开红色的步骤，里面会显示完整日志，日志末尾通常是真正的报错信息。最常见的错误是ModuleNotFoundError，意思是某个依赖没装上。解决办法就是检查requirements.txt，确保它列出了所有需要的库。

4.3 看结果：日志、测试报告和产物在哪

管道跑完之后，你除了能看到绿色对勾，还能从几个地方确认它“真的干了活”。

第一个地方是运行日志。每次运行的日志会按步骤拆分，你可以展开任意一步查看详细输出。比如测试步骤里，pytest会输出每个测试用例的结果。如果某条测试失败，日志里会直接显示断言信息和出错代码行号，这比本地跑测试时定位问题还方便。

第二个地方是测试报告。如果你在管道里运行了测试，Azure Pipelines 会自动收集测试结果，并在运行页面上生成一个“测试”标签页。它会把测试按通过、失败、跳过分类，并显示测试覆盖率数据。对新手来说，这里存在的意义是：你不用自己解析日志，系统已经把结果可视化好了。

第三个地方是产物（Artifact）。产物是构建流程结束后生成的交付物，比如一个编译好的 exe，一个 npm 包，或者一个打包好的 Python wheel。如果你想了解“管道把活干完了，成果放在哪”，答案就是产物区。发布产物的写法也不难，在管道末尾加一步任务就可以。但新手刚开始接触的时候，建议先不碰产物，等把构建和测试流程理顺了，再研究怎么把东西传给下一阶段。

4.4 改参数：把触发器和运行时长玩明白

第一个管道跑通之后，你最值得做的第一件事是“改着玩”。因为配置只有自己动手改过了，才算真正理解。

先改触发分支。如果你仓库主分支叫master，而管道里写的是main，那么每次推送都不会触发管道，你只能手动点击“运行”按钮。正确的做法是把trigger下的分支名改成仓库实际的主分支名。这里有一个新手容易迷糊的地方：触发分支指的是“代码推送到哪条分支就触发”，而不是“管道文件放在哪条分支”。管道文件的存放分支叫pipeline branch，这两个是不同的概念，一开始不必深究，遇到问题再来理解。

再改运行镜像。vmImage可以换成windows-latest或macos-latest，让管道在 Windows 或 macOS 环境下运行。如果你的代码依赖 Windows 特有功能，或者你想在多个平台上跑一遍同样的测试，就可以在这里配置多个 job 分别指定不同镜像。Azure Pipelines 支持并行在 Linux、macOS、Windows 上构建和测试应用，这是它一个很亮眼的能力，等你哪天要在不同系统上验证项目时，这招特别有用。

你还可以给管道加一个“定时运行”的触发器，比如每天早上跑一遍测试，语法里用schedules配置。不过新手阶段那不是重点，先把“推代码自动跑”这个最核心的动作掌握扎实，后面每一步都是在它的基础上加的。

5. 新手避坑：这些坑我几乎都踩过

第一次接触 Azure Pipelines 的时候，我一度觉得它像是个黑匣子：明明照着文档写了，跑起来却到处报错，报错信息还看不太懂。后来经验多了才发现，新手期的坑高度集中在那几个地方。这里挑五个最常见的，按“现象 → 原因 → 解决”的顺序写清楚，你遇到的时候直接对照就行。

5.1 一缩进就翻车：YAML 对空格极其敏感

现象：管道文件保存后立刻报错，错误信息类似You have not defined a trigger here或者Parsing error，页面上一片红。回头检查，觉得配置写得挺工整的。

原因：YAML 用缩进表达层级关系，同一个层级必须使用相同数量的空格。很多人从文档里复制配置，粘贴时输入的缩进多了少了、或者混用了 Tab 和空格，都会导致结构被解析成完全不同的意思。比如trigger:下面如果忘了缩进- main，这一项就不再属于trigger，而是被解析成另一个顶层字段，管道自然不认。

解决：在你的编辑器里安装一个 YAML 扩展，它会用颜色区分不同层级，缩进错了直接标红线。复制粘贴模板后，对每一行检查是否保留了原样缩进，不要用 Tab，统一用空格。如果你拿不准缩进对不对，可以把文件代码贴到任何 YAML 校验工具里看解析结果。养成“每次保存前先看一眼缩进”的习惯，这一条能帮你避开至少一半的配置错误。

5.2 改完代码管道不跑：触发器没配对

现象：代码明明推送到了仓库，Azure Pipelines 那边却毫无动静，没有新的运行记录。有的新手以为是服务器卡了，反复点“运行”按钮，发现手动运行反而能跑。

原因：绝大多数情况是trigger配置和实际分支名不匹配。repository 默认分支可能是master，而管道里写的是main；或者你在仓库里新建了dev分支并推送了代码，但触发器只监听main分支，那dev分支的推送自然不会触发管道。另外，如果你在 YAML 里写了trigger: none，那管道就完全关闭了自动触发，只能手动运行。

解决：先说结论，触发器的行为和“你以为的”可能不一样，动手前先确认两件事：一是仓库的默认分支叫什么名字；二是你想要哪条分支触发。修改trigger下的分支名与目标分支保持一致即可。如果你希望任何分支的推送都触发，可以写成：

trigger: - '*'

但要注意，这样做会导致管道频繁运行、消耗免费额度，练习阶段没必要。新手建议就固定监听一个主分支，等逻辑清晰了再扩展到其他分支。

5.3 本地好好的，一上管道就报错：缺依赖

现象：项目在本地跑得顺顺利利，一放进管道，第一步安装依赖就报错，或者运行时提示找不到某个命令、某个包。

原因：管道默认跑在一台全新的虚拟机上，这上面只有最基础的系统环境和工具链，没有你本地辛苦装好的各种软件。你在本地能用node、python、pytest，是因为当年你手动装过；管道虚拟机里什么都没有。这个问题准确地说不是“报错”，而是“它没有你所拥有的东西”。

解决：把管道当成一台从零开始配置的电脑，先把需要的环境装好，再跑业务。比如 Python 项目需要显式安装 Python 版本，用UsePythonVersion@0任务；Node.js 项目用NodeTool@0任务指定版本；需要编译工具链时还要安装相应依赖。安装依赖的那一步命令也要写全，比如pip install -r requirements.txt和npm install。一个很有效的排查方法是：看到报错后去看日志，日志里缺失import或command的名字，然后想一下“我在本地是怎么让它存在的”，把它变成管道里的一个步骤即可。

5.4 测试明明红了，管道却显示绿色：你没把测试接进来

现象：管道显示全部成功，所有步骤都绿了。但你自己在本地跑测试明明有失败用例，或者代码里写了一个会失败的测试，管道却完全无视。

原因：很多新手在管道的 steps 里只写了构建步骤，比如打包，把测试命令漏掉了；或者写了一步像是python -m pytest，但项目里根本没有任何测试文件，pytest 直接跳过，返回值仍然是 0，于是管道以为万事大吉。管道是很迟钝的：它只检查每个步骤的退出码，退出码为 0 就认为这步成功。你如果压根没让测试逻辑参与进来，它就不会知道你的代码有测试失败。

解决：把测试这一步加进 steps，并确保测试真的在执行。可以先在管道里加一步：

- script: | python -m pytest tests/ -v displayName: 'Run tests'

-v参数会让 pytest 输出每个测试用例的完整结果，方便你确认“有测试被执行”。然后，故意在某个测试里写一个会失败的断言，推一次代码，管道应该立刻变红。如果这样能红了，说明测试链路已经打通。别觉得这个动作傻，用一条“必失败的测试”验证管道不是虚设，比啥都放心。

5.5 把密码直接写进 YAML：给自己埋雷

现象：管道需要连接数据库，你的代码里需要一个连接密码。刚开始图省事，直接把密码写在azure-pipelines.yml里，比如database_password: "abc123"。管道跑通了，但仓库里的代码被历史记录保存了下来，甚至可能项目是公开的。

原因：YAML 文件放在 Git 仓库里，Git 的历史记录永远不会真正删除一条信息。就算你后来改了密码并提交一次新的代码，旧版本里那个明文密码仍然躺在 git 历史里，任何人克隆仓库都能看到。这是新手最容易忽略的隐患，尤其是在公共项目里，等于把秘密广播给了全世界。很多人管这叫“挖坑埋自己”，一点不夸张。

解决：永远不要把任何密钥、口令、令牌硬编码进 YAML。正确做法是用 Azure Pipelines 的变量库（Variable Groups）或密钥库（Azure Key Vault）来存放机密，管道运行时代理会把密文注入为环境变量，你在代码里通过环境变量读取。举例来说：

variables: - group: my-database-secrets steps: - script: | echo "Connecting with user $DB_USER" env: DB_USER: $(db-user)

这段配置里，db-user存在名为my-database-secrets的变量组中，管道运行时会自动把它的值传给环境变量，不会在日志和代码里暴露。保护机密这件事，从第一次写管道时就该养成习惯，否则等泄了再后悔就晚了。

6. 下一步怎么学：先掌握这四个关键词，再挑战多环境部署

你的第一个管道已经能自动跑测试了，接下来学什么？我的建议是不要立刻去背一大堆任务参数，而是先理解四个关键词：变量、阶段、环境和模板。把这四个词吃透，再回头去看官方文档里那些复杂案例，你会觉得它们都只是这些基础元素的排列组合。

变量（Variables）用来保存管道里会变化的值。比如测试环境的 URL、部署服务器的地址、版本号，都可以定义为变量。定义方式很简单，在 YAML 里用variables字段写就行：

variables: appName: my-app environmentName: dev

阶（Stages）段用来给管道划分大节段。一个管道可以包含多个阶段，比如“构建阶段”和“部署阶段”。每个阶段又包含若干个作业（Jobs），每个作业里包含若干任务（Steps）。这个层级关系是理解整个 YAML 管道的钥匙：Stages → Jobs → Steps。新手很容易把任务和阶段混在一起，其实它们是上下层关系。

环境（Environments）代表部署的目标位置，比如开发、测试、生产。它和阶段紧密结合，每个部署阶段都可以指定部署到哪个环境。环境还有一个好处：你可以为不同环境设置不同的审批人，实现对生产的保护。

模板（Templates）是管道的“复用函数”。当你有几个项目都要执行同一套构建步骤时，可以把公共步骤抽成一个模板文件，然后在不同管道里引用。这样改一处，所有项目都同步生效，省心省力。这四个概念掌握了，你就可以去挑战更接近真实工作的场景了，比如把应用部署到 Azure Kubernetes Service（AKS）、发布 NuGet 或 npm 包、与 Slack 或 Microsoft Teams 集成发通知。这张表可以当线索存着：

第一次成功跑通管道的时候，我特别兴奋，转头就去配了一台自托管代理（Self-hosted Agent），觉得那样更自由。结果因为代理机器上少了一个库，排错排到凌晨。后来我才明白，刚入门就用云上的托管代理，让 Azure 帮你维护运行环境，才是新手阶段最省心的选择；自托管代理是等到环境要求明确之后再到下一阶段的进阶配置。从那以后，我每次调整管道都遵循一条规则：先用最简单的配置跑通，再逐步加功能，绝不一次塞太多新概念进来。希望帮到你。现在就可以去把这份手册从头到尾过一遍，跟着里面每一步把示例跑起来——试得多了你自然会慢慢上手。

本文还有配套的精品资源，点击获取