クラシック リリース パイプラインの成果物ソース

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 ビルド定義ではサポートされていません。

以下のセクションでは、さまざまなタイプの成果物ソースの操作方法について説明します。

Azure Pipelines

クラシック リリース パイプラインを任意のパイプライン成果物にリンクできます。 さらに、複数の成果物をリンクし、複数のビルド ソースにデプロイ トリガーを設定できます。 この設定により、新しいビルドが利用可能になるたびにリリースが作成されます。 Azure Pipelines を成果物ソースとして使用する場合は、次の機能を使用できます。

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 を成果物ソースとして使用する場合、次の機能を使用できます。

Azure Artifacts

成果物ソースとして Azure Artifacts を使用できるシナリオの一部を次に示します。

• アプリケーション バイナリが Azure Artifacts に発行され、リリース パイプラインでパッケージを使用する必要があります。

• デプロイ ワークフローの一部として、Azure Artifacts に格納されている追加のパッケージが必要である。

リリース パイプラインでAzure Artifactsを使用する場合は、パッケージの [フィード]、[パッケージ] と [既定のバージョン] を選択する必要があります。 パッケージの 最新バージョンを選択するか、特定のバージョンを使用するか、またはリリース作成時に指定するかを選択できます。 デプロイ中に、パッケージはパイプラインを実行しているエージェントにダウンロードされます。

Azure Artifacts を成果物ソースとして使用する場合は、次の機能を使用できます。

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

Azure Container Repository と Docker Hub

コンテナー化されたアプリを展開するとき、コンテナー イメージはコンテナー レジストリに最初にプッシュされます。 その後、コンテナー イメージを Azure Web App for Containers または Docker/Kubernetes クラスターにデプロイできます。 これを行うには、まず、Azure または Docker Hub で認証するためのサービス接続を作成する必要があります。 詳細については、「Docker Registry サービス接続」を参照してください。

Azure Container Repository または Docker Hub を成果物ソースとして使用する場合は、次の機能を使用できます。

Jenkins

Jenkins 成果物を使用するには、Jenkins サーバーで認証するためのサービス接続を作成する必要があります。 詳しくは、「Jenkins サービス接続」を参照してください。 さらに、Jenkins プロジェクトは、成果物を公開するためのビルド後アクションを使用して構成する必要があります。

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

Jenkins を成果物ソースとして使用する場合は、次の機能を使用できます。

成果物のソース名

各成果物のダウンロードの一意性を確保するために、リリース パイプラインにリンクされているすべての成果物ソースには、ソース エイリアスと呼ばれる特定のダウンロード場所が自動的に割り当てられます。 この場所には、変数: $(System.DefaultWorkingDirectory)\[source alias] を使用してアクセスできます。

ソース別名を使用すると、エージェントで定義されたダウンロードの場所は変更されないため、リンクされた成果物ソースの名前を変更してもタスク プロパティを編集する必要がなくなります。

既定では、ソース エイリアスは成果物ソースの名前にアンダースコアを付けたものです (例: _mslearn-tailspin-spacegame-web)。 ソース エイリアスは、成果物ソース タイプに応じて、ビルド パイプラインの名前、ジョブ名、プロジェクト名、またはリポジトリ名に対応できます。 リリース パイプラインの [成果物] タブからソース エイリアスを編集できます。

成果物のダウンロード

ステージへのデプロイが完了すると、各ソースからバージョン管理された成果物がパイプライン エージェントにダウンロードされ、そのステージ内のタスクがそれらにアクセスできるようになります。 これらのダウンロードされた成果物は、リリースが完了しても削除されません。 ただし、新しいリリースが開始されると、以前の成果物が削除され、新しい成果物に置き換えられます。

リリースが開始されると、リリース パイプラインごとにエージェント上に一意のフォルダーが作成され、成果物はこのフォルダーにダウンロードされます: $(System.DefaultWorkingDirectory)。

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

関連記事

• 複数のブランチからのデプロイ
• パイプライン成果物の発行とダウンロード
• 成果物変数