リリース パイプラインと成果物ソース
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Azure Pipelines を使用すると、さまざまな成果物ソースから成果物をデプロイし、ワークフローをさまざまな種類の成果物リポジトリと統合できます。 リリースは、複数の成果物ソースにリンクできます。ここで、その 1 つがプライマリ ソースとして指定されます。
成果物ソース
Azure Pipelines では、さまざまなリポジトリ、ソース管理ツール、継続的インテグレーション システムがサポートされています。
リリースを作成するときに、成果物ソースのバージョンを指定できます。 既定では、最新バージョンのソース成果物がリリースで使用されます。 また、タグ、特定のバージョンを指定して特定のブランチから最新のビルドを使用することも、リリース作成時にユーザーがバージョンを指定できるようにすることもできます。
複数の成果物をリンクする場合は、どれがプライマリ ソース (既定値) になるかを指定できます。 プライマリ成果物ソースは、定義済みの変数の数を設定するために使用されます。 これは、名前付けリリースでも使用できます。
注意
Default version ドロップダウン項目は、リンクされたビルド定義のソースの種類によって異なります。
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
- バージョン コントロール
- Jenkins
- Azure Container Registry、Docker、Kubernetes
- Azure Artifacts
- TFS サーバー
- TeamCity
成果物ソース - Azure Pipelines
リリース パイプラインは、任意の Azure Pipelines ビルドにリンクできます。 複数のビルド パイプラインをリンクして、既定値を指定し、複数のビルド ソースにデプロイ トリガーを設定することもできます。 ビルドのいずれかが完了すると、リリースの作成がトリガーされます。
Azure Pipelines を成果物ソースとして使用する場合は、次の機能を使用できます。
| 機能 | 説明 |
|---|---|
| リリースの自動トリガー | 新しいビルド成果物 (XAML ビルドを含む) が使用可能になると、新しいリリースを自動的に作成できます。 詳細については、「リリース トリガー」を参照してください。 |
| 成果物変数 | Azure Pipelines ソースでは、多数の成果物変数がサポートされています。 |
| 作業項目とコミット | Azure Pipelines の作業項目をリンクすると、リリースの詳細に表示されます。 Git または TFVC ソース管理を使用すると、コミットが表示されます。 |
| 成果物のダウンロード | 既定では、ビルド成果物はパイプラインを実行しているエージェントにダウンロードされます。 ステージのステップを構成して、成果物のダウンロードをスキップすることもできます。 |
| デプロイ ステージ | ビルドの概要には、成果物がデプロイされたすべてのデプロイ ステージが一覧表示されます。 |
注意
ビルド パイプラインに成果物の発行タスクを含める必要があります。 YAML ビルド パイプラインの場合、ドロップという名前の成果物が暗黙的に発行されます。
既定では、リリースはコレクション レベルのジョブの承認スコープで実行されます。 つまり、リリースは、組織内のすべてのプロジェクト (または Azure DevOps Server のコレクション) のリソースにアクセスできます。 これは、他のプロジェクトからビルド成果物をリンクする場合に便利です。 プロジェクト設定で[ジョブの承認スコープをリリース パイプラインの現在のプロジェクトに制限する] を有効にして、プロジェクトの成果物へのアクセスを制限できます。
組織のジョブの承認スコープを設定するには:
- [組織の設定] に移動します。
- [パイプライン] で[設定] を選択します。
- [ジョブの承認スコープをリリース パイプラインの現在のプロジェクトに制限する] トグルをオンにして、スコープを現在のプロジェクトに制限します。 これは、適切なセキュリティ対策に推奨される設定です。
特定のプロジェクトのジョブの承認のスコープを設定するには:
- [プロジェクトの設定] に移動します。
- [パイプライン] で[設定] を選択します。
- [ジョブの承認スコープをリリース パイプラインの現在のプロジェクトに制限する] トグルをオンにして、スコープを現在のプロジェクトに制限します。 これは、パイプラインのセキュリティを強化するため、推奨される設定です。
注意
スコープが組織レベルでプロジェクトに設定されている場合、各プロジェクトのスコープを変更することはできません。
リリース内のすべてのジョブは、ジョブの承認スコープがコレクションに設定された状態で実行されます。 つまり、これらのジョブは、プロジェクト コレクション内のすべてのプロジェクトのリソースにアクセスできます。
成果物ソース - バージョン管理
ビルド パイプラインを通過せずに、さまざまなソース管理の成果物を直接使用するシナリオがいくつかあります。 次に例を示します。
明示的なビルド パイプラインを必要としない PHP または JavaScript アプリケーションを開発する。
さまざまなステージの構成を異なるバージョン管理リポジトリで管理し、これらの構成ファイルをデプロイ パイプラインの一部としてバージョン管理から直接使用する。
インフラストラクチャと構成をコードとして管理し、これらのファイルをバージョン管理リポジトリで管理する。
1 つのリリース パイプラインで複数の成果物ソースを構成できるため、アプリケーションのバイナリを生成するビルド パイプラインと、構成ファイルを同じパイプラインに格納するバージョン 管理リポジトリの両方をリンクし、デプロイ中に 2 つの成果物セットを一緒に使用できます。
Azure Pipelines では、Team Foundation バージョン管理 (TFVC) リポジトリ、Git リポジトリ、GitHub リポジトリがサポートされています。
リリース パイプラインは、コレクション内の任意のプロジェクト内の任意の Git または TFVC リポジトリにリンクできます (これらのリポジトリへの読み取りアクセス権が必要です)。 同じコレクション内にバージョン管理成果物をデプロイするときに、追加のセットアップは必要ありません。
GitHub リポジトリをリンクしてブランチを選択すると、成果物の保存後に成果物の種類の既定のプロパティを編集できます。 これは、成果物の安定バージョンのブランチが変更され、継続的デリバリー リリースでこのブランチを使用して新しいバージョンの成果物を取得する必要があるシナリオで特に便利です。 チェックアウト サブモジュールと LFS 追跡ファイルの有無、浅いフェッチの深さなど、チェックアウトの詳細を指定することもできます。
TFVC ブランチをリンクするときに、リリースの作成時にデプロイする変更セットを指定できます。
TFVC、Git、GitHub を成果物ソースとして使用する場合は、次の機能を使用できます。
| 機能 | 説明 |
|---|---|
| リリースの自動トリガー | 新しいビルド成果物 (XAML ビルドを含む) が使用可能になると、新しいリリースを自動的に作成できます。 詳細については、「リリース トリガー」を参照してください。 |
| 成果物変数 | Azure Pipelines ソースでは、多数の成果物変数がサポートされています。 |
| 作業項目とコミット | Azure Pipelines の作業項目をリンクすると、リリースの詳細に表示されます。 Git または TFVC ソース管理を使用すると、コミットが表示されます。 |
| 成果物のダウンロード | 既定では、ビルド成果物はパイプラインを実行しているエージェントにダウンロードされます。 ステージのステップを構成して、成果物のダウンロードをスキップすることもできます。 |
既定では、リリースはコレクション レベルのジョブの承認スコープで実行されます。 つまり、リリースは、組織内のすべてのプロジェクト (または Azure DevOps Server のコレクション) のリソースにアクセスできます。 これは、他のプロジェクトからビルド成果物をリンクする場合に便利です。 プロジェクト設定で[ジョブの承認スコープをリリース パイプラインの現在のプロジェクトに制限する] を有効にして、プロジェクトの成果物へのアクセスを制限できます。
成果物ソース - Jenkins
Jenkins 成果物を使用するには、Jenkins サーバーで認証するためのサービス接続を作成する必要があります。 詳細については、「サービス接続の管理」と「Jenkins サービス接続」を参照してください。 成果物を発行するには、ビルド後アクションを使用して Jenkins プロジェクトを構成する必要があります。
Jenkins を成果物ソースとして使用する場合は、次の機能を使用できます。
| 機能 | 説明 |
|---|---|
| リリースの自動トリガー | 新しいビルド成果物 (XAML ビルドを含む) が使用可能になると、新しいリリースを自動的に作成できます。 詳細については、「リリース トリガー」を参照してください。 |
| 成果物変数 | Azure Pipelines ソースでは、多数の成果物変数がサポートされています。 |
| 作業項目とコミット | Azure Pipelines の作業項目をリンクすると、リリースの詳細に表示されます。 Git または TFVC ソース管理を使用すると、コミットが表示されます。 |
| 成果物のダウンロード | 既定では、ビルド成果物はパイプラインを実行しているエージェントにダウンロードされます。 ステージのステップを構成して、成果物のダウンロードをスキップすることもできます。 |
Jenkins ビルドによって生成された成果物は、通常、アーカイブと共有のためにストレージ リポジトリに伝達されます。 Azure BLOB ストレージは、サポートされているリポジトリの 1 つであり、リリース パイプラインで成果物ソースとして Azure Storage に発行する Jenkins プロジェクトを使用できます。 Azure Pipelines では、Azure からパイプラインを実行しているエージェントに成果物を自動的にダウンロードします。 このシナリオでは、エージェントと Jenkins サーバー間の接続は必要ありません。 Microsoft ホステッド エージェントは、サーバーをインターネットに公開せずに使用できます。
注意
たとえば、エンタープライズ ネットワーク内にある場合、Azure Pipelines を Jenkins サーバーに接続できない場合があります。 その場合は、Jenkins サーバーにアクセスできるオンプレミス エージェントを設定すると、Azure Pipelines と Jenkins を統合できます。 ビルドへのリンク時に Jenkins プロジェクトの名前を表示することはできませんが、URL テキスト フィールドに名前を入力できます。
成果物ソース - コンテナー
コンテナー化されたアプリを展開するとき、コンテナー イメージはコンテナー レジストリに最初にプッシュされます。 その後、コンテナー イメージを Azure Web App for Containers または Docker/Kubernetes クラスターにデプロイできます。 Azure で認証するには、サービス接続を作成する必要があります。 詳細については、「サービス接続の管理」を参照してください。
Azure Container を成果物ソースとして使用する場合は、次の機能を使用できます。
| 機能 | 説明 |
|---|---|
| リリースの自動トリガー | 新しいビルド成果物 (XAML ビルドを含む) が使用可能になると、新しいリリースを自動的に作成できます。 詳細については、「リリース トリガー」を参照してください。 |
| 成果物変数 | Azure Pipelines ソースでは、多数の成果物変数がサポートされています。 |
| 作業項目とコミット | Azure Pipelines の作業項目をリンクすると、リリースの詳細に表示されます。 Git または TFVC ソース管理を使用すると、コミットが表示されます。 |
| 成果物のダウンロード | 既定では、ビルド成果物はパイプラインを実行しているエージェントにダウンロードされます。 ステージのステップを構成して、成果物のダウンロードをスキップすることもできます。 |
注意
複数の成果物ソースを使用する場合、特定のステージをトリガーする成果物ソースのマッピングはサポートされていません。 成果物ソースにプッシュがある場合は、いつでもリリースが作成されます。 これを行う場合は、Azure Pipelines でリリース パイプラインを複数のリリースに分割することをお勧めします。
成果物ソース - Azure Artifacts
成果物ソースとして Azure Artifacts を使用できるシナリオの一部を次に示します。
- アプリケーション バイナリが Azure Artifacts に発行され、リリース パイプラインでパッケージを使用する。
- デプロイ ワークフローの一部として、Azure Artifacts に格納されている追加のパッケージが必要である。
リリース パイプラインで Azure Artifacts を使用するには、フィード、パッケージ、パッケージの既定のバージョンを選択する必要があります。 パッケージの最新バージョンの選択、特定のバージョンの使用、リリース作成時のバージョンの選択を選択できます。 デプロイ中に、パイプラインを実行しているエージェントにパッケージがダウンロードまたは抽出されます。
Azure Artifacts を成果物ソースとして使用する場合は、次の機能を使用できます。
| 機能 | 説明 |
|---|---|
| リリースの自動トリガー | 新しいビルド成果物 (XAML ビルドを含む) が使用可能になると、新しいリリースを自動的に作成できます。 詳細については、「リリース トリガー」を参照してください。 |
| 成果物変数 | Azure Pipelines ソースでは、多数の成果物変数がサポートされています。 |
| 作業項目とコミット | Azure Pipelines の作業項目をリンクすると、リリースの詳細に表示されます。 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
注意
フィードには、最大 30 個の Maven スナップショットを格納できます。 Azure Artifacts では、上限に達すると、スナップショットを 25 まで自動的に削除します。 このプロセスは、30 以上のスナップショットがフィードに公開されるたびに自動的にトリガーされます。
成果物ソース - TFS サーバー
Azure Pipelines を使用して、オンプレミスの自動化エージェントを設定すると、サーバーをインターネット上で検出可能にすることなく、TFS サーバーから成果物をデプロイできます。 成果物はオンプレミス エージェントにダウンロードされ、エンタープライズ ネットワークから離れることなく、指定されたターゲット サーバーにデプロイされます。 これは、お客様が Azure Pipelines リリースを利用しながら、オンプレミス インフラストラクチャへの投資を活用するのに最適です。
TFS サーバーを成果物ソースとして使用するには、Visual Studio Marketplace から Azure Pipelines 拡張機能用の TFS 成果物をインストールし、Azure Pipelines で認証するためのサービス接続を作成する必要があります。 認証が完了したら、TFS ビルド パイプラインをリリース パイプラインにリンクし、[種類] ドロップダウン メニューから [外部 TFS ビルド] を選択できます。
TFS サーバーを成果物ソースとして使用する場合は、次の機能を使用できます。
| 機能 | 説明 |
|---|---|
| リリースの自動トリガー | 新しいビルド成果物 (XAML ビルドを含む) が使用可能になると、新しいリリースを自動的に作成できます。 詳細については、「リリース トリガー」を参照してください。 |
| 成果物変数 | Azure Pipelines ソースでは、多数の成果物変数がサポートされています。 |
| 作業項目とコミット | Azure Pipelines の作業項目をリンクすると、リリースの詳細に表示されます。 Git または TFVC ソース管理を使用すると、コミットが表示されます。 |
| 成果物のダウンロード | 既定では、ビルド成果物はパイプラインを実行しているエージェントにダウンロードされます。 ステージのステップを構成して、成果物のダウンロードをスキップすることもできます。 |
Azure Pipelines は、エンタープライズ ネットワーク内にある場合に備えて、オンプレミスの TFS サーバーに接続できない場合があります。 その場合は、TFS サーバーにアクセスできるオンプレミス エージェントを設定すると、Azure Pipelines と TFS を統合できます。 ビルドへのリンク時に TFS プロジェクトまたはビルド パイプラインの名前を表示することはできませんが、URL テキスト フィールドにこれらの変数を含めることができます。 さらに、リリースを作成すると、Azure Pipelines で TFS サーバーに対してビルド番号のクエリを実行できない場合があります。 代わりに、目的のビルドの "ビルド ID" (ビルド番号ではなく) を適切なフィールドに入力するか、[最新のビルド] を選択します。
成果物ソース - TeamCity
成果物ソースとして TeamCity を使用するには、まず Visual Studio Marketplace から Azure Pipelines 拡張機能の TeamCity 成果物をインストールする必要があります。
完了したら、TeamCity サーバーで認証するためのサービス接続を作成します。 その後、ビルド成果物をリリース パイプラインにリンクできます。 成果物を発行するアクションを使用して TeamCity ビルド構成を設定する必要があります。
TeamCity を成果物ソースとして使用する場合は、次の機能を使用できます。
| 機能 | 説明 |
|---|---|
| リリースの自動トリガー | 新しいビルド成果物 (XAML ビルドを含む) が使用可能になると、新しいリリースを自動的に作成できます。 詳細については、「リリース トリガー」を参照してください。 |
| 成果物変数 | Azure Pipelines ソースでは、多数の成果物変数がサポートされています。 |
| 作業項目とコミット | Azure Pipelines の作業項目をリンクすると、リリースの詳細に表示されます。 Git または TFVC ソース管理を使用すると、コミットが表示されます。 |
| 成果物のダウンロード | 既定では、ビルド成果物はパイプラインを実行しているエージェントにダウンロードされます。 ステージのステップを構成して、成果物のダウンロードをスキップすることもできます。 |
たとえば、エンタープライズ ネットワーク内にある場合、Azure Pipelines を TeamCity サーバーに接続できない場合があります。 その場合は、TeamCity サーバーにアクセスできるオンプレミス エージェントを設定すると、Azure Pipelines と TeamCity を統合できます。 ビルドへのリンク時に TeamCity プロジェクトの名前を表示することはできませんが、URL テキスト フィールドに入力できます。
成果物のソース名
すべての成果物のダウンロードの一意性を確保するために、リリース パイプラインにリンクされている各成果物ソースには、"ソース エイリアス" と呼ばれる特定のダウンロード場所が自動的に提供されます。 この場所には、$(System.DefaultWorkingDirectory)\[source alias] 変数を使用してアクセスできます。
ソース エイリアスを使用すると、リンクされた成果物ソースの名前を変更しても、エージェントで定義されているダウンロード場所が変更されないため、タスク のプロパティを編集する必要はありません。
既定では、ソース エイリアスは、成果物ソースの名前の前にアンダースコアが付きます。 成果物ソースの種類に応じて、ビルド パイプラインの名前、ジョブ名、プロジェクト名、またはリポジトリ名になります。 ソース エイリアスは、リリース パイプラインの [成果物] タブから編集できます。
成果物のダウンロード
ステージへのデプロイが完了すると、各ソースのバージョン管理された成果物がパイプライン エージェントにダウンロードされ、そのステージ内で実行されているタスクがそれらの成果物にアクセスできるようになります。 リリースが完了しても、ダウンロードした成果物は削除されません。 ただし、次のリリースを開始すると、ダウンロードした成果物が削除され、新しい成果物セットに置き換えられます。
リリースが開始されると、エージェント内の新しい一意のフォルダーがリリース パイプラインごとに作成され、成果物は $(System.DefaultWorkingDirectory) フォルダーにダウンロードされます。
Azure Pipelines では、同じリリースが再びデプロイされた場合、変更されていない成果物のダウンロードを回避するために最適化を実行しません。 さらに、以前にダウンロードした内容は新しいリリースを開始すると常に削除されるため、Azure Pipelines ではエージェントへの増分ダウンロードを実行できません。
ただし、必要に応じて、特定のジョブまたはステージの自動ダウンロードをスキップするようにパイプラインを設定できます。
関連記事
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示