フィード ビューとは

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

フィード ビューを使用すると、開発者はパッケージ バージョンのサブセットをコンシューマーと共有できます。 フィード ビューの一般的な用途は、テストおよび検証されたが、まだ開発中のパッケージや特定の品質バーを満たしていないパッケージを共有することです。

既定のビュー

すべての成果物フィードには、次の 3 つのビューがあります。 @local@prerelease@release 後者の 2 つのビューは、必要に応じて名前を変更または削除できる推奨ビューです。 @local は、アップストリーム ソースでよく使用される既定のビューです。

ビュー @local には、フィードに直接発行されたすべてのパッケージと、アップストリーム ソースから保存されたすべてのパッケージ が含まれます。

フィード ビューは読み取り専用です。つまり、ビューに接続されているユーザーは、そのビューに発行されたパッケージや、以前にアップストリーム ソースから保存されたパッケージのみを使用できます。 使用可能なパッケージの構築方法については、パッケージ グラフを参照してください。

Note

Azure Artifacts では、既定のビュー (@Local) との間でのパッケージの発行と復元のみがサポートされます。

フィード ビューとアップストリーム ソース

フィード ビューとアップストリーム ソースは、パッケージを共有および使用するためのエンタープライズ レベルのソリューションを提供するために連携するように設計されています。 他の Azure Artifacts フィードでフィードをアップストリーム ソースとして使用するには、シナリオに応じて、フィードの可視性 を組織のメンバーまたは Microsoft Entra ID のメンバーに設定する必要があります。 後者を選択すると、組織内のすべてのユーザーがフィードにアクセスできるようになります。 さらに、組織内のすべてのフィードと、同じ Microsoft Entra テナントに関連付けられている他の組織は、フィードのアップストリームにアクセスできます。

Note

パブリック プロジェクト内のすべてのフィード ビューには、インターネット上のすべてのユーザーがアクセスできます。

フィード ビューを使用してパッケージをリリースする

リリース パッケージを作成するときは、変更の性質、変更のリスク、変更の品質という 3 つの情報を伝える必要があります。

変更の性質とリスク

変更の性質とリスクはどちらも変更自体に関係します。つまり、何を行うかは、どちらも作業の開始時に知られています。 新機能を導入する場合、既存の機能を更新する場合、バグに修正プログラムを適用する場合。これが あなたの変化の性質 です。 アプリケーションの API 部分に変更を加える場合は、次の手順を行います。これは、変更のリスクの 1 つの側面です。 多くの NuGet ユーザーは、セマンティック バージョニング (SemVer) 表記を使用して、これら 2 つの情報を伝えます。 SemVer は広く使用されている標準であり、この種の情報を伝達する優れた仕事をします。

変更の品質

一般に、変更の品質は検証プロセスが完了するまで認識されません。 これは、変更がビルドされてパッケージ化された後に行われます。 この詳細のため、バージョン番号の数値セグメント (例: 1.2.3) の変更の品質を伝達することはできません。 事前検証する回避策があります (たとえば、ビルドの DLL をパッケージ化する前に直接使用し、パッケージを "デバッグ" または "CI" 環境に発行し、それらのパッケージを検証して "リリース" 環境に再発行します)。ただし、ビルドされたパッケージが正しい品質基準を満たすことを本当に保証することはできません。

ビューは @Release 、変更の品質を伝える手段として使用できます。 ビューを @Release 使用すると、品質バーを満たすパッケージを共有し、コンシューマーがテスト、検証、使用する準備ができているパッケージ バージョンのサブセットのみを表示できます。

関連記事

• パッケージをビューに昇格します。
• アップストリーム ソースのセットアップ
• 権限の構成