成果物と成果物ソースのリリース

Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2015

注意

Microsoft Team Foundation Server (TFS) 2018 以前のバージョンでは、ビルドとリリースの "パイプライン" は "定義"、"実行" は "ビルド"、"サービス接続" は "サービス エンドポイント"、"ステージ" は "環境"、"ジョブ" は "フェーズ" と呼ばれます。

注意

このトピックでは、クラシック リリース パイプラインについて説明します。 YAML パイプラインの成果物を理解するには、成果物に関するページ を参照してください

リリースは、CI/CD プロセス内のDevOpsのコレクションです。 成果物 とは、アプリケーションのデプロイ可能なコンポーネントのことです。 Azure Pipelines、さまざまなアーティファクト ソースによって生成され、さまざまな種類のアーティファクト リポジトリに格納されている成果物をデプロイできます。

リリース パイプライン を作成するときに、 適切な成果物ソース をリリース パイプラインにリンクします。 たとえば、ビルド パイプラインまたは Jenkins Azure Pipelinesをリリース パイプラインにリンクできます。

リリース を作成する場合 は、これらの成果物ソースの正確なバージョンを指定します。たとえば、プロジェクトからのビルドの数Azure Pipelines Jenkins プロジェクトからのビルドのバージョンなどです。

リリースが作成された後は、これらのバージョンを変更することはできません。 リリースは、基本的に、リリースを構成するバージョン管理された成果物によって定義されます。 リリースをさまざまなステージにデプロイする場合は、すべてのステージで同じ成果物をデプロイして検証します。

1 つのリリース パイプラインを複数の成果物ソース にリンクできます。そのうちの 1 つはプライマリ ソース です。 この場合、リリースを作成するときに、これらのソースごとに個別のバージョンを指定します。

Artifactsとリリースで使用する

Artifactsの多くの機能の中心Azure Pipelines。 成果物のリリース パイプラインへのリンクに依存する機能の一部を次に示します。

  • 自動トリガーは を解放します。 新しいバージョンの成果物が生成されるたびに自動的に作成される新しいリリースを構成できます。 詳細については、「継続的デプロイ トリガー 」を参照してください。 リリースを自動的に作成する機能は、一部の成果物ソースでのみ使用できます。

  • トリガー条件。 リリースを自動的に作成するか、成果物の特定の条件だけが満たされた場合に自動的にトリガーされるステージへのリリースのデプロイを構成できます。 たとえば、特定のブランチから新しいビルドが生成された場合にのみ自動的に作成されるリリースを構成できます。

  • 成果物のバージョン。 特定のバージョンのビルド成果物を自動的に使用したり、常に最新バージョンを使用したり、リリースの作成時にバージョンを指定したりするために、リリースを構成できます。

  • 成果物変数。 リリースの一部であるすべての成果物には、メタデータが関連付け、変数 を介して タスク公開されます。 このメタデータには、成果物のバージョン番号、成果物の生成元のコードの分岐 (ビルド成果物またはソース コード成果物の場合)、成果物を生成したパイプライン (ビルド成果物の場合) が含まれます。 この情報は、デプロイ タスクでアクセスできます。 詳細については、「アーティファクト変数」 を参照してください

  • 作業項目とコミット。 リリースの一部である作業項目またはコミットは、成果物のバージョンから計算されます。 たとえば、 の各ビルドAzure Pipelines一連の作業項目とコミットに関連付けられているとします。 リリース内の作業項目またはコミットは、現在のリリースと以前のリリースの間のすべての作業項目とすべてのビルドのコミットの共用体として計算されます。 現在、Azure Pipelines特定の成果物ソースについてのみ作業項目とコミットを計算できる点に注意してください。

  • 成果物のダウンロード。 リリースがステージにデプロイされるたびに、既定では Azure Pipelines によって、そのリリース内のすべての成果物が、デプロイ ジョブが実行されるエージェントに自動的にダウンロードされます。 成果物をダウンロードする手順は、成果物の種類によって異なります。 たとえば、複数のAzure Pipelinesを並列でダウンロードするアルゴリズムを使用して、複数の成果物がダウンロードされます。 Git 成果物は、Git ライブラリ機能を使用してダウンロードされます。 詳細については、「成果物のダウンロード」 を参照してください

成果物ソース

成果物を生成または格納するために、アプリケーションライフサイクル プロセスで使用できるツールには、いくつかの種類があります。 たとえば、Azure Pipelines、Jenkins、TeamCity などの継続的インテグレーション システムを使用して成果物を生成できます。 Git や TFVC などのバージョン管理システムを使用して、成果物を格納する場合があります。 または、Azure Artifacts や NuGet などのリポジトリを使用して成果物を格納することもできます。 これらのすべてのソースからAzure Pipelinesをデプロイする構成を構成できます。

既定では、リリース パイプラインから作成されたリリースでは、最新バージョンの成果物が使用されます。 成果物ソースをリリース パイプラインにリンクするときに、タグ、特定のバージョンを指定して、特定のブランチから最新のビルドを使用するオプションのいずれかを選択するか、ユーザーがパイプラインからリリースを作成するときにバージョンを指定することで、この動作を変更できます。

成果物の追加

複数の成果物セットをリンクする場合は、プライマリ (既定値) を指定できます。

既定のバージョン オプションの選択

重要

ドロップダウン Artifacts Default version の項目は、リンクされたビルド repository type 定義の によって異なります。

  • 次のオプションは、および のすべてのリポジトリの種類 Specify at the time of release creation Specific version でサポートされています Latest

  • Latest from a specific branch with tags オプション Latest from the build pipeline default branch with tags と オプションは、および のリポジトリ TfsGit GitHub の種類 Bitbucket でサポートされています GitHubEnterprise

  • Latest from the build pipeline default branch with tags は、ビルド定義 XAML ではサポートされていません。

次のセクションでは、さまざまな種類の成果物ソースを使用する方法について説明します。

成果物ソース - Azure Pipelines

リリース パイプラインは、プロジェクト コレクションまたは TFS プロジェクト コレクション内のAzure Pipelinesにリンクできます。

注意

ビルド パイプラインに 発行Artifacts タスクを含める必要があります。 XAML ビルド パイプラインの場合、名前がドロップされた成果物 暗黙的に発行されます。

TFS の異なるバージョンとバージョン間の機能の違いには、次Azure Pipelinesがあります。

  • TFS 2015: コレクションの同じプロジェクトからのみビルド パイプラインをリンクできます。 複数の定義をリンクできますが、既定のバージョンを指定することはできません。 継続的デプロイ トリガーは、1 つの定義でのみ設定できます。 複数のビルド パイプラインがリンクされている場合は、リリースの作成をトリガーしたビルドと共に、他のすべての定義の最新のビルドが使用されます。

  • TFS 2017 以降 Azure Pipelines: Azure Pipelines または TFS 内の任意のプロジェクトからビルド パイプラインをリンクできます。 複数のビルド パイプラインをリンクし、それぞれの既定値を指定できます。 複数のビルド ソースで継続的デプロイ トリガーを設定できます。 ビルドが完了すると、リリースの作成がトリガーされます。

次の機能は、新しいソースを使用Azure Pipelinesできます。

機能 ソースのAzure Pipelines動作
自動トリガー リリース 新しいビルド (XAML ビルドを含む) が生成されると、新しいリリースを自動的に作成できます。 詳細については 、「継続的デプロイ」 を参照してください。 ビルド パイプライン内で何も構成する必要はありません。 TFS のバージョンの違いについては、上記の注意事項を参照してください。
成果物変数 複数の成果物変数が、Azure Pipelines からのビルドでサポートされています。
作業項目とコミット Azure Pipelinesは、TFS およびプロジェクトの作業項目と統合Azure Pipelines。 これらの作業項目は、リリースの詳細にも表示されます。 Azure Pipelines TFVC や Git、GitHub、Subversion、その他の Git リポジトリなど、さまざまなバージョン管理システムと統合されます。 Azure Pipelinesは、TFVC または Git のソース コードからビルドが生成された場合にのみコミットを表示します。
成果物のダウンロード 既定では、ビルド成果物はエージェントにダウンロードされます。 ステージで、成果物のダウンロードを スキップするオプション を構成できます。
ビルドのデプロイ セクション ビルドの概要には、[ デプロイ] セクションが 含まれています。このセクションには、ビルドがデプロイされたすべてのステージが一覧表示されます。

既定では、リリースはコレクション レベルのジョブ承認スコープを使用して で実行されます。 つまり、リリースは組織内のすべてのプロジェクト (またはプロジェクトのコレクション) 内のリソースAzure DevOps Server。 これは、他のプロジェクトからビルド成果物をリンクする場合に便利です。 プロジェクト設定で リリース パイプラインの [ジョブ承認スコープを現在のプロジェクトに制限する] を有効にして、プロジェクト内のリリースの成果物へのアクセスを制限できます。

組織のジョブ承認スコープを設定するには:

  • ユーザー インターフェイスの [組織の設定] ページAzure DevOps移動します。
  • [設定] の下にある [Pipelines] を選択します。
  • リリース パイプラインの [ ジョブ承認スコープを現在 のプロジェクトに制限する] トグルをオンにし、スコープを現在のプロジェクトに制限します。 これは、パイプラインのセキュリティを強化するために推奨される設定です。

特定のプロジェクトのジョブ承認スコープを設定するには:

  • ユーザー インターフェイスの [プロジェクト設定] ページAzure DevOps移動します。
  • [設定] の下にある [Pipelines] を選択します。
  • [ジョブ承認スコープを現在のプロジェクトに制限する] トグルをオンにし、スコープをプロジェクトに制限します。 これは、パイプラインのセキュリティを強化するために推奨される設定です。

注意

スコープが組織レベルで project に設定されている場合、各プロジェクトのスコープを変更することはできません。

リリース内のすべてのジョブは、ジョブ承認スコープをコレクションに設定して実行されます。 つまり、これらのジョブは、プロジェクト コレクション内のすべてのプロジェクトのリソースにアクセスできます。

成果物ソース - TFVC、Git、および GitHub

ビルド パイプラインを通さずに、バージョン管理システムに格納されている成果物を直接使用するシナリオがあります。 次に例を示します。

  • 明示的なビルド パイプラインを必要としない PHP または JavaScript アプリケーションを開発しています。

  • さまざまなバージョン管理リポジトリのさまざまなステージの構成を管理し、これらの構成ファイルをデプロイ パイプラインの一部としてバージョン管理から直接使用する必要があります。

  • インフラストラクチャと構成をコード (Azure Resource Manager テンプレートなど) として管理し、これらのファイルをバージョン管理リポジトリで管理する必要があります。

1 つのリリース パイプラインで複数の成果物ソースを構成できます。そのため、アプリケーションのバイナリを生成するビルド パイプラインと、構成ファイルを同じパイプラインに格納するバージョン管理リポジトリの両方をリンクし、デプロイ時に 2 つの成果物セットを一緒に使用できます。

Azure Pipelines(TFVC) Team Foundation バージョン管理(TFVC) リポジトリ、Git リポジトリ、および他のリポジトリGitHub統合されます。

リリース パイプラインは、コレクション内の任意のプロジェクトの Git または TFVC リポジトリにリンクできます (これらのリポジトリへの読み取りアクセスが必要になります)。 同じコレクション内にバージョン管理成果物をデプロイする場合、追加のセットアップは必要ありません。

Git または GitHub リポジトリ をリンク し、 ブランチを選択すると、成果物の保存後に成果物の種類の既定のプロパティを編集できます。 これは、安定したバージョンの成果物のブランチが変更され、継続的デリバリー リリースでこのブランチを使用して新しいバージョンの成果物を取得する必要があるシナリオで特に役立ちます。 チェックアウトサブモジュールと LFS 追跡ファイルのかどうか、浅いフェッチの深さなど、チェックアウトの詳細を指定することもできます。

TFVC ブランチ をリンクするときに、リリースの作成時にデプロイする変更セットを指定できます。

TFVC、Git、およびデータ ソースを使用する場合は、次のGitHub使用できます。

機能 TFVC、Git、およびデータ ソースGitHub動作
自動トリガー リリース リリース パイプラインでリポジトリにプッシュする継続的デプロイ トリガーを構成できます。 これにより、リポジトリに対して新しいコミットが行われたときに、リリースが自動的にトリガーされます。 「 トリガー」を参照してください
成果物変数 バージョン管理 ソースでは、 多数の成果物変数がサポートされています。
作業項目とコミット Azure Pipelinesを使用している場合、リリースに関連付けられている作業項目やコミットを表示することはできません。
成果物のダウンロード 既定では、バージョン管理成果物はエージェントにダウンロードされます。 ステージで、成果物のダウンロードを スキップするオプション を構成できます。

既定では、リリースはコレクション レベルのジョブ承認スコープを使用して で実行されます。 つまり、リリースは組織内のすべてのリポジトリ (または組織のコレクション) にAzure DevOps Server。 プロジェクト設定で リリース パイプラインの [ジョブ承認スコープを現在のプロジェクトに制限する] を有効にして、プロジェクト内のリリースの成果物へのアクセスを制限できます。

成果物ソース - Jenkins

Jenkins 成果物を使用するには、Jenkins サーバーに接続するための資格情報を使用してサービス接続を作成する必要があります。 詳細については、「サービス接続」「Jenkins サービス接続」を参照してください。 その後、Jenkins プロジェクトをリリース パイプラインにリンクできます。 成果物を発行するには、ビルド後のアクションを使用して Jenkins プロジェクトを構成する必要があります。

Jenkins ソースを使用する場合は、次の機能を使用できます。

機能 Jenkins ソースでの動作
自動トリガー リリース リリース パイプラインでリポジトリにプッシュする継続的デプロイ トリガーを構成できます。 これにより、リポジトリに対して新しいコミットが行われたときに、リリースが自動的にトリガーされます。 「 トリガー」を参照してください
成果物変数 Jenkins からのビルドでは 、多数の成果物変数がサポートされています。
作業項目とコミット Azure Pipelines Jenkins ビルドの作業項目やコミットを表示することはできません。
成果物のダウンロード 既定では、Jenkins ビルドはエージェントにダウンロードされます。 ステージで、成果物のダウンロードを スキップするオプション を構成できます。

Artifacts Jenkins ビルドによって生成されたデータは、通常、アーカイブと共有のためにストレージ リポジトリに反映されます。 Azure Blob Storage はサポートされているリポジトリの 1 つで、リリース パイプラインで成果物ソースとして Azure Storage に発行する Jenkins プロジェクトを使用できます。 デプロイでは、成果物が Azure からエージェントに自動的にダウンロードされます。 この構成では、エージェントと Jenkins サーバー間の接続は必要ありません。 Microsoft ホステッド エージェントは、サーバーをインターネットに公開せずに使用できます。

注意

Azure Pipelines、たとえばエンタープライズ ネットワーク内にある場合、Jenkins サーバーに接続できない場合があります。 この場合は、Jenkins Azure Pipelinesアクセスできるオンプレミス エージェントを設定することで、Jenkins と統合できます。 ビルドにリンクするときに Jenkins プロジェクトの名前は表示されますが、これをリンク ダイアログ フィールドに入力できます。

Jenkins 統合機能の詳細については、「Jenkinsジョブ、Azure Pipelines、および Pipelines との統合」をArtifacts。

成果物ソース - Azure Container Registry、Docker、Kubernetes

コンテナー化されたアプリを展開するとき、コンテナー イメージはコンテナー レジストリに最初にプッシュされます。 プッシュが完了したら、コンテナー イメージを Web App for Containers Docker/Kubernetes クラスターにデプロイできます。 資格情報を使用してサービス接続を作成して、サービスに接続して、そこに配置されたイメージまたは Azure にデプロイする必要があります。 詳細については、「サービス接続」 を参照してください

次の機能は、Azure Container Registry、Docker、Kubernetes ソースを使用する場合に使用できます。

機能 Docker ソースでの動作
自動トリガー リリース イメージの継続的デプロイ トリガーを構成できます。 これにより、リポジトリに対して新しいコミットが行われたときに、リリースが自動的にトリガーされます。 「 トリガー」を参照してください
成果物変数 ビルドでは 、多数の成果物 変数がサポートされています。
作業項目とコミット Azure Pipelinesやコミットを表示することはできません。
成果物のダウンロード 既定では、ビルドはエージェントにダウンロードされます。 ステージで、成果物のダウンロードを スキップするオプション を構成できます。

注意

複数の成果物ソース (複数のレジストリ/リポジトリ) からの継続的なデプロイの場合、成果物ソースをマップして特定のステージをトリガーできない。 成果物ソースへのプッシュがある場合は、いつでもリリースが作成されます。 成果物ソースをマップして特定のステージをトリガーする場合は、リリース パイプラインを複数のリリース パイプラインに分解することが推奨されます。

成果物ソース - Azure Artifacts

これらの成果物を使用するシナリオは次のとおりです。

  1. アプリケーション ビルド (TFS、Azure Pipelines、TeamCity、Jenkins など) をパッケージとして Azure Artifacts に発行し、リリースで成果物を使用する必要があります。
  2. アプリケーションのデプロイの一環として、追加のパッケージを Azure Artifacts。

このような成果物をリリース パイプラインにリンクする場合は、パッケージのフィード、パッケージ、および既定のバージョンを選択する必要があります。 パッケージの最新バージョンを選択するか、特定のバージョンを使用するか、リリース作成時にバージョンを選択することができます。 デプロイ時に、パッケージがエージェント フォルダーにダウンロードされ、ジョブの実行の一部として内容が抽出されます。

次の機能は、新しいソースを使用Azure Artifacts使用できます。

機能 ソースのAzure Artifacts動作
自動トリガー リリース パッケージの継続的デプロイ トリガーを構成できます。 これにより、パッケージが更新されると、リリースが自動的にトリガーされます。 「 トリガー」を参照してください
成果物変数 パッケージでは 、多数の成果物 変数がサポートされています。
作業項目とコミット Azure Pipelinesやコミットを表示することはできません。
成果物のダウンロード 既定では、パッケージはエージェントにダウンロードされます。 ステージで、成果物のダウンロードを スキップするオプション を構成できます。

Maven スナップショットの処理

Maven スナップショットの場合、複数のバージョンを一度にダウンロードできます (例: myApplication-2.1.0.BUILD-20190920.220048-3.jar myApplication-2.1.0.BUILD-20190820.221046-2.jar myApplication-2.1.0.BUILD-20190820.220331-1.jar 、、)。 古いコピーを削除し、デプロイ前に最新の成果物のみを保持する必要がある場合があります。 管理者特権でのコマンド プロンプトで次の PowerShell コマンドを実行して、辞書式の値が最も高いコピーを除くすべてのコピーを削除します。

Get-Item "myApplication*.jar" | Sort-Object -Descending Name | Select-Object -SkipIndex 0 | Remove-Item

注意

フィードには最大 30 の Maven スナップショットを格納できます。 上限に達すると、25 Azure Artifactsスナップショットが自動的に削除されます。 このプロセスは、30 以上のスナップショットがフィードに発行されるたび自動的にトリガーされます。

成果物ソース - 外部またはオンプレミスの TFS

オンプレミスの TFS Azure Pipelines発行された成果物をデプロイするには、 を使用します。 TFS サーバーをインターネットに表示する必要はありません。オンプレミスのオートメーション エージェントを設定しただけ。 オンプレミスの TFS サーバーからビルドがオンプレミス エージェントに直接ダウンロードされ、指定されたターゲット サーバーにデプロイされます。 エンタープライズ ネットワークから離れるのではありません。 これにより、オンプレミスの TFS サーバーへのすべての投資を活用し、オンプレミスのリリース機能を利用Azure Pipelines。

ヒント

このメカニズムを使用して、ある Azure Pipelines サブスクリプションで発行された成果物を別の Azure Pipelines にデプロイしたり、別の Team Foundation Server で公開された成果物を別の Team Foundation Server からデプロイしたりできます。

これらのシナリオを有効にするには、Marketplace から拡張機能用の TFS成果物Azure PipelinesインストールVisual Studioがあります。 次に、資格情報を使用してサービス接続を作成して TFS サーバーに接続します (詳細については、 サービス接続に関するページ を参照してください)。

その後、TFS ビルド パイプラインをリリース パイプラインにリンクできます。 [種類 ] ボックスの一覧で [外部 TFS ビルド ] を選択 します。

外部 TFS ソースを使用する場合は、次の機能を使用できます。

機能 外部 TFS ソースでの動作
自動トリガー リリース リリース パイプラインで外部 TFS ソースの継続的デプロイ トリガーを構成することはできません。 ビルドの完了時に新しいリリースを自動的に作成するには、Azure Pipelines REST API を呼び出して新しいリリースを作成するために、外部 TFS サーバーのビルド パイプラインにスクリプトを追加する必要があります。
成果物変数 外部 TFS ソースでは、 多数の成果物変数がサポートされています。
作業項目とコミット Azure Pipelines TFS ソースの作業項目またはコミットを表示することはできません。
成果物のダウンロード 既定では、外部 TFS 成果物はエージェントにダウンロードされます。 ステージで、成果物のダウンロードを スキップするオプション を構成できます。

注意

Azure Pipelines、エンタープライズ ネットワーク内にある場合、オンプレミスの TFS サーバーに接続できない場合があります。 その場合は、TFS Azure Pipelinesアクセスできるオンプレミス エージェントを設定することで、TFS と統合できます。 ビルドにリンクするときに TFS プロジェクトの名前やビルド パイプラインを表示できないが、リンク ダイアログ のフィールドにこれらの変数を含め得る。 また、リリースを作成するときに、Azure Pipelines TFS サーバーに対してビルド番号を照会できない場合があります。 代わりに、目的のビルドのビルド ID (ビルド番号ではない) を適切なフィールドに入力するか、[最新のビルド] を選択 します。

成果物ソース - TeamCity

TeamCity と統合するには、まず Marketplace から拡張機能のTeamCity 成果物Azure Pipelinesインストールする必要があります。

TeamCity 成果物を使用するには、まず、資格情報を使用して TeamCity サーバーに接続するサービス接続を作成します (詳細については、サービス接続に関 するページ を参照してください)。

その後、TeamCity ビルド構成をリリース パイプラインにリンクできます。 TeamCity ビルド構成は、成果物を発行するアクションを使用して構成する必要があります。

TeamCity ソースを使用する場合は、次の機能を使用できます。

機能 TeamCity ソースでの動作
自動トリガー リリース リリース パイプラインで TeamCity ソースの継続的デプロイ トリガーを構成することはできません。 ビルドの完了時に新しいリリースを自動的に作成するには、Azure Pipelines REST API を呼び出して新しいリリースを作成するスクリプトを TeamCity プロジェクトに追加します。
成果物変数 TeamCity からのビルドでは、 多数の成果物変数がサポートされています。
作業項目とコミット Azure Pipelines TeamCity ビルドの作業項目やコミットを表示することはできません。
成果物のダウンロード 既定では、TeamCity ビルドはエージェントにダウンロードされます。 ステージで、成果物のダウンロードを スキップするオプション を構成できます。

注意

Azure Pipelines、たとえばエンタープライズ ネットワーク内にある場合、TeamCity サーバーに接続できない場合があります。 この場合は、TeamCity Azure Pipelinesアクセスできるオンプレミス エージェントを設定することで、TeamCity と統合できます。 ビルドにリンクするときに TeamCity プロジェクトの名前を表示できないが、これをリンク ダイアログ フィールドに入力できます。

成果物ソース - カスタム成果物

組み込みの成果物ソースに加えて、Azure Artifactsカスタム成果物ソースと成果物拡張モデルの統合がサポートされています。 任意のカスタム成果物ソースをプラグインできます。Azure DevOps、ファーストクラスのユーザー エクスペリエンスとシームレスな統合が提供されます。

詳細については、「Azure DevOps成果物拡張モデル」を参照してください

成果物ソース - その他のソース

アーティファクトは、他の種類のソース (NuGet リポジトリなど) によって作成および公開される場合があります。 Azure Pipelines でサポートされている成果物ソースの種類は引き続き拡張しますが、特定のソースの種類のサポートを待たずに使用を開始できます。 リリース パイプライン内の成果物ソースのリンクをスキップし、ソースから成果物を直接ダウンロードするカスタム タスクをステージに追加します。

成果物ソースの別名

すべての成果物のダウンロードの一意性を確保するために、リリース パイプラインにリンクされている各成果物ソースには、 と呼ばれる特定のダウンロード場所が自動的に提供されます _source alias_ 。 この場所には、 変数を使用してアクセスできます。

$(System.DefaultWorkingDirectory)\[source alias]

また、この一意性により、後でリンクされた成果物ソースの名前を元の場所に変更した場合 (たとえば、Azure Pipelines のビルド パイプラインの名前や Jenkins のプロジェクトの名前を変更する)、エージェントで定義されているダウンロード場所が変更されないので、タスクのプロパティを編集する必要が生じずにいます。

ソースエイリアスは、既定では、成果物ソースをリンクするときに選択されたソースの名前で、先頭にアンダースコアが付きます。成果物ソースの種類に応じて、これはビルド パイプライン、ジョブ、プロジェクト、またはリポジトリの名前になります。 ソース エイリアスは、リリース パイプラインの [成果物] タブから編集できます。たとえば、ビルド パイプラインの名前を変更し、ビルド パイプラインの名前を反映するソース エイリアスを使用する場合などです。

プライマリ ソース

複数の成果物ソースをリリース パイプラインにリンクすると、そのうちの 1 つがプライマリ成果物ソースとして指定されます。 プライマリ成果物ソースは、事前に定義された多数の変数 を設定するために 使用されます。 また、リリースの名前付け にも使用できます

成果物のダウンロード

リリースをステージにデプロイすると、各ソースのバージョン管理された成果物が既定で Automation エージェントにダウンロードされ、そのステージ内で実行されているタスクでこれらの成果物をデプロイできます。 エージェントにダウンロードされた成果物は、リリースの完了時には削除されません。 ただし、次のリリースを開始すると、ダウンロードした成果物は削除され、新しい成果物のセットに置き換えられる。

リリースを開始すると、エージェント内の新しい一意のフォルダーがリリース パイプラインごとに作成され、そのフォルダーに成果物がダウンロードされます。 変数 $(System.DefaultWorkingDirectory) は、このフォルダーにマップされます。

Azure Pipelinesリリースが再びデプロイされた場合、変更されていない成果物をダウンロードしないように最適化は現在実行されていません。 また、新しいリリースを開始すると、以前にダウンロードしたコンテンツは常に削除されます。Azure Pipelinesエージェントへの増分ダウンロードを実行することはできません。

ただし、必要にAzure Pipelinesの特定のジョブとステージに対してエージェントへの成果物の自動ダウンロードをスキップするように、ユーザーに指示することができます。 通常、この操作は、ジョブ内のタスクに成果物が必要ない場合や、必要な成果物をダウンロードするタスクにカスタム コードを実装する場合に行います。

ただしAzure Pipelines、デプロイの特定のジョブとステージに対してエージェントにダウンロードする成果物を選択できます。 通常、これを行って、そのジョブ内のタスクが成果物のすべてまたは一部を必要としない場合、または必要な成果物をダウンロードするためにタスクにカスタム コードを実装する場合に、デプロイ パイプラインの効率を向上させます。

ダウンロードする成果物の選択

成果物変数

Azure Pipelines、タスクとスクリプトでアクセスして使用できる定義済みの変数のセットを公開します。たとえば、デプロイ ジョブで PowerShell スクリプトを実行する場合などです。 リリース パイプラインにリンクされている成果物ソースが複数ある場合は、これらのそれぞれに関する情報にアクセスできます。 定義済みのすべての成果物変数の一覧については、「変数」を 参照してください

関連情報

ヘルプとサポート