简介《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 Pipelineazure 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: UsePythonVersion0 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: UsePythonVersion0是“选一个 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 版本用UsePythonVersion0任务Node.js 项目用NodeTool0任务指定版本需要编译工具链时还要安装相应依赖。安装依赖的那一步命令也要写全比如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 ServiceAKS、发布 NuGet 或 npm 包、与 Slack 或 Microsoft Teams 集成发通知。这张表可以当线索存着关键词它是什么你什么时候会用到变量存管道中用到的常量或动态值配置多个环境、管理版本号阶段把管道按构建、部署切大块需要先构建再部署的流程环境描述部署的目标位置区分开发/测试/生产环境模板抽取可复用的步骤组多个项目共用同一套构建流程第一次成功跑通管道的时候我特别兴奋转头就去配了一台自托管代理Self-hosted Agent觉得那样更自由。结果因为代理机器上少了一个库排错排到凌晨。后来我才明白刚入门就用云上的托管代理让 Azure 帮你维护运行环境才是新手阶段最省心的选择自托管代理是等到环境要求明确之后再到下一阶段的进阶配置。从那以后我每次调整管道都遵循一条规则先用最简单的配置跑通再逐步加功能绝不一次塞太多新概念进来。希望帮到你。现在就可以去把这份手册从头到尾过一遍跟着里面每一步把示例跑起来——试得多了你自然会慢慢上手。本文还有配套的精品资源点击获取