次の方法で共有


フィード ビューとは

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

フィード ビューを使用すると、開発者はパッケージ バージョンのサブセットをコンシューマーと共有できます。 フィードビューの一般的な用途は、テストおよび検証が済んだパッケージバージョンを共有する一方で、まだ開発中であるか、特定の品質基準に達していないパッケージは控えることです。

既定のビュー

すべての成果物フィードには、@local@prerelease@releaseの 3 つのビューがあります。 後者の 2 つのビューは、必要に応じて名前を変更または削除できる推奨ビューです。 @local は、アップストリーム ソースでよく使用される既定のビューです。 フィード設定>ビューで既定のビューを変更できますが、そのビューへの直接発行は有効になりません。 パッケージはベース フィードにのみ発行でき、@Local ビューで使用できます。

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

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

手記

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

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

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

手記

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

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

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

セマンティック バージョンの内訳: 1.2.3 は変更の性質を表し、beta2 は変更の品質を表します。

変更の性質とリスク

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

変更の品質

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

発行パッケージのワークフロー

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

デプロイ セマンティック バージョン