クラシック リリース パイプラインの成果物ソース
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
クラシック リリース パイプラインを使用すると、さまざまなソースから成果物をデプロイできます。 グラフィカル インターフェイスを使用すると、さまざまなサービスからの成果物を統合して使用するパイプラインを設定できます。 さらに、さまざまなソースから複数の成果物をリンクし、ニーズに基づいて 1 つをプライマリ ソースとして指定できます。
成果物ソース
Azure Pipelines では、さまざまなリポジトリ、サービス、CI/CD プラットフォームがサポートされています。 リリースを作成するときに、成果物ソースのバージョンを指定できます。 既定では、最新バージョンのソース成果物がリリースで使用されます。 また、タグ、特定のバージョンを指定して特定のブランチから最新のビルドを使用することも、リリース作成時にユーザーがバージョンを指定できるようにすることもできます。
複数の成果物をリンクする場合は、どれをプライマリソースにするかを指定できます (既定)。 プライマリ 成果物ソースは、定義済みの 変数を設定するために使用され、名前付けのリリースにも使用できます。
[既定のバージョン] ドロップダウン オプションは、リンクされたビルド定義のソースの種類によって異なります。 オプション Specify at the time of release creation、 Specific version、 Latest は、すべてのリポジトリ タイプでサポートされています。 ただし、Latest from the build pipeline default branch with tags は XAML ビルド定義ではサポートされていません。
以下のセクションでは、さまざまなタイプの成果物ソースの操作方法について説明します。
Note
複数の成果物ソースを使用する場合、特定のステージをトリガーする成果物ソースのマッピングはサポートされていません。 この機能が必要な場合、Azure Pipelines では、リリース パイプラインを複数のリリースに分割することをお勧めします。
Azure Pipelines
クラシック リリース パイプラインを任意のパイプライン成果物にリンクできます。 さらに、複数の成果物をリンクし、複数のビルド ソースにデプロイ トリガーを設定できます。 この設定により、新しいビルドが利用可能になるたびにリリースが作成されます。 Azure Pipelines を成果物ソースとして使用する場合は、次の機能を使用できます。
| 機能 | 説明 |
|---|---|
| リリースの自動トリガー | 新しい成果物 (XAML ビルドを含む) が利用可能になったときに、新しいリリースを自動的に作成できます。 詳細については、「クラシック リリース トリガー」を参照してください。 |
| 成果物変数 | クラシック リリースで参照される成果物に対して、いくつかの Artifact variables (成果物の変数) がサポートされています。 |
| 作業項目とコミット | 作業項目をリンクして、リリースの詳細に表示されるようにします。 Git または TFVC を使用すると、コミットが表示されます。 |
| 成果物のダウンロード | 既定では、パイプライン 成果物は、パイプラインを実行しているエージェントにダウンロードされます。 また、必要に応じて、成果物のダウンロードをスキップするようにステージのステップを構成することもできます。 |
| デプロイ ステージ | パイプラインの概要には、成果物がデプロイされたすべてのデプロイ ステージが一覧表示されます。 |
Note
クラシック パイプラインでパイプライン成果物を発行するには、PublishPipelineArtifact タスクをパイプラインに追加する必要があります。 YAMLパイプラインでは、drop 成果物が暗黙的に発行されます。
ジョブの承認スコープを制限する
既定では、リリースは組織レベルのジョブ承認スコープで実行され、組織内のすべてのプロジェクトのリソースにアクセスできます。 これは、他のプロジェクトからパイプライン成果物をリンクする場合に便利です。 プロジェクトの成果物へのアクセスを制限するには、プロジェクト設定で、「リリース パイプラインのジョブ承認スコープを現在のプロジェクトに制限」を 有効にすることができます。
組織のジョブ承認スコープを設定するには:
Azure DevOps 組織にサインインします。
左下隅にある [組織の設定] を選択します。
*[設定][パイプライン]> を選択します。
リリース パイプラインの [ジョブ承認スコープを現在のプロジェクトに制限する] トグル をオンにして、スコープを現在のプロジェクトに制限します。 これは、セキュリティを強化するために推奨されます。
特定のプロジェクトのジョブ承認スコープを設定するには
Azure DevOps 組織にサインインしてから、プロジェクトに移動します。
左下隅にある [プロジェクト設定] を選択します。
*[設定][パイプライン]> を選択します。
リリース パイプラインの [ジョブ承認スコープを現在のプロジェクトに制限する] トグル をオンにして、スコープを現在のプロジェクトに制限します。 この設定は、パイプラインのセキュリティを強化するために推奨されます。
Note
スコープが組織レベルで設定されている場合、各プロジェクトで個別に変更することはできません。
Note
既定では、リリースはコレクション レベルのジョブ承認スコープで実行され、コレクション内のすべてのプロジェクトのリソースにアクセスできます。
Azure Repos、GitHub、TFVC
ビルド パイプラインを経由せずに、さまざまなソース管理から直接成果物を使用するシナリオがあります。 次に例を示します。
明示的なビルド パイプラインを必要としない PHP または JavaScript アプリケーションの開発。
さまざまなバージョン管理リポジトリのさまざまなステージの構成を管理し、これらの構成ファイルをデプロイ パイプラインの一部として直接使用します。
バージョン 管理リポジトリでのコードとしてのインフラストラクチャと構成の管理。
Azure Pipelines では、1 つのリリース パイプラインで複数の成果物ソースを構成できます。 これにより、アプリケーション バイナリを生成するビルド パイプラインと、構成ファイルを保存するバージョン管理リポジトリをリンクし、デプロイ中に両方の成果物のセットを一緒に使用できるようになります。
Azure Pipelinesでは、Azure Repos、Team Foundation バージョン管理 (TFVC)、GitHub リポジトリがサポートされています。 読み取りアクセス権があれば、プロジェクト コレクション内の任意の Git または TFVC リポジトリにリリース パイプラインをリンクできます。 同じコレクション内にバージョン管理成果物をデプロイするときに、追加のセットアップは必要ありません。
GitHub リポジトリをリンクしてブランチを選択する場合、成果物を保存した後で、成果物タイプの既定のプロパティを編集できます。 これは、安定したバージョンのブランチが変更され、継続的デリバリー リリースで新しい成果物バージョンに対して正しいブランチが使用されるようにする場合に便利です。 また、サブモジュール、Git-LFS 追跡対象ファイル、インクルード、浅いフェッチ深度など、チェックアウトの詳細を指定することもできます。
TFVC ブランチをリンクする場合は、リリースの作成時にデプロイする変更セットを指定できます。
Azure Repos、Git、TFVC を成果物ソースとして使用する場合、次の機能を使用できます。
| 機能 | 説明 |
|---|---|
| リリースの自動トリガー | 新しい成果物 (XAML ビルドを含む) が利用可能になったときに、新しいリリースを自動的に作成できます。 詳細については、「リリース トリガー」を参照してください。 |
| 成果物変数 | クラシック リリースで参照される成果物に対して、いくつかの Artifact variables (成果物の変数) がサポートされています。 |
| 作業項目とコミット | 作業項目をリンクして、リリースの詳細に表示されるようにします。 Git または TFVC を使用すると、コミットが表示されます。 |
| 成果物のダウンロード | 既定では、パイプライン 成果物は、パイプラインを実行しているエージェントにダウンロードされます。 また、必要に応じて、成果物のダウンロードをスキップするようにステージのステップを構成することもできます。 |
Note
既定では、リリースは組織レベルのジョブ承認スコープで実行され、組織内のすべてのプロジェクトのリソースにアクセスできます。 これは、他のプロジェクトからパイプライン成果物をリンクする場合に便利です。 プロジェクトの成果物へのアクセスを制限するには、プロジェクト設定で、「リリース パイプラインのジョブ承認スコープを現在のプロジェクトに制限」を 有効にすることができます。
Note
既定では、リリースはコレクション レベルのジョブ承認スコープで実行され、コレクション内のすべてのプロジェクトのリソースにアクセスできます。 これは、他のプロジェクトからパイプライン成果物をリンクする場合に便利です。 プロジェクトの成果物へのアクセスを制限するには、プロジェクト設定で、「リリース パイプラインのジョブ承認スコープを現在のプロジェクトに制限」を 有効にすることができます。
Azure Artifacts
成果物ソースとして Azure Artifacts を使用できるシナリオの一部を次に示します。
アプリケーション バイナリが Azure Artifacts に発行され、リリース パイプラインでパッケージを使用する必要があります。
デプロイ ワークフローの一部として、Azure Artifacts に格納されている追加のパッケージが必要である。
リリース パイプラインでAzure Artifactsを使用する場合は、パッケージの [フィード]、[パッケージ] と [既定のバージョン] を選択する必要があります。 パッケージの 最新バージョンを選択するか、特定のバージョンを使用するか、またはリリース作成時に指定するかを選択できます。 デプロイ中に、パッケージはパイプラインを実行しているエージェントにダウンロードされます。
Azure Artifacts を成果物ソースとして使用する場合は、次の機能を使用できます。
| 機能 | 説明 |
|---|---|
| リリースの自動トリガー | 新しい成果物 (XAML ビルドを含む) が利用可能になったときに、新しいリリースを自動的に作成できます。 詳細については、「リリース トリガー」を参照してください。 |
| 成果物変数 | クラシック リリースで参照される成果物に対して、いくつかの Artifact variables (成果物の変数) がサポートされています。 |
| 作業項目とコミット | 作業項目をリンクして、リリースの詳細に表示されるようにします。 Git または TFVC を使用すると、コミットが表示されます。 |
| 成果物のダウンロード | 既定では、パイプライン 成果物は、パイプラインを実行しているエージェントにダウンロードされます。 また、必要に応じて、成果物のダウンロードをスキップするようにステージのステップを構成することもできます。 |
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
Note
フィードには、最大 30 個の Maven スナップショットを格納できます。 この制限に達すると、Azure Artifacts は古いスナップショットを自動的に削除し、最新の 25 個のみを保持します。
Azure Container Repository と Docker Hub
コンテナー化されたアプリを展開するとき、コンテナー イメージはコンテナー レジストリに最初にプッシュされます。 その後、コンテナー イメージを Azure Web App for Containers または Docker/Kubernetes クラスターにデプロイできます。 これを行うには、まず、Azure または Docker Hub で認証するためのサービス接続を作成する必要があります。 詳細については、「Docker Registry サービス接続」を参照してください。
Azure Container Repository または Docker Hub を成果物ソースとして使用する場合は、次の機能を使用できます。
| 機能 | 説明 |
|---|---|
| リリースの自動トリガー | 新しい成果物 (XAML ビルドを含む) が利用可能になったときに、新しいリリースを自動的に作成できます。 詳細については、「リリース トリガー」を参照してください。 |
| 成果物変数 | クラシック リリースで参照される成果物に対して、いくつかの Artifact variables (成果物の変数) がサポートされています。 |
| 作業項目とコミット | 作業項目をリンクして、リリースの詳細に表示されるようにします。 Git または TFVC を使用すると、コミットが表示されます。 |
| 成果物のダウンロード | 既定では、パイプライン 成果物は、パイプラインを実行しているエージェントにダウンロードされます。 また、必要に応じて、成果物のダウンロードをスキップするようにステージのステップを構成することもできます。 |
Jenkins
Jenkins 成果物を使用するには、Jenkins サーバーで認証するためのサービス接続を作成する必要があります。 詳しくは、「Jenkins サービス接続」を参照してください。 さらに、Jenkins プロジェクトは、成果物を公開するためのビルド後アクションを使用して構成する必要があります。
Jenkins ビルドによって生成された成果物は、通常、アーカイブと共有のためにストレージ リポジトリに伝達されます。 Azure Blob Storage はそのようなリポジトリの1つであり、Azure Storage に発行する Jenkins プロジェクトをリリース パイプラインの成果物ソースとして使用できます。 Azure Pipelines は、これらの成果物を Azure からパイプラインを実行しているエージェントに自動的にダウンロードします。 このシナリオでは、エージェントと Jenkins サーバー間の接続は必要なく、Jenkins サーバーをインターネットに公開せずに Microsoft がホストするエージェントを使用できます。
Jenkins を成果物ソースとして使用する場合は、次の機能を使用できます。
| 機能 | 説明 |
|---|---|
| リリースの自動トリガー | 新しい成果物 (XAML ビルドを含む) が利用可能になったときに、新しいリリースを自動的に作成できます。 詳細については、「リリース トリガー」を参照してください。 |
| 成果物変数 | クラシック リリースで参照される成果物に対して、いくつかの Artifact variables (成果物の変数) がサポートされています。 |
| 作業項目とコミット | 作業項目をリンクして、リリースの詳細に表示されるようにします。 Git または TFVC を使用すると、コミットが表示されます。 |
| 成果物のダウンロード | 既定では、パイプライン 成果物は、パイプラインを実行しているエージェントにダウンロードされます。 また、必要に応じて、成果物のダウンロードをスキップするようにステージのステップを構成することもできます。 |
Note
Azure Pipelines は、Jenkins サーバーがプライベート エンタープライズ ネットワーク内にある場合、Jenkin サーバーに ping を実行できない場合があります。 このような場合は、Jenkins サーバーにアクセスできるオンプレミス エージェントを設定することで、Azure Pipelines を Jenkins と統合できます。 パイプラインにリンクするときに Jenkins プロジェクトの名前が表示されない場合がありますが、URL テキスト フィールドにプロジェクト名を手動で入力できます。
成果物のソース名
各成果物のダウンロードの一意性を確保するために、リリース パイプラインにリンクされているすべての成果物ソースには、ソース エイリアスと呼ばれる特定のダウンロード場所が自動的に割り当てられます。 この場所には、変数: $(System.DefaultWorkingDirectory)\[source alias] を使用してアクセスできます。
ソース別名を使用すると、エージェントで定義されたダウンロードの場所は変更されないため、リンクされた成果物ソースの名前を変更してもタスク プロパティを編集する必要がなくなります。
既定では、ソース エイリアスは成果物ソースの名前にアンダースコアを付けたものです (例: _mslearn-tailspin-spacegame-web)。 ソース エイリアスは、成果物ソース タイプに応じて、ビルド パイプラインの名前、ジョブ名、プロジェクト名、またはリポジトリ名に対応できます。 リリース パイプラインの [成果物] タブからソース エイリアスを編集できます。
成果物のダウンロード
ステージへのデプロイが完了すると、各ソースからバージョン管理された成果物がパイプライン エージェントにダウンロードされ、そのステージ内のタスクがそれらにアクセスできるようになります。 これらのダウンロードされた成果物は、リリースが完了しても削除されません。 ただし、新しいリリースが開始されると、以前の成果物が削除され、新しい成果物に置き換えられます。
リリースが開始されると、リリース パイプラインごとにエージェント上に一意のフォルダーが作成され、成果物はこのフォルダーにダウンロードされます: $(System.DefaultWorkingDirectory)。
Azure Pipelines では、同じリリースが再度デプロイされた場合に、変更されていない成果物が再ダウンロードされるのを防ぐための最適化は実行されません。 さらに、新しいリリースが開始されると、以前にダウンロードしたコンテンツが削除されるため、Azure Pipelines はエージェントへの増分ダウンロードを実行できません。
成果物の自動ダウンロードをスキップするには、[リリース パイプライン]>[タスク]>[エージェント ジョブ]>[成果物のダウンロード] に移動し、すべての成果物をオフにするか、スキップする特定の成果物を指定します。
アーティファクトの自動ダウンロードをスキップするには、[リリース パイプライン]>[タスク]>[エージェント ジョブ]>[追加オプション] に移動し、成果物の [ダウンロードをスキップ] チェック ボックスをオンにします。
