クラシック リリース変数と成果物変数

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

注意

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

クラシック リリース変数と成果物変数は、パイプライン全体でデータを交換および転送するための便利な方法です。 各変数は文字列として格納され、その値はパイプラインの実行間で変更される可能性があります。

変数は、テンプレートの 解析時 にのみ使用できるランタイム パラメーターとは異なります。

注意

これは、クラシック リリース変数と成果物変数に関するリファレンス記事です。 YAML パイプラインの変数を理解するには、「ユーザー定義変数 」を参照してください

DevOps CI/CD プロセスの各ステージにアプリケーションをデプロイするためのタスクを作成する場合、変数は次の場合に役立ちます。

  • より汎用的なデプロイ パイプラインを 1 回定義し、各ステージに合わせて簡単にカスタマイズします。 たとえば、変数を使用して Web デプロイの接続文字列を表し、この変数の値をステージ間で変更できます。 これらはカスタム 変数 です

  • デプロイ パイプラインが実行されている特定のリリース、ステージ、成果物、またはエージェントのコンテキストに関する情報を使用します。 たとえば、スクリプトをダウンロードするためにビルドの場所にアクセスしたり、エージェントの作業ディレクトリにアクセスして一時ファイルを作成したりする必要がある場合があります。 これらは既定 の変数 です

ヒント

リリースのすべての変数 の現在の 値を表示し、既定の変数を使用してデバッグ モード でリリースを実行できます

既定の変数

実行コンテキストに関する情報は、既定の変数を使用してタスクを実行するために使用できます。 タスクとスクリプトでは、これらの変数を使用して、実行されているシステム、リリース、ステージ、またはエージェントに関する情報を検索できます。 System.Debug を除き、これらの変数は読み取り専用であり、その値はシステムによって自動的に設定されます。 次の表では、最も重要な変数のいくつかについて説明します。 完全な一覧を表示するには、「 すべての変数の現在の値を表示する」を参照してください。

既定の変数-System

変数名 説明
Teamfound Ationserveruri TFS または Azure Pipelines 内のサービス接続の URL。 これをスクリプトまたはタスクから使用して Azure Pipelines REST Api を呼び出すことができます。

例: https://fabrikam.vsrm.visualstudio.com/
Teamfound Ationcollectionuri Team Foundation コレクションまたは Azure Pipelines の URL。 これをスクリプトまたはタスクから使用して、ビルドやバージョン管理などの他のサービスで REST Api を呼び出すことができます。

例: https://dev.azure.com/fabrikam/
CollectionId このビルドまたはリリースが属するコレクションの ID。 TFS 2015 では使用できません。

例: 6c6f3423-1c84-4625-995a-f7f143a1e43d
DefinitionId 現在のリリースが所属するリリースパイプラインの ID。 TFS 2015 では使用できません。

例: 1
System.TeamProject このビルドまたはリリースが属しているプロジェクトの名前。

例: Fabrikam
TeamProjectId このビルドまたはリリースが属しているプロジェクトの ID。 TFS 2015 では使用できません。

例: 79f5c12e-3337-4151-be41-a268d2c73344
システムの ArtifactsDirectory リリースのデプロイ中に成果物がダウンロードされるディレクトリ。 成果物をエージェントにダウンロードする必要がある場合、ディレクトリはデプロイの前にクリアされます。 Agent.ReleaseDirectory および System.DefaultWorkingDirectory と同じです。

例: C:\agent\_work\r1\a
System.DefaultWorkingDirectory リリースのデプロイ中に成果物がダウンロードされるディレクトリ。 成果物をエージェントにダウンロードする必要がある場合、ディレクトリはデプロイの前にクリアされます。 Agent.ReleaseDirectory および System.ArtifactsDirectory と同じです。

例: C:\agent\_work\r1\a
System.WorkFolder このエージェントの作業ディレクトリ。ビルドまたはリリースごとにサブフォルダーが作成されます。 Agent.RootDirectory および Agent.WorkFolder と同じです。

例: C:\agent\_work
System.Debug これは、ユーザーが設定できる唯一 システム変数です。 エラー検出を支援するために デバッグ モードでリリースを実行 するには、これを true に設定します。

例: true

既定の変数 - リリース

変数名 説明
Release.AttemptNumber このステージでこのリリースがデプロイされる回数。 TFS 2015 では使用できません。

例: 1
Release.DefinitionEnvironmentId 対応するリリース パイプライン内のステージの ID。 TFS 2015 では使用できません。

例: 1
DefinitionId 現在のリリースが所属するリリースパイプラインの ID。 TFS 2015 では使用できません。

例: 1
Release.DefinitionName 現在のリリースが所属するリリース パイプラインの名前。

例: fabrikam-cd
リリース. RequestedFor 現在進行中の配置をトリガーした (開始した) id の表示名。 TFS 2015 では使用できません。

例: Mateo Escobedo
リリース. RequestedForEmail 現在進行中のデプロイをトリガーした (開始した) id の電子メールアドレス。 TFS 2015 では使用できません。

例: mateo@fabrikam.com
リリース. RequestedForId 現在進行中のデプロイをトリガーした (開始した) id の ID。 TFS 2015 では使用できません。

例: 2f435d07-769f-4e46-849d-10d1ab9ba6ab
DeploymentID のリリース デプロイの ID。 ジョブごとに一意です。

例: 254
DeployPhaseID デプロイが実行されているフェーズの ID。

例: 127
EnvironmentId 配置が現在進行中であるリリースのステージインスタンスの ID。

例: 276
リリース. 環境名 デプロイが現在進行中のステージの名前。

例: Dev
Release.EnvironmentUri デプロイが現在進行中のリリース内のステージ インスタンスの URI。

例: vstfs://ReleaseManagement/Environment/276
Release.Environments。{stage-name}.status ステージの展開状態。

例: InProgress
Release.PrimaryArtifactSourceAlias プライマリ成果物ソースのエイリアス

例: fabrikam\_web
Release.Reason デプロイの理由。 サポートされる値は次のとおりです。
ContinuousIntegration - ビルドが完了した後、継続的デプロイでリリースが開始されました。
Manual - リリースが手動で開始されました。
None - デプロイの理由が指定されていません。
Scheduled - スケジュールからリリースが開始されました。
Release.ReleaseDescription リリース時に指定されたテキストの説明。

例: Critical security patch
Release.ReleaseId 現在のリリース レコードの識別子。

例: 118
Release.ReleaseName 現在のリリースの名前。

例: Release-47
Release.ReleaseUri 現在のリリースの URI。

例: vstfs://ReleaseManagement/Release/118
ReleaseWebURL このリリースの URL。

例: https://dev.azure.com/fabrikam/f3325c6c/_release?releaseId=392&_a=release-summary
のリリース。 requested リリースをトリガーした id の表示名。

例: Mateo Escobedo
リリース. RequestedForEmail リリースをトリガーした id の電子メールアドレス。

例: mateo@fabrikam.com
リリース. RequestedForId リリースをトリガーした id の ID。

例: 2f435d07-769f-4e46-849d-10d1ab9ba6ab
SkipArtifactsDownload エージェントへの成果物のダウンロードをスキップするかどうかを指定するブール値です。

例: FALSE
TriggeringArtifact ティファクト. Alias リリースをトリガーした成果物のエイリアス。 リリースがスケジュールまたは手動でトリガーされた場合、これは空になります。

例: fabrikam\_app

既定の変数-リリースステージ

変数名 説明
環境を解放します。{ステージ名}。オンライン 指定されたステージ内でのこのリリースの配置の状態。 TFS 2015 では使用できません。

例: NotStarted

既定の変数-エージェント

変数名 説明
Agent.Name エージェントプールに登録されているエージェントの名前。 これは、コンピューター名とは異なる可能性があります。

例: fabrikam-agent
Agent.MachineName エージェントが構成されているコンピューターの名前。

例: fabrikam-agent
Agent.Version エージェント ソフトウェアのバージョン。

例: 2.109.1
Agent.JobName 実行されているジョブの名前 (リリースやビルドなど)。

例: Release
Agent.HomeDirectory エージェントがインストールされているフォルダー。 このフォルダーには、エージェントのコードとリソースが含まれている。

例: C:\agent
Agent.ReleaseDirectory リリースのデプロイ中に成果物がダウンロードされるディレクトリ。 成果物をエージェントにダウンロードする必要がある場合、ディレクトリはデプロイの前にクリアされます。 System.ArtifactsDirectory および System.DefaultWorkingDirectory と同じです。

例: C:\agent\_work\r1\a
Agent.RootDirectory このエージェントの作業ディレクトリ。ビルドまたはリリースごとにサブフォルダーが作成されます。 Agent.WorkFolder および System.WorkFolder と同じです。

例: C:\agent\_work
Agent.WorkFolder このエージェントの作業ディレクトリ。ビルドまたはリリースごとにサブフォルダーが作成されます。 Agent.RootDirectory および System.WorkFolder と同じです。

例: C:\agent\_work
エージェント。 DeploymentGroupId エージェントが登録されている配置グループの ID。 これは、配置グループジョブでのみ使用できます。 TFS 2018 Update 1 では使用できません。

例: 1

既定の変数-一般成果物

リリースで参照される成果物ごとに、次の成果物変数を使用できます。 すべての変数が成果物の種類ごとに意味を持つわけではありません。 次の表に、既定のアーティファクト変数と、アイテムの種類に応じた値の例を示します。 例が空の場合は、その成果物の種類に対して変数が設定されていないことを意味します。

プレースホルダーは、 {alias} 成果物のエイリアス に対して指定した値で置き換えます。または、リリースパイプライン用に生成された既定値に置き換えてください。

変数名 説明
成果物を解放します。{alias}。DefinitionId ビルドパイプラインまたはリポジトリの識別子。

Azure Pipelines 例: 1
GitHub の例: fabrikam/asp
成果物を解放します。{alias}。DefinitionName ビルドパイプラインまたはリポジトリの名前。

Azure Pipelines 例: fabrikam-ci
TFVC の例: $/fabrikam
Git の例: fabrikam
GitHub の例: fabrikam/asp (main)
Release.Artifacts。{エイリアス}。BuildNumber ビルド番号またはコミット識別子。

Azure Pipelines例: 20170112.1
Jenkins/TeamCity の例: 20170112.1
TFVC の例: Changeset 3
Git の例: 38629c964
GitHub の例: 38629c964
Release.Artifacts。{エイリアス}。BuildId ビルド識別子。

Azure Pipelines例: 130
Jenkins/TeamCity の例: 130
GitHub の例: 38629c964d21fe405ef830b7d0220966b82c9e11
Release.Artifacts。{エイリアス}。BuildURI ビルドの URL。

Azure Pipelines例: vstfs://build-release/Build/130
GitHub の例: https://github.com/fabrikam/asp
Release.Artifacts。{エイリアス}。SourceBranch ソースのビルド元のブランチの完全なパスと名前。

Azure Pipelines例: refs/heads/main
Release.Artifacts。{エイリアス}。SourceBranchName ソースが作成されたブランチの名前のみ。

Azure Pipelines 例: main
成果物を解放します。{alias}。SourceVersion ビルドされたコミット。

Azure Pipelines 例: bc0044458ba1d9298cdc649cb5dcf013180706f7
成果物を解放します。{alias}。リポジトリ. プロバイダー ソースが作成されたリポジトリの種類。

Azure Pipelines 例: Git
成果物を解放します。{alias}。RequestedForID ビルドをトリガーしたアカウントの識別子。

Azure Pipelines 例: 2f435d07-769f-4e46-849d-10d1ab9ba6ab
成果物を解放します。{alias}。Event.deployment.requestedfor.displayname ビルドを要求したアカウントの名前。

Azure Pipelines 例: Mateo Escobedo
成果物を解放します。{alias}。各種 ビルドなどの成果物ソースの種類。

Azure Pipelines 例: Build
Jenkins の例: Jenkins
TeamCity の例: TeamCity
TFVC の例: TFVC
Git の例: Git
GitHub の例: GitHub
Release.Artifacts。{エイリアス}。PullRequest.TargetBranch アプリケーションのターゲットであるブランチの完全なパスとpull request。 この変数は、リリースが新しいフローによってトリガーされた場合pull requestされます。

Azure Pipelines例: refs/heads/main
Release.Artifacts。{エイリアス}。PullRequest.TargetBranchName ブランチのターゲットであるブランチの名前pull request。 この変数は、リリースが新しいフローによってトリガーされた場合pull requestされます。

Azure Pipelines例: main

成果物ソースの 別名に関するページも参照してください。

既定の変数 - プライマリ成果物

リリース パイプラインでは、成果物の 1 つをプライマリ成果物として指定します。 指定されたプライマリ成果物の場合、Azure Pipelines変数が設定されます。

変数名 同等なもの
Build.DefinitionId Release.Artifacts。{プライマリ 成果物の別名}。DefinitionId
Build.DefinitionName Release.Artifacts。{プライマリ 成果物の別名}。DefinitionName
Build.BuildNumber Release.Artifacts。{プライマリ 成果物の別名}。BuildNumber
Build.BuildId Release.Artifacts。{プライマリ 成果物の別名}。BuildId
BuildURI 成果物を解放します。{プライマリ成果物の別名}。BuildURI
Build.SourceBranch 成果物を解放します。{プライマリ成果物の別名}。SourceBranch
SourceBranchName 成果物を解放します。{プライマリ成果物の別名}。SourceBranchName
ビルド SourceVersion 成果物を解放します。{プライマリ成果物の別名}。SourceVersion
ビルド. Repository. プロバイダー 成果物を解放します。{プライマリ成果物の別名}。リポジトリ. プロバイダー
ビルド. RequestedForID 成果物を解放します。{プライマリ成果物の別名}。RequestedForID
のビルド requested 成果物を解放します。{プライマリ成果物の別名}。Event.deployment.requestedfor.displayname
ビルド. 種類 成果物を解放します。{プライマリ成果物の別名}。各種
プル要求をビルドします。 成果物を解放します。{プライマリ成果物の別名}。プル要求
プル要求. TargetBranchName 成果物を解放します。{プライマリ成果物の別名}。プル要求 TargetBranchName

既定の変数の使用

既定の変数は、リリース パイプラインのタスクのパラメーターとして、またはスクリプト内の 2 つの方法で使用できます。

タスクへの入力として既定の変数を直接使用できます。 たとえば、エイリアスが Release.Artifacts.{Artifact alias}.DefinitionName ASPNET4 の成果物ソースに渡 す場合です。CI をタスクに対して実行する場合は、 を使用します $(Release.Artifacts.ASPNET4.CI.DefinitionName)

PowerShell スクリプト タスクへの引数での成果物変数の使用

スクリプトで既定の変数を使用するには、最初に既定の変数名の を に . 置き換える必要があります _ 。 たとえば、別名が ASPNET4 である成果物ソースの成果物変数 Release.Artifacts.{Artifact alias}.DefinitionName の値を 出力するには、PowerShell スクリプトの CI では、 を使用します $env:RELEASE_ARTIFACTS_ASPNET4_CI_DEFINITIONNAME

インライン PowerShell スクリプトでの成果物変数の使用

成果物ソースエイリアス の元の名前は に置 ASPNET4.CI き換えられる点に注意してください ASPNET4_CI

すべての変数の現在の値を表示する

  1. リリースの概要のパイプライン ビューを開き、関心のあるステージを選択します。 ステップの一覧で[ジョブの初期化] を選択します

    リリースのログを開く

  2. これにより、この手順のログが開きます。 下にスクロールして、このジョブでエージェントによって使用される値を確認します。

    リリース内の変数の値の表示

デバッグ モードでリリースを実行する

リリース全体、または個々のリリース ステージのタスクをデバッグ モードで実行することで、リリースが実行され、ログ ファイルに追加情報が表示されます。 これは、問題とエラーを解決するのに役立ちます。

  • リリース全体のデバッグ モードを開始するには、リリース パイプラインの [変数] タブに、 値を持つ という名前の変数 System.Debug true を追加します。

  • 単一ステージのデバッグ モードを開始するには、ステージのショートカット メニューから [ステージの構成] ダイアログを開き、 値を持つ という名前の変数を [変数] タブ System.Debug true に追加 します。

  • または、値を持つ という 名前の変数を含む変数グループを作成し、この変数グループをリリース パイプライン System.Debug true にリンクします。

ヒント

Azure RM サービス接続に関連するエラーが発生した場合は、「 方法: Azure Resource Manager サービス接続のトラブルシューティング」を参照してください。

カスタム変数

カスタム変数は、さまざまなスコープで定義できます。

  • 変数グループを使用して、プロジェクト内のすべての定義で値を共有します。 プロジェクト内のすべての定義、ステージ、およびタスクで同じ値を使用する必要があり、1か所で値を変更できるようにする場合は、変数グループを選択します。 変数グループを定義および管理するには、[ ライブラリ ] タブを使用します。

  • リリースパイプライン変数 を使用して、すべてのステージで値を共有します。 リリースパイプラインのすべてのステージとタスクで同じ値を使用する必要があり、1か所で値を変更できるようにする場合は、リリースパイプライン変数を選択します。 これらの変数は、リリースパイプラインの [ 変数 ] タブで定義および管理します。 [パイプライン変数] ページで、[スコープ] ドロップダウンリストを開き、[リリース] を選択します。 既定では、変数を追加すると、その変数は Release scope に設定されます。

  • ステージ変数 を使用して、1つの特定のステージ内のすべてのタスクで値を共有します。 ステージごとに異なる値にはステージレベルの変数を使用します (これはステージ内のすべてのタスクで同じです)。 これらの変数は、リリースパイプラインの [ 変数 ] タブで定義および管理します。 [パイプライン変数] ページで、[スコープ] ドロップダウンリストを開き、必要なステージを選択します。 変数を追加するときに、スコープを適切な環境に設定します。

プロジェクト、リリースパイプライン、およびステージのスコープでカスタム変数を使用すると、次のことができます。

  • 値の重複を避けることで、すべての出現箇所を1回の操作として簡単に更新できます。

  • 機密値は、リリースパイプラインのユーザーが表示したり変更したりできないように保存します。  変数の横にある南京錠 (南京錠) アイコンを選択して、構成プロパティをセキュリティで保護された (シークレット) 変数に指定します。

    重要

    非表示 (シークレット) 変数の値はサーバーに安全に格納され、保存後にユーザーが表示することはできません。 デプロイ中に、Azure Pipelinesサービスは、タスクによって参照されている場合にこれらの値を復号化し、セキュリティで保護された HTTPS チャネル経由でエージェントに渡します。

注意

カスタム変数を作成すると、標準変数を上書きできます。 たとえば、PowerShell Path 環境変数 です。 Windows エージェントでカスタム変数を作成すると、その変数が上書きされ Path $env:Path 、PowerShell は実行されません。

カスタム変数の使用

ビルドタスクとリリース タスクでカスタム変数を使用するには、変数名をかっこで囲み、その前に文字を付 $ けることです。 たとえば 、adminUserName という名前の変数がある場合は、その変数の現在の値を としてタスクのパラメーターに挿入できます $(adminUserName)

注意

同じスコープ (ジョブやステージなど) 内のパイプラインにリンクされている異なるグループ内の変数は競合します。その結果、予測できない場合があります。 変数には、変数グループ全体で異なる名前を使用してください。

スクリプトでの変数の定義と変更

スクリプトから変数を定義または変更するには、 task.setvariable logging コマンドを使用します。 更新された変数の値は実行中のジョブにスコープが設定され、ジョブやステージ間ではフローされないことに注意してください。 変数名は大文字に変換され、文字 "." と "" は "_" に置き換えられます。

たとえば、Agent.WorkFolderAGENT_WORKFOLDER にします。 Windows では、これはまたはとしてアクセスし %AGENT_WORKFOLDER% $env:AGENT_WORKFOLDER ます。 Linux と macOS では、を使用し $AGENT_WORKFOLDER ます。

ヒント

でスクリプトを実行できます。

バッチスクリプト

sauce変数と変数を設定する secret.Sauce

@echo ##vso[task.setvariable variable=sauce]crushed tomatoes
@echo ##vso[task.setvariable variable=secret.Sauce;issecret=true]crushed tomatoes with garlic

変数の読み取り

引数

"$(sauce)" "$(secret.Sauce)"

スクリプト

@echo off
set sauceArgument=%~1
set secretSauceArgument=%~2
@echo No problem reading %sauceArgument% or %SAUCE%
@echo But I cannot read %SECRET_SAUCE%
@echo But I can read %secretSauceArgument% (but the log is redacted so I do not spoil
     the secret)

変数を読み取ったコンソール出力:

No problem reading crushed tomatoes or crushed tomatoes
But I cannot read 
But I can read ******** (but the log is redacted so I do not spoil the secret)