Microsoft AZ-400: 套件管理與成品管理 — 學習指南

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

屬於 Microsoft DevOps Engineer Expert AZ-400 — 學習指南. 使用經過驗證的解答練習： Microsoft 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

套件管理是 Azure DevOps 中可重現建置、可靠部署與安全供應鏈的骨幹。Azure Artifacts 集中化了跨生態系（NuGet、npm、Maven、Gradle 與 Universal packages）的套件儲存與治理，同時啟用來自公開登錄庫的上游快取，並為晉升、保留與權限提供精細的控制。結合語意化版本控制的自動化以及安全性/合規性工具，它讓您能夠標準化內部與外部相依性如何被大規模地生產、發現、核准與取用。

Azure Artifacts 核心概念

摘要 (feed) 是套件的儲存與存取控制單位。團隊通常會依據產品、平台或信任邊界來組織摘要（例如，一個摘要透過上游來源管理所有公開的 OSS 相依性，一個摘要用於共享的內部函式庫，以及每個產品一個摘要）。摘要支援多種套件類型，每種類型都有其自己的用戶端工具。

檢視 (Views) 在單一摘要內實作了閘門式的晉升模型：

• local：所有新發佈的套件都會出現在這裡
• prerelease：用於向早期採用者與整合管線揭露 beta/nightly 建置版本
• release：只有經生產核准的套件會被晉升到這裡以供廣泛取用 取用者可以指向一個特定的檢視，以自動避免不穩定的內容。在您的發行流程中，透過晉升或降級版本來控制爆炸半徑。

上游來源 (Upstream sources) 將一個摘要連接到公開登錄庫（NuGet.org、npmjs.com、Maven Central）。啟用後，開發人員可以透過您的摘要來解析公開的相依性。Azure Artifacts 會透明地代理並快取所使用的確切版本，從而提高可靠性、支援氣隙隔離情境，並允許您之後透過停用新的上游下載來「凍結」供應。您可以針對每個摘要設定其啟用的上游來源範圍，以符合政策要求。

強制執行保留 (Retention) 政策以降低儲存成本，同時保留重要的內容。定義政策以保留每個套件最新的 N 個版本、僅保留晉升到 release 檢視的版本，並自動刪除舊的 prerelease 版本。釘選特定版本以將其從清理中豁免（例如，那些嵌入在長期存在的產品分支中的版本）。將保留期間與稽核及回滾需求對齊，以在可追溯性與儲存成本之間取得平衡。

摘要權限遵循最小權限原則：

• 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 的變體。
• 發佈：使用 dotnet pack 或 nuget pack，然後用 dotnet nuget push 或 nuget push 推送到您的摘要端點。使用 Azure Pipelines 的 NuGet 工作，並在品質閘門上晉升到 prerelease/release 檢視。
• 取用：使用摘要的來源 URI（可選擇性地將範圍限定在某個檢視）來設定 nuget.config。透過 dotnet restore 或 NuGet Restore 工作來還原。
• 需驗證的摘要：使用 Azure Artifacts Credential Provider（內建於近期的 dotnet SDK）或 NuGet Authenticate 管線工作。對於開發人員，透過 Visual Studio/Azure CLI 登入；對於 CI，根據需要授予建置服務主體 Reader/Contributor 權限。

npm (JavaScript/TypeScript)

• 範圍套件：在組織範圍下發佈內部套件，例如 @fabrikam/button。範圍可以自然地對應到摘要權限，並允許限制跨專案的取用。
• .npmrc：設定 registry=https://pkgs.dev.azure.com/ORG/PROJECT/_packaging/FEED/npm/registry/、always-auth=true，並可選擇性地為多重登錄庫設定 @scope:registry=...。在 CI 中，使用 npm Authenticate 工作來注入臨時驗證權杖。在本機開發，使用 npm login 搭配 PAT 登入。
• 私人登錄庫：Azure Artifacts 作為一個私人 npm 登錄庫，並將 npmjs.com 作為其上游來源。僅從 release 檢視取用，以阻擋未經核准的 prerelease 版本。

Maven and Gradle (Java/Kotlin)

• 發佈 (Maven)：在 pom.xml 中定義 distributionManagement 指向您的摘要，並在 settings.xml 中定義一個帶有認證（PAT 或服務連線）的 server 項目。在 Azure Pipelines 中使用 mvn deploy 或 Maven 工作。
• 發佈 (Gradle)：套用 maven-publish 插件並設定 repositories { maven { url = "https://pkgs.dev.azure.com/..." credentials { } } }，然後用 gradle publish 進行發佈。
• 相依性解析：將您的摘要端點（可選擇性地加上檢視後綴）加入到 Gradle 的 repositories 或 Maven 的 pom.xml 中的 repositories。開發中的建置採用 SNAPSHOT 版本，並將發行版本晉升到 release 檢視以供穩定的取用者使用。

Universal packages (二進位大型物件、腳本、模型)

• 版本控制：遵循 SemVer 風格或整數版本；每次發佈都是不可變的。將其用於不適用於特定語言生態系的產物。
• 發佈/下載工作：在管線中使用 Azure DevOps 的 Universal Publish 與 Universal Download 工作，或使用 Azure CLI (az artifacts universal publish/download)。透過 Azure DevOps 服務連線或已登入的身分進行驗證。
• 使用案例：共享的 CLI、IaC 模組、測試資料、機器學習模型，或需要 RBAC、保留與晉升功能但沒有特定語言工具支援的跨語言資產。

安全性與合規性控制

在提交 (commit) 與建置 (build) 期間，必須強制執行弱點掃描。整合可識別已知弱點相依性並提供升級指引的工具。在許多 Azure DevOps 環境中，SonarQube 被用作品質閘門策略的一部分來標記問題，其中包含可揭露相依性風險的規則；您可以搭配專用的 SCA 工具 (例如 Snyk、Mend/WhiteSource 或 Black Duck) 來補強，以在各生態系中獲得更詳盡的 CVE 涵蓋範圍。對於 .NET，dotnet list package --vulnerable 可提供額外信號；對於 npm，則是 npm audit；對於 Java，可將 OWASP Dependency-Check 新增為建置步驟。

授權合規性是透過掃描 SBOM 或資訊清單 (manifests)，並與一份核准的授權白名單進行比對來強制執行。Black Duck 通常會被加入 Azure Pipelines，以便在偵測到受限制的授權時，封鎖建置作業。將掃描報告儲存為管線成品 (pipeline artifacts)，並將其附加到發行版本中，以確保可稽核性。

實作允許/封鎖套件的最佳方式是透過策略，而非臨時的例外情況：

• 將消費者限制在「發行 (release)」檢視；僅提升 (promote) 經審查的版本。
• 當您需要凍結版本時，停用新的上游下載，確保只有快取中的版本可用。
• 使用 npm scopes 和個別摘要 (feed) 的權限來限制命名空間。
• 新增管線檢查，在遇到不允許的套件或授權時讓建置失敗，並使用成品提升 (artifact promotion) 作為核准工作流程。

集中式摘要搭配上游快取有助於稽核與治理：您可以獲得一個用於套件傳入的單一管制點、不可變的歷史紀錄，以及用於產生 SBOM 的一致來源資訊。

版本控制自動化與保留經濟學

透過自動化，語意化版本控制 (Semantic versioning) 最容易維護：

• GitVersion 會讀取您的 Git 歷史紀錄和分支命名慣例，以可預測的方式計算版本 (例如，main 產生 1.4.0，feature/* 產生 1.5.0-feature.3)。設定模式 (Mainline 或 Continuous Delivery)、預發行標籤和標籤來源。在封裝 (packing) 之前，將計算出的版本注入 csproj、package.json 或 Gradle 的 version 屬性中。
• 自動版本號提升可以遵循提交語意 (commit semantics) 或 PR 標籤。例如，chore 不提升版本，feat 提升次要版 (minor)，fix 提升修補版 (patch)；breaking-change 則提升主要版 (major)。使用管線步驟來設定 buildNumber，並將版本傳遞給封裝/發布 (pack/publish) 任務。
• 預發行標籤應反映分支的意圖 (例如，在 feature 分支上使用 -alpha，在 release 分支上使用 -rc)。將預發行版本發布到「預發行 (prerelease)」檢視，並在成功部署到預備環境 (staging) 後，將其提升至「發行 (release)」檢視。

保留與儲存成本管理需要主動的策略：

• 自動清理：設定每個摘要的保留原則，在 N 天/個版本後刪除較舊、未被提升的版本。對於有長期支援週期的關鍵函式庫，可延長保留期間。
• 釘選：明確釘選那些嵌入在長生命週期產品或合規性快照中的版本，以將它們從刪除作業中排除。
• 儲存空間優化：優先使用上游快取，而不是在本地發布公開套件的副本，並在可行時整合摘要以減少開銷。定期監控摘要的儲存空間增長情況，並調整策略閾值。

上游來源詳情：

• NuGet：連接到 https://api.nuget.org/v3/index.json 作為上游，以代理和快取 NuGet.org 的套件。
• npm：連接到 https://registry.npmjs.com，以便在您的已驗證摘要後方快取 npmjs.com 的相依性。
• Maven：連接到 Maven Central (例如 https://repo.maven.apache.org/maven2)，讓企業消費者可以透過您的摘要，用單一 URL 來取得套件。

### 實務問題情境

Adobe 需要在多雲和多語言環境中標準化套件治理，同時減少因公用登錄檔不穩定造成的服務中斷，並強制執行授權政策。團隊會發佈內部的 NuGet、npm 和 Maven 成品，並共享大型的跨語言 CLI 工具。

1. 建立集中的摘要和上游來源

• 行動：建立三個 Azure Artifacts 摘要：“oss-upstream”（其上游來源指向 NuGet.org、npmjs.com、Maven Central）、“shared-libs”（內部函式庫）和 “productA”（應用程式層級的套件）。在所有摘要上啟用檢視 (views)（local、prerelease、release）。
• 理由：“oss-upstream” 成為單一的傳入/快取點；“shared-libs” 和 “productA” 則劃分了信任邊界和晉升工作流程。

2. 透過檢視設定用戶端的取用方式

• 行動：將 nuget.config、.npmrc、settings.xml/Gradle 的儲存庫指向每個摘要的 release 檢視，供執行階段的取用者使用；並指向 prerelease 檢視，供整合測試的管線使用。
• 理由：檢視 (Views) 強制只有經過晉升和審查的套件才能到達生產環境的取用者，而無需更改用戶端的設定。

3. 實作語意化版本控制的發佈流程

• 行動：將 GitVersion 加入函式庫和應用程式的 CI 流程。驅動版本注入到 dotnet pack、npm version（不使用 Git 標籤，由管線控制）以及 Gradle/Maven 的版本欄位中。發佈到 local 檢視；CI 成功後晉升至 prerelease；通過預備環境測試後自動晉升至 release。
• 理由：與 Git flow 一致的確定性版本控制，確保了預發行版本標籤的一致性，以及可隨時自動化晉升的流程。

4. 保護需驗證的摘要並改善開發者體驗

• 行動：在管線中使用 NuGet Authenticate 和 npm Authenticate 任務；為開發人員的機器啟用 Azure Artifacts Credential Provider；使用透過 Azure DevOps 變數群組輪替的 PATs 來設定 Maven settings.xml 中的伺服器。
• 理由：無縫、基於權杖的驗證可防止憑證擴散，並支援非互動式的 CI 還原作業。

5. 強制執行弱點和授權政策

• 行動：在建置流程中加入 SonarQube 的品質閘門；整合 Black Duck 以強制執行授權白名單，並阻擋包含不允許授權或高嚴重性 CVEs 的建置。對於 npm 和 .NET，執行 npm audit 和 dotnet list package –vulnerable；將 SBOMs 作為建置成品發佈。
• 理由：多個互補的掃描器可減少盲點；Black Duck 提供大規模的授權合規性檢查，而 SonarQube 和生態系工具則能及早發現安全性的退化問題。

6. 控制傳入流量並在必要時凍結

• 行動：僅允許從 “oss-upstream” 下載上游套件；在事件應變期間停用新的上游傳入，以凍結供應鏈。依靠快取的套件來維持建置。
• 理由：一個管制點 (choke point) 能在公用登錄檔遭到入侵或不穩定時，實現快速的圍堵。

7. 應用保留和釘選策略

• 行動：為 shared-libs 和 productA 保留最新的 5 個版本；刪除超過 30 天未被晉升的版本；釘選與 LTS 分支和法規基準線相關的版本。
• 理由：自動化清理可抑制儲存成本，而釘選則保留了可稽核性和回滾能力。

8. 委派最低權限存取

• 行動：將 Owners 角色指派給平台工程團隊；將 Contributors 角色指派給需要發佈/棄用套件的函式庫維護者；將 Readers 角色指派給僅取用 release 成品的產品團隊。
• 理由：將能力與職責對齊；開發人員無需廣泛的管理權限即可取消上架/棄用套件。

9. 使用 Universal packages 管理跨語言工具

• 行動：透過 Universal Publish/Download 任務，將內部 CLI 和 IaC 模組作為 Universal packages 發佈；對其進行語意化版本控制，並透過檢視進行晉升。
• 理由：為非特定語言的資產提供 RBAC、保留和晉升機制，並採用一致的取用模型。

10. 衡量與迭代

• 行動：追蹤摘要儲存空間、快取命中率和晉升前置時間；並據此調整保留閾值、上游政策和晉升標準。
• 理由：隨著產品組合規模的演變，持續的調整可以維持可靠性、成本效益和合規性。

← 監控、可觀測性與回饋 · 所有領域 · 敏捷規劃與工作管理 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Microsoft →