Azure DevOps Services |Azure DevOps Server 2022 |Azure DevOps Server 2020
Azure Artifacts を使用すると、パッケージ管理を合理化してコラボレーションを強化し、パッケージの整合性を確保し、バージョン管理、アクセス制御、フィード管理などのさまざまな機能を活用できます。
重要な概念
Azure Artifacts には、ファイル共有よりもいくつかの利点があります。
インデックス作成:
Azure Artifacts では、各フィード内にパッケージのインデックスが保持され、簡単なリスト操作が可能になります。 これに対し、ファイル共有を使用する場合、NuGet クライアントが認識するインデックスでファイル共有が構成されていない限り、クライアントは各 nupkg ファイルを開き、nuspec メタデータを検査する必要があります。
不変:
各パッケージ バージョンは、依存関係の整合性を維持するために 1 回だけフィードにプッシュできます。 これにより、そのバージョンへの参照が常に正確であることが保証されます。 ただし、バージョン番号を変更せずに更新されたバイナリを含むパッケージを発行するワークフローがある場合、Azure Artifacts フィードに移行するときにこれらのワークフローで問題が発生します。 詳細については、「 不変性 」を参照してください。
形式の一貫性:
Azure Artifacts では、プッシュされたすべてのパッケージに対して徹底的な検証が実行され、整合性と正確性が確保されます。 この検証プロセスにより、無効なパッケージが開発環境とビルド環境に入らないようにします。 ただし、構造が正しくないパッケージを発行するワークフローでは、Azure Artifacts フィードに移行するときに問題が発生することに注意してください。
認証と承認
現在 Active Directory でサポートされているファイル共有を利用している場合は、自分とオンプレミスのビルド エージェントが Windows NTLM を使用して自動的に認証される可能性があります。 パッケージを Azure Artifacts に移行するには、いくつかの調整が必要です。
認証: パッケージをプッシュおよび復元するには、NuGet クライアントへのアクセスを提供する必要があります。
- Visual Studio: 資格情報の取得は自動的に行われます。
- nuget.exe: 資格情報の取得は、 Azure Artifacts 資格情報プロバイダーをインストールした後に自動的に行われます。
認可: パッケージへのアクセスを必要とするユーザー、サービス、組織、またはグループに、必要なアクセス許可が設定されていることを確認します。 詳細については、 アクセス許可 のセクションを参照してください。
パッケージの移行は 4 段階のプロセスです。
既存のパッケージ ソースのインベントリ
構成を変更する前に、既存のパッケージ ソースのインベントリを作成することが重要です。 これには、セットアップで現在使用されているすべてのパッケージ ソースの識別と一覧表示が含まれます。 このインベントリを実施することで、移行または再構成する必要があるパッケージ ソースを包括的に理解できるようになります。 Start b
コードベース内の nuget.config ファイル (ソリューション (.sln) ファイルと同じフォルダーにある可能性があります。
既定の NuGet 構成ファイルは次のとおりです。
- ウィンドウズ:
%APPDATA%\NuGet\NuGet.Config
- macOS/Linux:
~/.config/NuGet/NuGet.Config
または~/.nuget/NuGet/NuGet.Config
- ウィンドウズ:
パッケージ ソースに関連付けられているサーバー パス ( <add key="SMBNuGetServer" value="\\server\share\NuGet" />
など) を特定し、そのコピーを作成します。 このサーバー パスの一覧は、以降のセクションで移行プロセスに使用されます。
アクセス制御戦略を計画する
新しいフィードを構成する場合、次の 2 つのオプションがあります。
- 既存のファイル共有のアクセス許可と一致するようにフィードのアクセス許可を構成します。
- フィードのアクセス許可を、Azure DevOps で既に設定されているチームとグループに合わせます。
既存のファイル共有のアクセス許可をレプリケートする場合は、パッケージを含む各共有のアクセス許可を書き留めます。 具体的には、次のユーザーまたはグループを書き留めます。
フル コントロール
読み取り または 一覧表示
書き込み または 変更
フィードを設定する
現在のパッケージ ソースのインベントリを完了したら、フィードを構成します。 この手順では、SMB 共有へのフィードの 1 対 1 のマッピングを想定します。
SMB 共有ごとに、指示に従って フィードを作成します。
フィード名を SMB 共有フォルダーの名前と一致するように設定します。
フィード の可視性、 アップストリーム ソース、スコープを選択 します。
作成したフィードごとに、 フィードのアクセス許可 を設定するときに考慮する必要があるフィードのアクセス許可のセットがあります。
既存のファイル共有のアクセス許可と一致するように新しいフィードのアクセス許可を構成する場合は、次の表を参照して、ユーザーに適切なアクセス許可を割り当てます。
ファイル共有権限 | フィードのアクセス許可 |
---|---|
フル コントロール | 所有者 |
書き込みまたは変更 | 貢献者 |
読み取りまたは一覧表示 | 読者 |
パッケージを移行する
フィードごとに、[ Artifacts>Connect to feed] に 移動し、[ NuGet.exe] を選択します。 [プロジェクトのセットアップ] セクションで指定したソース URL をコピーします。 このソース URL は、NuGet 構成を更新し、パッケージを移行するために必要です。
フィードを設定したら、フィードで認証し、パッケージを発行するようにプロジェクトを設定できるようになりました。 次の手順に進む前に、最新バージョンの Azure Artifacts 資格情報プロバイダー がインストールされていることを確認してください。
注
NuGet バージョン 5.5.x 以降を使用することをお勧めします。これには、キャンセルとタイムアウトに対処する重要なバグ修正が含まれています。
nuget.config ファイルが .csproj または .sln ファイルと同じフォルダーにあることを確認します。 ファイルの配置を確認したら、次のスニペットを nuget.config ファイルに追加します。 プレースホルダーを適切な値に置き換えます。
- 組織の範囲指定フィード:
<?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <clear /> <add key="<FEED_NAME>" value="https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/_packaging/<FEED_NAME>/nuget/v3/index.json" /> </packageSources> </configuration>
- プロジェクト スコープ フィード:
<?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <clear /> <add key="<FEED_NAME>" value="https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/<PROJECT_NAME>/_packaging/<FEED_NAME>/nuget/v3/index.json" /> </packageSources> </configuration>
次の
push
コマンドを実行して、すべてのパッケージを新しいフィードに発行します。 ApiKey 引数の値として任意の文字列を指定できます。nuget.exe push -Source <FEED_NAME> -ApiKey Az <PACKAGE_PATH>\*.nupkg
ヒント
大規模なチームの場合は、移行中にパッケージを追加または更新しないように、 nuget push
操作を実行する前に、各共有を読み取り専用としてマークすることを検討する必要があります。
Azure Pipelines もワークフローに組み込む場合は、フィードにパッケージを発行するための適切なアクセス許可を確実に持つよう、パイプラインを更新してください。 詳細については、「 Azure Pipelines を使用して NuGet パッケージを発行する 」と「 Azure Pipelines を使用して NuGet パッケージを復元する 」を参照してください。
関連記事
- Visual Studio を使用して NuGet パッケージをインストールする
- パッケージを NuGet.org に発行する
- パッケージの削除と回復