Azure Artifacts

解決する課題

• 社内で作ったライブラリやパッケージを組織内で安全に共有したい（公開レジストリには置けない）
• 複数チーム・複数プロジェクトで同じ依存パッケージを一元管理し、バージョンの食い違いをなくしたい
• 公開レジストリ（nuget.org や npmjs.com など）への直接アクセスを減らし、取得を安定・高速化したい
• 検証が済んだ安定版だけを下流チームに公開し、未検証のプレリリースを混在させたくない
• パッケージの取得・発行で資格情報を平文で埋め込みたくない（CI/CD でも安全に認証したい）

主要概念と用語

• フィード（Feed）: パッケージを保管・共有する単位。組織やプロジェクト単位で作成し、利用者・発行者の権限をここで管理する
• パッケージの種類: NuGet、npm、Maven、Python（PyPI 形式）、ユニバーサルパッケージなど、主要なエコシステムの形式を1つのサービスで扱える
• ユニバーサルパッケージ（Universal Packages）: 特定言語に縛られない任意のファイル群をバージョン付きで保管する形式。ビルド成果物や大きなバイナリの配布に使う
• 上流ソース（Upstream Source）: nuget.org や npmjs.com などの公開レジストリをフィードからプロキシ・キャッシュする仕組み。取得したパッケージはフィードに保存される
• ビュー（View）: フィード内のパッケージを成熟度で段階公開する仕組み。既定で「ローカル」「プレリリース」「リリース」といった区分があり、安定版だけを下流に見せられる
• 権限ロール: 閲覧者・共同作成者・所有者などの役割でフィードへのアクセスを制御する
• 保持ポリシー（Retention Policy）: 未参照の古いパッケージバージョンを自動削除し容量を抑えるルール

仕様・制限・クォータ

• NuGet・npm・Maven・Python・ユニバーサルパッケージといった主要なパッケージ形式を統合的に扱える。クライアントは各エコシステム標準のツール（nuget / npm / mvn / pip / twine など）でそのまま接続する
• フィードのスコープは組織単位またはプロジェクト単位で選べ、可視性や権限の範囲が変わる
• 上流ソースで取得したパッケージはフィードにキャッシュ保存され、以後は外部に出ずに取得できる
• ストレージ消費は保管したパッケージの実体に依存し、未参照バージョンが積み上がると容量が増えるため保持ポリシーでの整理が前提となる
• 課金は保管容量に基づく形が中心で、一定の無料枠を超えた分が従量課金になる。具体的な無料枠やレート上限は変動しうるため公式ドキュメントで最新値を確認する

内部の仕組み

Azure Artifacts は、各パッケージエコシステムの標準プロトコルに対応したマネージドなパッケージリポジトリです。利用者は nuget.org のような公開レジストリの代わりにフィードの URL をパッケージソースとして登録し、標準ツールで発行（push）や取得（restore / install）を行います。フィードは保管・権限・公開範囲を一元的に管理する境界として機能します。

上流ソースを有効にすると、フィードに無いパッケージを要求したときにフィードが公開レジストリへ代理アクセスし、取得した実体をフィード内にキャッシュします。これにより、次回以降は外部に出ずに同じバージョンを取得でき、公開レジストリの障害や削除に左右されにくくなります。自作パッケージと外部パッケージを同じフィード URL から一括取得できる点も利点です。

ビューは、同じフィード内のパッケージを成熟度のラベルで切り分ける仕組みです。発行直後はローカルやプレリリースのビューに置き、検証を通ったものだけをリリースのビューに昇格させると、下流の利用者はリリースのビューを参照するだけで安定版だけを取得できます。

設計パターン / ベストプラクティス

• 自作パッケージと外部パッケージを同一フィードに集約し、上流ソース経由で取得を一本化する
• ビューで成熟度を分離し、下流チームにはリリースのビューだけを参照させて未検証版の混入を防ぐ
• フィードのスコープは公開範囲に合わせ、組織全体で共有するものは組織フィード、限定公開はプロジェクトフィードに分ける
• パッケージのバージョンは**不変（同じバージョンを上書きしない）**運用とし、再現性とロールバックを確保する
• CI/CD からの認証は個人アクセストークンを避け、パイプライン組み込みの認証やサービス接続を使う
• 保持ポリシーで未参照の古いバージョンを定期削除し、容量とコストを抑える

運用・監視

• パッケージの発行・取得や権限変更は Azure DevOps の監査ログで追跡し、誰がいつ何を行ったかを把握する
• パッケージが取得できない → フィードの権限ロール、パッケージソース URL、認証情報（トークンやサービス接続）の有効性を確認する
• 上流から想定バージョンが取れない → 上流ソースの設定と、そのバージョンが上流レジストリに存在するかを確認する
• 容量が増え続ける → 保持ポリシーで未参照バージョンを整理し、不要なフィードやプレリリース版を削除する
• 古い安定版に戻したい → 不変バージョン運用なら該当バージョンを指定して取得するだけで再現できる

コスト

セキュリティ

• フィードは閲覧者・共同作成者・所有者などのロールで最小権限を割り当て、取得だけのチームには発行権限を渡さない
• CI/CD では個人アクセストークンの平文埋め込みを避け、パイプライン組み込みの認証やサービス接続で資格情報を扱う
• 組織外への公開範囲を絞るため、フィードのスコープと可視性を要件に合わせて設定する
• 上流ソースを使うことで外部レジストリから直接ダウンロードする経路を減らし、取得元を統制された1か所に集約できる
• パッケージは不変バージョン運用とし、同一バージョンの差し替えによる供給網の混乱を防ぐ

Well-Architected の観点

• セキュリティ: ロールベースの権限、トークンを埋め込まない認証、公開範囲の限定、上流経由での取得元一元化で、保管と配布の両面を保護する
• オペレーショナルエクセレンス: フィードとビューによる段階公開、保持ポリシー、Azure Pipelines 統合で、パッケージのライフサイクルを仕組み化する
• 信頼性: 上流ソースのキャッシュで外部レジストリの障害や削除に左右されにくくし、不変バージョンで再現性を担保する
• コスト最適化: 保持ポリシーと不要バージョンの整理、無料枠の把握で保管コストのムダを削る

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# Azure DevOps の拡張をインストールしてサインイン
az extension add --name azure-devops
az devops login

# 既定の組織とプロジェクトを設定
az devops configure --defaults \
  organization=https://dev.azure.com/myorg \
  project=myproject

# プロジェクトスコープのフィードを作成
az artifacts universal publish \
  --feed myfeed \
  --name mytool \
  --version 1.0.0 \
  --path ./dist \
  --description "build artifacts"

# ユニバーサルパッケージを取得（ダウンロード）
az artifacts universal download \
  --feed myfeed \
  --name mytool \
  --version 1.0.0 \
  --path ./download

# npm から使う場合は、フィードの URL を registry として .npmrc に登録し
# パイプラインの組み込み認証で push / install する（トークンは平文で書かない）
npm publish --registry https://pkgs.dev.azure.com/myorg/_packaging/myfeed/npm/registry/