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、ユニバーサルパッケージといったエコシステム全体でパッケージのストレージとガバナンスを一元化します。同時に、パブリックレジストリからのアップストリームキャッシュや、昇格、保持、アクセス許可に関するきめ細かい制御を可能にします。セマンティックバージョニングの自動化とセキュリティ/コンプライアンスツールと組み合わせることで、内部および外部の依存関係が大規模に生成、発見、承認、消費される方法を標準化できます。

Azure Artifactsのコアコンセプト

フィードは、パッケージのストレージとアクセス制御の単位です。チームは通常、製品、プラットフォーム、または信頼境界（例：アップストリーム経由のすべてのパブリックOSS依存関係用のフィード、共有内部ライブラリ用のフィード、製品ごとのフィード）によってフィードを整理します。フィードは複数のパッケージタイプをサポートし、それぞれに独自のクライアントツールがあります。

ビューは、単一フィード内でゲート付きの昇格モデルを実装します。

• local: 新しく発行されたすべてのパッケージがここに表示されます
• prerelease: ベータ版やナイトリービルドを早期導入者や統合パイプラインに公開するために使用されます
• release: 本番環境で承認されたパッケージのみが、広範な消費のためにここに昇格されます コンシューマーは特定のビューを指定することで、不安定なコンテンツを自動的に回避します。リリースプロセスの一環としてバージョンを昇格または降格させ、影響範囲を制御します。

アップストリームソースは、フィードをパブリックレジストリ（NuGet.org、npmjs.com、Maven Central）に接続します。有効にすると、開発者はフィードを通じてパブリックな依存関係を解決します。Azure Artifactsは、使用された正確なバージョンを透過的にプロキシおよびキャッシュし、信頼性を向上させ、エアギャップシナリオを可能にし、後で新しいアップストリームのダウンロードを無効にすることで供給を「凍結」できます。ポリシーに合わせて、フィードごとにどのアップストリームを有効にするかスコープを設定できます。

保持ポリシーは、重要なものを保持しつつストレージコストを削減するために適用されます。パッケージごとに最新のNバージョンを保持する、releaseに昇格したバージョンのみを保持する、古いプレリリースを自動的に削除する、といったポリシーを定義します。特定のバージョンをピン留めして、クリーンアップから除外します（例：長期間存続する製品ブランチに埋め込まれたもの）。監査およびロールバックの要件に合わせて保持期間を設定し、トレーサビリティとストレージコストのバランスを取ります。

フィードのアクセス許可は、最小権限の原則に従います。

• 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ビューに昇格させます。
• 消費: nuget.configにフィードのソースURI（オプションでビューにスコープ指定）を設定します。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タスクを使用して一時的な認証トークンを注入します。ローカルでは、PATを使用してnpm loginします。
• プライベートレジストリ: Azure Artifactsは、npmjs.comへのアップストリームを持つプライベートnpmレジストリとして機能します。承認されていないプレリリースをブロックするために、releaseビューからのみ消費します。

MavenおよびGradle (Java/Kotlin)

• 発行 (Maven): pom.xmlにフィードを指すdistributionManagementを定義し、settings.xmlに認証情報（PATまたはサービス接続）を持つserverエントリを定義します。mvn deployまたはAzure PipelinesのMavenタスクを使用します。
• 発行 (Gradle): maven-publishプラグインを適用し、repositories { maven { url = "https://pkgs.dev.azure.com/..." credentials { } } }を設定し、gradle publishで発行します。
• 依存関係の解決: GradleのrepositoriesまたはMavenのpom.xmlのrepositoriesに、フィードのエンドポイント（オプションでビューのサフィックス付き）を追加します。開発ビルドにはSNAPSHOTを採用し、安定したコンシューマー向けにリリースバージョンをreleaseビューに昇格させます。

ユニバーサルパッケージ (バイナリブロブ、スクリプト、モデル)

• バージョニング: SemVerスタイルまたは整数バージョンに従います。各発行は不変です。言語固有のエコシステムに適合しないアーティファクトにこれを使用します。
• 発行/ダウンロードタスク: パイプラインでAzure DevOpsタスクのUniversal PublishおよびUniversal Downloadを使用するか、Azure CLI（az artifacts universal publish/download）を使用します。Azure DevOpsサービス接続またはログイン済みIDを介して認証します。
• ユースケース: 共有CLI、IaCモジュール、テストデータ、MLモデル、またはRBAC、保持、昇格が必要で言語固有のツールが不要なクロスランゲージアセット。

セキュリティとコンプライアンスの統制

脆弱性スキャンは、コミット時およびビルド時に強制する必要があります。既知の脆弱性を持つ依存関係を特定し、アップグレードのガイダンスを提供するツールを統合します。多くのAzure DevOps環境では、品質ゲート戦略の一環としてSonarQubeが使用され、依存関係のリスクを表面化させるルールを含む問題を警告します。これを補完するために、専用のSCAツール（例：Snyk、Mend/WhiteSource、Black Duck）を使用して、エコシステム全体でより網羅的なCVEカバレッジを確保できます。.NETの場合はdotnet list package --vulnerable、npmの場合はnpm auditが追加のシグナルを提供できます。Javaの場合は、ビルドステップとしてOWASP Dependency-Checkを追加できます。

ライセンスコンプライアンスは、SBOMやマニフェストを承認済みライセンスの許可リストと照合してスキャンすることで強制されます。制限されたライセンスが検出された場合にビルドをブロックするために、Azure Pipelinesには一般的にBlack Duckが追加されます。スキャンレポートはパイプラインアーティファクトとして保存し、監査可能性のためにリリースに添付します。

許可/ブロックされたパッケージは、アドホックな例外としてではなく、ポリシーとして実装するのが最善です。

• 利用者をリリースビューに制限し、精査済みのバージョンのみをプロモートします。
• フリーズが必要な場合は、新規のアップストリームからのダウンロードを無効にし、キャッシュされたバージョンのみが利用可能であることを保証します。
• npmスコープとフィードごとの権限を使用して、名前空間を制限します。
• 許可されていないパッケージやライセンスでビルドが失敗するようにパイプラインチェックを追加し、承認ワークフローとしてアーティファクトのプロモーションを使用します。

監査とガバナンスは、アップストリームのキャッシュを備えた一元化されたフィードから恩恵を受けます。これにより、パッケージ流入のための単一の流入ポイント、不変の履歴、そしてSBOM生成のための一貫した来歴が得られます。

バージョニングの自動化と保持に関する経済性

セマンティックバージョニングは、自動化によって最も簡単に維持できます。

• GitVersionは、Gitの履歴とブランチの命名規則を読み取り、予測可能な方法でバージョンを計算します（例：mainは1.4.0を生成し、feature/*は1.5.0-feature.3を生成します）。モード（MainlineまたはContinuous Delivery）、プレリリースラベル、タグソースを設定します。計算されたバージョンを、パッキングの前にcsproj、package.json、またはGradleのversionプロパティに注入します。
• バージョンの自動インクリメントは、コミットセマンティクスやPRラベルに従うことができます。例えば、choreはインクリメントせず、featはマイナーバージョンを、fixはパッチバージョンをインクリメントし、breaking-changeはメジャーバージョンをインクリメントします。パイプラインステップを使用してbuildNumberを設定し、バージョンをpack/publishタスクに渡します。
• プレリリースラベルは、ブランチの意図を反映する必要があります（例：featureブランチでは-alpha、releaseブランチでは-rc）。プレリリースをプレリリースビューに発行し、ステージングが成功したらリリースにプロモートします。

保持とストレージコストの管理には、プロアクティブなポリシーが必要です。

• 自動クリーンアップ：フィードごとの保持設定を構成し、N日/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. 一元化されたフィードとアップストリームの確立

• アクション: 3つのAzure Artifactsフィードを作成します：「oss-upstream」（NuGet.org、npmjs.com、Maven Centralへのアップストリームを持つ）、「shared-libs」（内部ライブラリ用）、および「productA」（アプリケーションレベルのパッケージ用）。すべてのフィードでビュー（local、prerelease、release）を有効にします。
• 理由: 「oss-upstream」が単一のイングレス（入口）/キャッシュポイントになります。「shared-libs」と「productA」は、信頼境界とプロモーションワークフローを分離します。

2. ビューを介したクライアント消費の設定

• アクション: ランタイムコンシューマー向けには各フィードのreleaseビューに、統合テストパイプライン向けにはprereleaseビューに、nuget.config、.npmrc、settings.xml/Gradleリポジトリを向けます。
• 理由: ビューを使用することで、クライアント設定を変更することなく、昇格され、検証済みのパッケージのみが本番コンシューマーに届くようになります。

3. セマンティックバージョニングによる公開の実装

• アクション: ライブラリとアプリのCIにGitVersionを追加します。dotnet pack、npm version（Gitタギングは行わず、パイプラインによって制御）、およびGradle/Mavenのバージョンフィールドへのバージョン注入を推進します。localに公開し、CI成功時にprereleaseに昇格させ、ステージングテスト後にreleaseに自動昇格させます。
• 理由: Gitフローに沿った決定論的なバージョニングにより、一貫性のあるプレリリースラベルと自動化に対応したプロモーションが保証されます。

4. 認証済みフィードと開発者エクスペリエンスの保護

• アクション: パイプラインでNuGet Authenticateおよびnpm Authenticateタスクを使用します。開発者マシンでAzure Artifacts Credential Providerを有効にします。Azure DevOpsの変数グループを介してローテーションされるPATを使用して、Mavenのsettings.xmlサーバーを設定します。
• 理由: シームレスなトークンベースの認証により、認証情報の拡散を防ぎ、非対話型のCIリストアをサポートします。

5. 脆弱性とライセンスポリシーの強制

• アクション: ビルドにSonarQubeの品質ゲートを追加します。Black Duckを統合して、ライセンスの許可リストを強制し、許可されていないライセンスや高深刻度のCVEを持つビルドをブロックします。npmと.NETについては、npm auditとdotnet list package –vulnerableを実行し、SBOMをビルドアーティファクトとして公開します。
• 理由: 複数の補完的なスキャナーが死角を減らします。Black Duckは大規模なライセンスコンプライアンスを提供し、SonarQubeとエコシステムツールはセキュリティリグレッションを早期に検出します。

6. イングレスの制御と必要に応じた凍結

• アクション: アップストリームからのダウンロードを「oss-upstream」からのみ許可します。インシデント対応中は、供給を凍結するために新しいアップストリームのイングレスを無効にします。ビルドを維持するためにキャッシュされたパッケージに依存します。
• 理由: チョークポイント（ボトルネック）を設けることで、パブリックレジストリが侵害されたり不安定になったりした場合に、迅速な封じ込めが可能になります。

7. 保持と固定（ピン留め）の適用

• アクション: shared-libsとproductAについては最新5バージョンを保持します。30日以上経過した未昇格のバージョンを削除します。LTSブランチや規制ベースラインに関連付けられたバージョンを固定（ピン留め）します。
• 理由: 自動クリーンアップによりストレージコストを抑制し、ピン留めは監査可能性とロールバックを維持します。

8. 最小権限アクセスの委任

• アクション: プラットフォームエンジニアリングにOwners（所有者）を割り当てます。公開/非推奨化を行う必要があるライブラリメンテナーにContributors（貢献者）を割り当てます。リリースアーティファクトのみを消費する製品チームにReaders（閲覧者）を割り当てます。
• 理由: 権限を責任に合わせます。開発者は広範な管理者権限なしに、リストからの削除/非推奨化ができます。

9. クロスランゲージツール用のUniversalパッケージ

• アクション: 社内のCLIやIaCモジュールをUniversalパッケージとして、Universal Publish/Downloadタスク経由で公開します。セマンティックにバージョニングし、ビューを介して昇格させます。
• 理由: 言語に依存しないアセットに対して、RBAC、保持、プロモーション機能を一貫した消費モデルで提供します。

10. 測定と反復

• アクション: フィードのストレージ、キャッシュヒット率、プロモーションのリードタイムを追跡します。それに応じて、保持のしきい値、アップストリームポリシー、プロモーション基準を調整します。
• 理由: 継続的なチューニングにより、ポートフォリオの規模が進化するにつれて、信頼性、コスト効率、コンプライアンスを維持します。

← モニタリング、可観測性、フィードバック · すべてのドメイン · アジャイル計画と作業管理 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Microsoftを閲覧 →