简介这是一份 Azure DevOps Pipelines 官方文档整理而成的操作手册面向需要搭建持续集成与持续交付体系的开发、运维及 DevOps 工程师适合从入门到进阶查阅。手册系统覆盖 Azure Pipelines 核心概念包括代理、条件、表达式、环境、作业、运行时参数、阶段、任务、模板与触发器并完整讲解经典发布管道、快速入门、自定义管道、YAML 架构及预定义变量等关键内容。资源共 1 个 PDF 文件整体大小 106.6MB便于离线检索与按章节学习。已有 412 人浏览学习内容版块清晰既包含在 Windows、Linux、macOS 上生成多语言应用的操作指南也涵盖部署到 Azure SQL、AKS、Azure Key Vault 等服务的教程以及持续测试、资源管理、常见故障排查和发布包等实践章节可帮助读者从零搭建管道并解决实际发布中的问题。1. Azure Pipelines到底是什么一个帮你自动搬砖的助手刚接触代码发布的人可能都有过这种体验每次改完功能都要手动登录服务器、上传代码、跑一遍测试、再重启服务。改一行半小时没了改十行一下午就没了。Azure Pipelines 就是来帮你解决这个问题的——它是 Azure DevOps 平台的自动化服务核心能力是持续集成与持续交付CI/CD。你只要把代码推到仓库它会自动完成构建、测试甚至部署再把结果反馈给你。它适合任何写代码的人不管你是刚入门的新手还是在团队负责发版的老手都能把重复的手工操作交给它。这篇指南不聊复杂原理只带你先搞懂它是什么再亲手跑通第一个管道。2. 先弄懂两个核心概念持续集成和持续交付的区别Azure Pipelines 身上贴着两个最常见的标签CI 和 CD。很多新手第一次打开官方文档看到这两个缩写直接懵了。别慌这俩概念一点都不玄学也不难理解。我尽量用大白话把它讲清楚你带着这两个印象再去看文档会觉得顺眼很多。2.1 持续集成CI每次提交代码都自动体检持续集成英文叫 Continuous Integration缩写 CI。它的核心动作只有一个每当你的代码发生变动——比如有人往仓库里推送了一次新的提交——系统就自动把最新的代码拉下来做一次完整的体检。这个体检包含什么呢至少包含两件事一是构建Build把源代码变成可以运行的产物比如把 Java 代码编译成 jar 包把前端代码打包成静态文件二是测试Test跑你写好的一堆自动化测试用例确认这次改动没有把原来的功能弄坏。如果构建失败或者测试没通过你就需要赶紧回去看这次提交的代码。为什么要这样做因为问题发现得越早修起来越便宜。如果你把两个星期的代码攒在一起合并后再统一测试一旦出错很难定位到底是哪一次改动引入的。但如果是每次提交都自动跑一遍测试某一次红了你立刻就知道是哪里出了问题。用官方文档的说法这叫在开发周期的早期捕获 bug从而降低修复成本。所以 CI 解决的核心问题就是这个让代码仓库保持一个基本健康的状态避免出现本地跑得好好的一合并就炸了的尴尬局面。它不负责部署只负责保证你的代码在被合并进主干之前是经得起验证的。2.2 持续交付CD把成品自动送到每个环境持续交付Continuous Delivery缩写 CD。如果说 CI 的目标是把代码变成可运行的产物那 CD 的目标就是把这个产物安全地送到各个运行环境里去。运行环境大家应该不陌生本地开发是一个环境公司有一台测试服务器线上有一台生产服务器可能还有给客户演示用的预发布环境。每次发版你得把这些环境挨个部署一遍传文件、改配置、重启服务。CD 要解决的就是把这个过程自动化——你用 CI 生成的构建产物通过管道自动传递到测试环境、预发布环境最后再部署到生产环境。你可能听说过多环境部署提升质量这句话意思是代码不是直接上生产的而是先在测试环境跑一遍验证验证通过再往下一个环境推。这就像发货之前先经过质检质检合格了才装箱。Azure Pipelines 支持你把整个流程定义成多个阶段每个阶段对应一个环境阶段之间还可以加审批——没有人确认管道不会继续往下走。2.3 为什么非得自动化一次手动发布翻车之后光讲概念可能感受不深我讲一个某团队的亲身经历。这个团队当时发布全靠手工A 同学负责打包把代码上传到一台跳板机再手动执行脚本部署到服务器。最开始人少一周发一次版勉强能撑住。后来项目需求增多变成一天发好几次问题就开始爆发了——打包出来的版本偶尔不一致测试环境验证过的东西一到生产就行为奇怪偶尔还会出现两个人同时部署撞车的情况。后来他们引入了 CI/CD把打包、跑测试、部署测试环境、部署生产环境全部写进管道里。从那以后发版变成一件很无聊的事推一次代码等几分钟看管道跑完完事。就算出错管道也会明确指出是哪一步挂的日志都给你整理好不用再靠猜。手动流程最要命的不是慢而是不可复现——你永远没法保证每次手点的按钮、每个手敲的命令都完全一致。而管道里的每一步都是写死的脚本和参数跑一千次结果都一样。2.4 它到底能跑什么语言、平台和部署目标Azure Pipelines 一个很受欢迎的特点是什么都不挑。官方文档里列出的支持范围非常大构建和测试的编程语言包括 Node.js、Python、Java、PHP、Ruby、C#、C、Go、.NET、Android还有 iOS 和 Xcode 项目几乎覆盖了主流技术栈。部署目标同样广泛虚拟机、容器、Azure Kubernetes 服务、云平台服务、本地服务器都可以作为部署终点甚至还能把你的移动应用发布到应用商店。它还内置了针对 .NET、Java、Node.js、Android 等常用项目的现成任务省去你到处找插件的功夫。这意味着你只要学会一次以后换语言、换部署平台这套思路都能复用不用担心白学。3. 亲自上手免费注册并创建第一个管道概念讲得再多不如自己亲手跑通一次。这一章我们只做一件事把一个简单的项目通过 Azure Pipelines 自动构建一次。你全程跟着做大约十五分钟就可以看到第一个结果。第一次跑通之后你心里就有底了后面再怎么折腾都不怕。3.1 第一步准备一个代码仓库Azure Pipelines 有一个硬性前提你的源代码必须放在版本控制系统里。它支持很多种仓库例如 GitHub、Azure Repos Git 等。如果你手头还没有项目最简单的做法是在 GitHub 上建一个空仓库往里面放一个最简单的项目文件。不用多复杂一个单文件的 Python 脚本或者一个 HTML 页面都可以——先别追求项目本身的复杂度我们的目标是让管道有东西可跑。如果你用的是 GitHub 仓库直接把代码推上去就行。仓库是公开还是私有都可以两者在使用上有一些区别公开项目使用管道是免费的私有项目每个月有固定的免费分钟数这个我们在第 5 章会详细讲。3.2 第二步注册 Azure DevOps 并创建组织打开浏览器进入 Azure DevOps 的注册页面选择免费开始。你可以用已有的 GitHub 账号登录也可以用 Microsoft 账号登录。第一次进来系统会引导你创建一个组织Organization。组织怎么理解你把它当成一个团队工作区就行所有项目、管道、构建记录都放在这个工作区里。创建的时候需要做两件事给组织起个名字然后选择数据中心的位置。完成后你会得到一个访问地址格式是 https://dev.azure.com/你的组织名。以后所有项目都从这个地址进入。这里给你一个小建议组织名字最好用英文或拼音。因为后面生成的各类链接都会带上组织名纯英文最不容易在复制粘贴的时候出问题。3.3 第三步创建项目并找到 Pipelines 入口登录进组织之后页面会引导你创建一个项目Project。项目名可以随意比如就叫 my-first-pipeline。可见级别暂时选私有就行以后想改成公开随时可以调整。项目创建完成左侧导航栏里会有一个写着 Pipelines管道的菜单点进去就是管道管理页面。页面上会有一个明显的按钮叫创建管道或Create Pipeline我们点击它开始创建第一个管道。3.4 第四步选择代码源并让系统识别你的仓库创建管道的第一步是选择代码放在哪里。前面我们用 GitHub 的话这里就选 GitHub 选项系统接下来会要求你授权让你选择刚才那个仓库。选好仓库之后Azure Pipelines 会主动做一件事扫描你的仓库内容然后根据项目类型推荐一个管道模板。比如仓库里有一个 Python 文件它会推荐 Python 包构建模板如果检测到 package.json会推荐 Node.js 模板。这一步对新手特别友好你直接选它推荐的第一个模板即可。3.5 第五步看一眼生成的 YAML然后点运行选择完模板系统会打开一个编辑器里面已经生成好了一个名为 azure-pipelines.yml 的文件。下面是一个 Python 项目可能生成的示例trigger: - main # 推送到main分支时自动触发运行 pool: vmImage: ubuntu-latest # 使用微软托管的Ubuntu环境来执行任务 steps: - task: UsePythonVersion0 # 官方任务指定Python版本 inputs: versionSpec: 3.11 addToPath: true - script: | # 运行脚本升级包管理工具并安装依赖 python -m pip install --upgrade pip pip install -r requirements.txt displayName: 安装依赖 - script: | # 运行脚本执行pytest测试 python -m pytest displayName: 运行测试先别急着理解每一行的含义这一章的最终目标只是让它跑起来文件里该有的内容系统已经帮你填好了。直接点击保存并运行系统会把这份 YAML 文件提交到你的仓库里然后立刻开始第一次构建。等待一两分钟页面会跳转到构建运行的详情页。你会看到几个步骤依次执行安装依赖、运行测试、最后完成构建。每一步前面都有一个绿色的对勾表示这一步通过了。到这里你的第一个管道就正式建成了是不是没有想象中那么复杂提示第一次运行如果系统提示需要授权或创建服务连接按页面提示点一下许可或批准即可。这是为了让管道能访问你的仓库属于正常的安全流程。第一次跑通之后你可能会开始好奇那个 YAML 文件里到底写了什么为什么它能指挥管道干活带着这个疑问我们进入第 4 章。4. 读懂YAML管道一份配置文件如何驱动整个流程跑通第一个管道之后你会产生一个新的困惑那个 YAML 文件里面到底写了什么为什么它能指挥管道一步一步干活这一章我们就把它拆开来看。你不需要背语法只需要理解它的组织逻辑——下次再拿到别人的管道文件你能大概看出它的执行顺序和关键参数那就算达标了。4.1 从一份最简单的 YAML 开始拆解我们先用一份最简单的 YAML 来举例trigger: - main # main分支收到推送时自动运行 pool: vmImage: ubuntu-latest # 运行环境Ubuntu最新版虚拟机 steps: - script: echo Hello, Azure Pipelines! displayName: 打个招呼 # 这一步在控制台打印一行问候这份配置的每一块都有明确的意义。trigger:表示触发条件意思是当这个仓库的 main 分支收到新的代码推送时管道就自动启动。如果你以后想改成别的分支把 main 换成对应分支名即可。pool:定义管道在哪种运行环境里执行。ubuntu-latest是微软托管虚拟机的一个镜像代号代表最新版 Ubuntu 系统。你可以把它换成windows-latest或macos-latest管道就会跑到对应系统的虚拟机上——跨平台构建大致就是这么实现的。steps:是步骤列表每一步就是一个任务。这里只有一个任务执行一条脚本命令echo作用是打印一行字。displayName是给这一步起的可读名字方便你在运行记录里一眼看出这一步在做什么。这里要特别提醒你注意YAML 对缩进极度敏感。steps:下面的每一项前面必须有相同的缩进层级通常统一用两个空格。如果你复制别人的配置时缩进乱了管道会直接解析失败这也是新手最常踩的坑第 5 章会展开讲。4.2 认识任务、作业和阶段三个层级在管道文件里你会反复看到三个概念任务、作业、阶段。它们的关系是从小到大、层层包含的可以对照下面这张表来理解层级作用类比任务Task一个具体操作如运行脚本、安装依赖、发布产物一次具体动作作业Job一组任务的集合在指定的运行环境上按顺序执行一个工作台阶段Stage一组作业的逻辑分组常对应不同部署环境流水线上的工位任务Task是最小的执行单元代表做一件具体的事。前面例子里的script就是一个任务。Azure Pipelines 内置了大量任务比如指定 Python 版本、运行测试、发布构建产物等。你可以在官方任务索引里查到所有可用的任务基本覆盖了常见开发需求。作业Job是一组任务的集合。默认情况下一个 YAML 文件里的所有任务都在同一个作业里按顺序执行。但如果你希望并行跑多个环境的构建可以把它们拆成多个作业每个作业有自己独立的运行环境和任务列表。阶段Stage是更大的一层用于组织作业。通常一个阶段对应一个环境构建是一个阶段部署到测试环境是下一个阶段部署到生产环境又是更下一个阶段。阶段可以串行执行也可以设置条件比如前一个阶段成功后才继续执行下一个阶段。你不需要现在就掌握全部细节只要知道执行顺序大致是任务在作业里跑、作业在阶段里跑就够了。后面你真正配置多环境部署时这些概念自然会被串起来。4.3 触发器管道什么时候自动运行管道不会平白无故跑起来它需要一个起跑信号这个信号就叫触发器。最常用的就是前面看到的那段trigger: - main它的意思是只要 main 分支有新的代码推送就自动触发管道运行。如果你希望任意分支都触发可以写成trigger: - *除了代码推送之外触发器也可以是定时运行。比如你想每天晚上自动跑一遍全量测试可以用schedules来配置计划任务。当然最原始的触发方式还是手动运行在管道详情页直接点击运行管道随时可以手动执行一次。这里补充一个容易忽略的知识点一个仓库里可以同时存在多套管道每套对应一个 YAML 文件。你可以让不同的管道各司其职一个负责日常构建一个负责发布部署互不干扰。4.4 执行环境的真相什么是 Agent你可能会好奇管道真正运行的时候代码到底是在哪台机器上执行的呢答案是 Agent它也常被翻译成构建代理。它是实际执行任务的运行环境你可以把它理解成一台管道专用电脑。Azure Pipelines 提供两类 Agent。第一类是微软托管的 Agent你在pool里写一个vmImage微软就临时从云端分配一台全新的虚拟机给你跑管道跑完自动销毁。它的优点是完全不用自己维护系统开箱即用缺点是每次都是新机器安装依赖会花一些时间。第二类是自托管 Agent你准备一台自己的机器安装 Agent 程序并注册到 Azure DevOps之后管道就可以指定使用这台机器。它适合什么场景呢比如构建过程需要访问内网资源、需要特殊的硬件环境或者你觉得托管机器的免费额度不够用。不过入门阶段直接用微软托管的最省事不要急着折腾自建环境。4.5 变量和变量组让配置不再写死管道里如果全是写死的值时间久了你会觉得很难受。比如现在把 Python 版本写死成 3.11过几个月想升级到 3.12就得打开文件改一遍。更灵活的做法是使用变量。YAML 里定义变量的方式是这样variables: pythonVersion: 3.11 # 定义一个变量后面用$(pythonVersion)引用 buildConfiguration: Release steps: - task: UsePythonVersion0 inputs: versionSpec: $(pythonVersion) # 引用变量而不是写死具体版本这段配置先定义了两个变量pythonVersion和buildConfiguration后面用$(变量名)的语法来引用。以后要改版本只需要动 variables 下面的一行不需要满文件找需要改动的位置。如果多个管道都想用同一批变量比如服务器地址、账号名称可以创建变量组Variable Group来统一维护。至于密码、密钥这类敏感信息千万不要直接写进 YAML 文件正确做法是放进变量组并标记为机密或者存进 Azure Key Vault管道运行时再引用。具体原因和后果第 5 章的坑五会详细说。5. 避坑指南新手最常见的5个翻车时刻跑管道这件事十个新手有九个会在前几次运行里遇到各种各样的报错。这一章我把最常见的几个坑拿出来逐个拆开每条都按现象、原因、解决的顺序讲。以后你遇到类似问题直接对照这里排查能省下不少摸索时间。5.1 坑一YAML缩进对不齐管道直接罢工现象管道连跑都没跑起来运行记录里直接显示解析失败错误提示类似 Failed to parse the YAML file有时候还配着一个让人摸不着头脑的行号。原因YAML 是一种对缩进极其敏感的文件格式。steps:下面每个任务必须处于相同的缩进层级多一个空格或少一个空格解析器都会认为它不是同一个列表里的元素。另一个常见情况是 Tab 键和空格混用也会引发同样的解析问题。解决尽量用代码编辑器来编辑 YAML 文件并装上相应的语法扩展它能实时标出缩进异常的位置。如果已经报错就展开错误提示中提到的行号附近检查每一行的缩进是否一致。我常用的做法是统一用两个空格做缩进全程不用 Tab这个习惯帮我避免了很多次解析错误。5.2 坑二依赖安装失败npm或pip一直报错现象管道前面的步骤都正常到了安装依赖这一环就红了。npm 报 ENOENT 或 404 Not Foundpip 报 Could not find a version that satisfies the requirement看起来是包找不到。原因微软托管的构建机器是全新的每次跑完就销毁所以机器上没有任何缓存和多余的全局包。如果安装命令里引用的依赖源地址过期了或者包名写错了就会直接失败。还有一类情况是缺少系统级运行库导致某个底层工具装不上。解决先展开失败步骤的完整日志看清楚失败的命令是哪一行。如果是下载源的问题换用官方源或可用的镜像源。如果是缺少系统库可以在安装依赖之前加一步先执行系统包管理命令把基础库装上。还有一个好习惯在安装依赖前先升级包管理工具本身很多诡异的安装报错都是因为包管理器版本太旧。5.3 坑三私有项目的免费分钟数很快用完现象管道突然不再启动了运行请求一直在排队或者直接提示资源不可用页面提示没有可用的并行作业额度。如果你用的是私有项目每个月默认只有 1800 分钟也就是 30 小时的免费构建时长。原因每次管道运行都在消耗免费分钟数构建越频繁、单次构建越久额度消耗越快。新手反复调试的过程中很容易就把一个月的额度用掉一大半然后在下一次真正需要发布的时候发现没额度了。解决三个方向。如果项目本身允许公开源码可以把项目改成公开公开项目使用管道不占用免费分钟数。或者配置一台自托管 Agent自托管的构建不消耗托管时长。另外优化构建速度也能变相省额度比如启用依赖缓存、减少不必要的步骤让每次构建跑得更快。5.4 坑四管道一直在排队构建迟迟不开始现象代码提交后管道状态一直停在排队中等了几十分钟还在排队看起来就像卡住了一样。原因账户的并行作业数是有限的免费额度下同一时间能并行跑的作业通常只有一个。如果你同时触发多个管道或者上一个构建还占着唯一的并行额度新触发的就会排队等待。解决先打开运行历史看看是不是有卡住或长时间运行的旧构建占着额度。如果有直接取消那些没必要跑的构建排队就会立刻消失。如果确认没有占用还是排着队再检查是否触发了数量限制。这个问题的排查思路其实很简单先挤掉占坑的再看别的。5.5 坑五密钥明文写在 YAML 里现象管道跑通了但过一段时间发现数据库密码、存储连接串这些敏感值被明文写在 azure-pipelines.yml 文件里而这个文件已经被提交进了共享仓库甚至公开仓库。原因图省事。很多新手第一次配置管道时顺手就把密钥复制粘贴进 YAML——因为这样最快而且本地跑确实能用。但问题在于YAML 文件是跟着代码仓库走的仓库的可见范围就是 YAML 内容的可见范围一旦仓库共享出去密钥就跟着泄露了这个时候可没有后悔药吃。解决把密钥放进变量组并在变量组设置里把它标记为机密这样日志里会自动打码。更严谨的做法是把密钥放到 Azure Key Vault 之类的专用机密管理服务里通过服务连接在管道内读取。任何不应该公开的值都不可以明文出现在 YAML 文件里。如果发现已经泄露不要只删文件了事一定要立刻到对应平台轮换该密钥强制失效换新。6. 下一步怎么学从能跑通到能独立搭建到这里你已经走完了了解概念、注册账号、创建并运行第一个管道、读懂基本 YAML、避开常见坑的完整入门过程。接下来按什么顺序继续深入我给出我比较推荐的一条路径。第一件事试着改模板。把第 3 章生成的 YAML 里的脚本换成你自己项目的真实命令比如让管道跑一遍项目完整的测试命令。能改通说明你真正开始操作了。第二件事学习让管道发布产物。在官方教程里检索发布 NuGet 包、npm 包或 Python 包的文档把你构建好的包发布出去。这个话题你可能暂时用不上但它是理解CI 的产物如何交给 CD 使用的关键一课。第三件事挑战多阶段部署。定义一个既有构建又有部署的管道先把文件构建出来再部署到一个测试环境并在阶段之间加上人工审批体验一把没人确认就不会往下走的发布流程。第四件事熟悉变量组和服务连接然后去配置一个真实部署目标比如一台云虚拟机。等这一步做完你基本已经能独立搭建一个像样的 CI/CD 管道了。最后再回头翻官方文档的概念区把环境、模板、门禁这些概念逐个补齐。给你讲一个我自己的小教训我刚开始学的时候特别喜欢在 YAML 里堆功能触发条件写得花哨变量用了一堆结果一跑就挂。后来我改了一个习惯先跑通最简单的版本再加下一个功能每加一项都确认之前的功能都还正常。从那以后我的每个管道基本都是一次成型。另外一个很实用的小习惯是每次管道报错不要只看日志的最后几行要从失败的步骤往回翻十几行前因后果才能连起来。把这个习惯坚持下去你排查问题的速度会明显快起来。希望这份指南能帮到你接下来就打开控制台动手创建你的第一个管道吧。本文还有配套的精品资源点击获取
