Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022
Azure Artifactsでは、パッケージの発行、保存、共有、使用をチームに 1 つの場所で行うことができます。 フィード、パッケージ、およびコンシューマーの数が増えるにつれて、いくつかの初期の決定によって、パッケージ管理が簡単になるか、保守が困難になる可能性があります。 この記事では、パッケージの復元を予測可能に保ち、より詳細な制御でパッケージをリリースし、時間の経過と共にフィードをより簡単に管理するのに役立つプラクティスをまとめます。
コア ガイダンス
各クライアント構成ファイルで 1 つのフィードを使用し、パブリック レジストリまたは追加の内部ソースも必要な場合は、そのフィードのアップストリーム ソースを有効にします。 この方法により、構成ファイルがよりシンプルになり、フィードの復元動作が予測しやすくなります。 詳細については、「アップストリーム ソースとは」を参照してください。
フィード ビューをリリース チャネルとして扱います。 新しいバージョンを
@localに発行し、そこで検証してから、より広範に使用できるバージョンを@prereleaseまたは@releaseに昇格します。 この方法は、まだ評価されているパッケージ バージョンを、より多くのコンシューマーと共有する準備ができているバージョンから分離するのに役立ちます。 詳細については、「フィード ビューとは」を参照してください。フィードのアクセス許可を意図的に構成します。 パッケージを発行できるユーザー、アップストリーム ソースからパッケージを保存できるユーザー、および共有ビューからパッケージを使用できるユーザーを決定します。 ロールの境界を明確にすると、フィードを保護し、偶発的な変更を減らすことができます。 詳細については、「 フィードのロールとアクセス許可」を参照してください。
古いパッケージ バージョンの蓄積を開始する前に、アイテム保持ポリシーを有効にします。 古いバージョンは、特に更新が活発なフィードではすぐにたまる可能性があります。 保持ポリシーは、ストレージの増加を制御し、フィードを管理しやすくするために必要な労力を減らすのに役立ちます。 詳細については、「 アイテム保持ポリシーを使用してパッケージを自動的に削除する」を参照してください。
パッケージ発行元のベスト プラクティス
次のベスト プラクティスは、一貫性、セキュリティ、およびスムーズなユーザー エクスペリエンスを確保するのに役立ちます。 Azure Artifacts を使用してパッケージを発行する際の主な推奨事項を次に示します。
手記
フィードにパッケージを発行するには、フィード パブリッシャー (共同作成者) 以上である必要があります。 詳細については、 フィードのロールとアクセス許可 に関するページを参照してください。
リポジトリごとに 1 つのフィードを使用します。
フィードは、複数のパッケージの種類をホストできる組織構造です。 プロジェクトでは複数のフィードを使用できますが、通常は、リポジトリを 1 つのプライマリ フィードに接続し続けて競合を減らし、パッケージ管理を簡素化することをお勧めします。 追加のフィードまたはパブリック レジストリのパッケージが必要な場合は、各クライアント構成に複数のフィードを直接追加するのではなく、アップストリーム ソースを使用します。
新しく作成されたパッケージを自動的に発行します。
新しいパッケージの発行を自動化することで、チームまたはターゲット コンシューマーが手動で介入することなく、最新バージョンを確実に使用できるようになります。 パッケージを発行すると、Azure Artifactsフィードの
@localビューにパッケージが追加されます。 フィード ビュー を参照してください。詳細については、 を参照してください。アイテム保持ポリシーを有効にして、古いパッケージ バージョンを自動的にクリーンします。
時間の経過とともに、古いパッケージ バージョンが蓄積され、ストレージが消費され、フィードの管理が困難になる可能性があります。 アイテム保持ポリシーを使用すると、指定した数の最新バージョンを保持しながら、古いパッケージ バージョンを自動的に削除できます。 このプロセスは、ストレージの増加を制御し、フィードの保守を容易にするのに役立ちます。 詳細については、「 アイテム保持ポリシーを使用してパッケージを自動的に削除する 」を参照してください。
フィード ビューを使用してパッケージを解放します。
フィード ビューを使用すると、パッケージ バージョンのサブセットをコンシューマーと共有できます。 たとえば、早期導入者のためにパッケージを
@prereleaseに昇格させ、より広範な使用の準備ができたら@releaseに昇格できます。 ビューに追加されたパッケージは、保持ポリシーの対象外です。 フィード ビュー を参照してください。詳細については、 を参照してください。ビューに対する適切なアクセス許可を確保します。
パッケージが外部チームまたは組織全体で使用されている場合は、
@releaseビューと@prereleaseビューに適切な可視性設定があることを確認します。 詳細については、「フィード ビューの設定」を参照してください。
パッケージ コンシューマーのベスト プラクティス
パッケージを使用する場合は、復元を予測可能にし、パッケージのソースを明確にすることを目指します。
クライアント構成で 1 つのフィードを使用します。
フィードが確定的な復元を提供できるようにするには、クライアント構成でアップストリーム ソースが有効になっている 1 つのフィードのみを参照するようにします。 この方法により、設定ファイルがより簡潔になり、パッケージ解決で予期しない結果が生じる可能性を減らせます。 詳細については、「アップストリーム ソースとは」を参照してください。
外部パッケージのにアップストリーム ソースを使用します。
外部フィードのパッケージや 、NuGet.org や npmjs.com などのパブリック レジストリを使用 する場合は、すべてのクライアント構成にこれらのソースを個別に追加するのではなく、アップストリーム ソースを使用します。 この方法により、チームは、同じフィードを介して内部依存関係と外部依存関係の両方を一貫した方法で復元できます。 詳細については、「 アップストリーム ソースとは」 および「アップストリーム ソース を設定する」を参照してください。
手記
アップストリーム ソースからパッケージを保存するには、フィードおよびアップストリーム リーダー (コラボレーター) 以上である必要があります。 詳細については、 フィードのロールとアクセス許可 に関するページを参照してください。
アップストリーム ソースを意図的に並べ替えます。
フィードはアップストリームソースを順番にチェックし、それを含む最初のソースからパッケージを返します。 複数のアップストリーム ソースを使用する場合は、フィードが目的のソースからパッケージを解決するようにそれらを並べ替えます。 この順序付けは、パブリック レジストリと内部フィードの組み合わせを使用する場合、または組織がカスタマイズされたオープンソース パッケージを内部で再発行する場合に最も重要です。 詳細については、「 アップストリーム ソースを意図的に注文する 」と「 検索順序」を参照してください。
フィード ビューを使用して、コンシューマーに表示される内容を制御します。
チームがフィード ビューを通じて検証済みのパッケージ バージョンを昇格させる場合は、それらのビューを使用して、特定の対象ユーザー向けのパッケージ バージョンのみを共有します。 たとえば、新しく発行されたパッケージを
@localに保持し、@prereleaseを通じてプレビュー ビルドを共有し、承認されたパッケージを@releaseで共有することができます。同じテナント内の組織間ソースのフィード ロケーターを使用します。
ソースが同じMicrosoft Entraテナント内にあるが、組織の一部ではない場合は、フィード ロケーターを使用します。 構文は
azure-feed://<organization>/<projectName>/<feed>@<view>です。