Microsoft AZ-400: 包管理与工件管理 — 学习指南
属于 Microsoft DevOps Engineer Expert AZ-400 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.
概述
包管理是 Azure DevOps 中实现可复现构建、可靠部署和安全供应链的支柱。Azure Artifacts 集中了跨 NuGet、npm、Maven、Gradle 和 Universal packages 等生态系统的包存储和治理，同时支持从公共注册表进行上游缓存，并为包的提升、保留和权限提供精细化控制。结合语义化版本控制自动化和安全/合规工具，它使您能够大规模地标准化内部和外部依赖项的生产、发现、批准和使用方式。
Azure Artifacts 核心概念
源 (feed) 是包的存储和访问控制单元。团队通常按产品、平台或信任边界来组织源（例如，一个源通过上游用于所有公共开源软件依赖，一个用于共享的内部库，每个产品一个源）。源支持多种包类型，每种类型都有其自己的客户端工具。
视图 (View) 在单个源内实现了一种门控式的提升模型：
- local: 所有新发布的包都会出现在这里
- prerelease: 用于向早期采用者和集成管道暴露 beta/夜间构建版本
- release: 只有经过生产批准的包才会被提升到这里以供广泛使用 使用者指向特定的视图，以自动避免不稳定的内容。在发布流程中提升或降级版本，以控制爆炸半径。
上游源 (Upstream sources) 将一个源连接到公共注册表（NuGet.org、npmjs.com、Maven Central）。启用后，开发人员通过您的源来解析公共依赖项。Azure Artifacts 会透明地代理并缓存所使用的确切版本，从而提高可靠性，支持离线 (air-gapped) 场景，并允许您稍后通过禁用新的上游下载来“冻结”供应。您可以根据策略为每个源限定启用哪些上游源。
强制执行保留策略以降低存储成本，同时保留重要内容。您可以定义策略来保留每个包的最新 N 个版本，只保留提升到 release 视图的版本，并自动删除旧的预发布版本。固定 (Pin) 特定版本，使其免于被清理（例如，那些嵌入在长期存在的产品分支中的版本）。将保留窗口与审计和回滚要求对齐，以在可追溯性和存储成本之间取得平衡。
源权限遵循最小权限原则：
- 所有者 (Owner): 管理源设置、权限、视图和保留策略
- 参与者 (Contributor): 发布、取消列出、弃用和提升包；不能更改源级别的设置
- 读取者 (Reader): 只能还原/使用包；不能修改包 注意：“协作者 (Collaborator)” 不是 Azure Artifacts 的源角色。如果遇到该术语，请将其预期的能力（通常是“可以发布”）映射到 Azure Artifacts 中的“参与者 (Contributor)”角色。
管理包生态系统
NuGet (dotnet/C#)
- 版本控制: 首选 SemVer 2.0.0 (例如, 1.4.0, 1.4.1-alpha.3+build.45)。预发布标签通过视图来控制分发；release 视图的使用者永远不会遇到 -alpha/-beta 变体。
- 发布: 使用
undefined
或
undefined
打包，然后使用
undefined
或
undefined
推送到你的源端点。在 Azure Pipelines 中使用 NuGet 任务，并在质量门上将包提升到 prerelease/release 视图。
- 使用: 使用源的 URI (可选择性地限定于某个视图) 来配置 nuget.config。通过
undefined
或 NuGet Restore 任务来还原包。
- 经身份验证的源: 使用 Azure Artifacts 凭据提供程序（内置于近期的 dotnet SDK 中）或 NuGet Authenticate 管道任务。对于开发人员，通过 Visual Studio/Azure CLI 登录；对于 CI，根据需要授予构建服务主体“读取者”/“参与者”权限。
npm (JavaScript/TypeScript)
- 作用域包: 在组织作用域下发布内部包，例如 @fabrikam/button。作用域可以自然地映射到源权限，并允许限制跨项目的使用。
- .npmrc: 设置
undefined
,
undefined
, 并可选择性地为多注册表设置设置
undefined
。在 CI 中，使用 npm Authenticate 任务注入临时身份验证令牌。对于本地开发，使用 PAT 执行
undefined
。
- 私有注册表: Azure Artifacts 充当一个私有的 npm 注册表，并以上游方式连接到 npmjs.com。仅从 release 视图使用包，以阻止未经批准的预发布版本。
Maven and Gradle (Java/Kotlin)
- 发布 (Maven): 在 pom.xml 中定义指向你的源的
undefined
，并在 settings.xml 中定义一个包含凭据（PAT 或服务连接）的
undefined
条目。在 Azure Pipelines 中使用
undefined
或 Maven 任务进行发布。
- 发布 (Gradle): 应用
undefined
插件并配置
undefined
，然后使用
undefined
进行发布。
- 依赖项解析: 对于 Gradle，将你的源端点（可选择性地带上视图后缀）添加到
undefined
中；对于 Maven，则添加到 pom.xml 的
undefined
中。开发构建采用 SNAPSHOT 版本，并将发布版本提升到 release 视图以供稳定的使用者使用。
Universal packages (二进制文件、脚本、模型)
- 版本控制: 遵循 SemVer 风格或整数版本；每次发布都是不可变的。此类型适用于不适合特定语言生态系统的工件。
- 发布/下载任务: 在管道中使用 Azure DevOps 的 Universal Publish 和 Universal Download 任务，或使用 Azure CLI (
undefined
/
undefined
)。通过 Azure DevOps 服务连接或已登录的身份进行身份验证。
- 使用场景: 共享的 CLI、IaC 模块、测试数据、机器学习模型，或需要 RBAC、保留和提升功能但没有特定语言工具支持的跨语言资产。
### 实际问题场景
Adobe 需要在多种云和语言之间标准化包治理，同时减少因公共注册中心不稳定而导致的服务中断，并强制执行许可证策略。各个团队需要发布内部的 NuGet、npm 和 Maven 工件，并共享大型的跨语言 CLI 工具。
- 建立集中的源和上游源
- 操作：创建三个 Azure Artifacts 源：“oss-upstream”（包含指向 NuGet.org、npmjs.com、Maven Central 的上游源）、“shared-libs”（内部库）和 “productA”（应用程序级包）。在所有源上启用视图（local、prerelease、release）。
- 原理：“oss-upstream” 成为单一的入口/缓存点；“shared-libs” 和 “productA” 分离了信任边界和提升工作流。
- 通过视图配置客户端使用
- 操作：对于运行时消费者，将其 nuget.config、.npmrc、settings.xml/Gradle 仓库指向每个源的 release 视图；对于集成测试管道，则指向 prerelease 视图。
- 原理：视图强制只有经过提升和审查的包才能到达生产环境的消费者，而无需更改客户端配置。
- 使用语义化版本控制实现发布
- 操作：为库和应用的 CI 添加 GitVersion。驱动版本注入到 dotnet pack、npm version（不使用 Git 标签，由管道控制）以及 Gradle/Maven 的版本字段中。发布到 local 视图；CI 成功后提升到 prerelease 视图；在预生产环境测试通过后自动提升到 release 视图。
- 原理：与 Git flow 对齐的确定性版本控制，确保了预发布标签的一致性和为自动化提升做好准备。
- 保护需身份验证的源并优化开发者体验
- 操作：在管道中使用 NuGet Authenticate 和 npm Authenticate 任务；为开发人员机器启用 Azure Artifacts Credential Provider；使用通过 Azure DevOps 变量组轮换的 PAT 来配置 Maven settings.xml 中的服务器。
- 原理：无缝的、基于令牌的身份验证可防止凭据蔓延，并支持非交互式的 CI 包还原。
- 强制执行漏洞和许可证策略
- 操作：向构建中添加 SonarQube 质量门；集成 Black Duck 以强制执行许可证白名单，并阻止包含不允许的许可证或高危 CVE 的构建。对于 npm 和 .NET，运行 npm audit 和 dotnet list package –vulnerable；将 SBOMs 作为构建工件发布。
- 原理：多个互补的扫描器可以减少盲点；Black Duck 提供大规模的许可证合规性检查，而 SonarQube 和生态系统工具则能及早发现安全回归问题。
- 控制入口并在需要时冻结
- 操作：仅允许从 “oss-upstream” 下载上游包；在事件响应期间禁用新的上游包入口以冻结供应。依赖缓存的包来维持构建。
- 原理：如果公共注册中心遭到破坏或不稳定，一个集中的管控点能够实现快速遏制。
- 应用保留和固定策略
- 操作：对于 shared-libs 和 productA，保留最新的 5 个版本；删除超过 30 天未被提升的版本；固定与 LTS 分支和合规基线相关的版本。
- 原理：自动化清理可以控制存储成本，而版本固定则保留了可审计性和回滚能力。
- 委派最小权限访问
- 操作：将 Owners 角色分配给平台工程团队；将 Contributors 角色分配给必须发布/弃用包的库维护者；将 Readers 角色分配给只使用 release 工件的产品团队。
- 原理：使能力与职责对齐；开发人员可以在没有广泛管理权限的情况下取消列出/弃用包。
- 使用通用包管理跨语言工具
- 操作：通过 Universal Publish/Download 任务，将内部 CLI 和 IaC 模块作为通用包发布；对它们进行语义化版本控制，并通过视图进行提升。
- 原理：为非特定语言的资产提供 RBAC、保留和提升策略，并采用一致的使用模型。
- 衡量与迭代
- 操作：跟踪源存储、缓存命中率和提升前置时间；并据此调整保留阈值、上游策略和提升标准。
- 原理：随着产品组合规模的演变，持续的调优可以保持可靠性、成本效益和合规性。
← 监控、可观察性与反馈 · 所有领域 · 敏捷规划与工作管理 →
练习这些题目 → · 在 ExamRoll.io 上限时练习 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通过考试 →