工作類型使用方式 &
Azure DevOps Services |Azure DevOps Server 2022 - Azure DevOps Server 2019 |TFS 2018
注意
在 Microsoft Team Foundation Server (TFS) 2018 和舊版中，組建和發行管線稱為定義、執行稱為組建、服務連線稱為服務端點、階段稱為環境，而作業稱為階段。
工作是在管線中定義自動化的建置組塊。 工作就是透過一組輸入來抽象化的封裝指令碼或程序。
當您將工作新增至管線時，也可能將一組 需求 新增至管線。 要求會定義必須在 代理程式 上安裝的必要條件，才能執行工作。 當您執行組建或部署時，將會選擇符合這些需求的代理程式。
當您執行 作業時，所有工作都會依序執行，一個接著一個。 若要在多個代理程式上平行執行相同的一組工作，或在不使用代理程式的情況下執行某些工作，請參閱 作業。
根據預設，所有工作都會在相同的內容中執行，無論是在 主機上 或 作業容器中。 您可以選擇性地使用 步驟目標 來控制個別工作的內容。
深入瞭解如何使用 內建工作來指定工作的屬性。
自訂工作
我們提供一些 內建工作 ，以啟用基本建置和部署案例。 我們也提供 建立您自己的自訂工作的指引。
此外， Visual Studio Marketplace 提供許多擴充功能;安裝到您的訂用帳戶或集合時，每一項都會使用一或多個工作來擴充工作目錄。 此外，您可以撰寫自己的 自訂延伸模組 ，將工作新增至 Azure Pipelines 或 TFS。
在 YAML 管線中，您會依名稱參考工作。 如果名稱同時符合現成工作和自訂工作，則內建工作會優先。 您可以使用工作 GUID 或自訂工作的完整名稱來避免此風險：
steps:
- task: myPublisherId.myExtensionId.myContributionId.myTaskName@1 #format example
- task: qetza.replacetokens.replacetokens-task.replacetokens@3 #working example
若要尋找 myPublisherId 和 myExtensionId ，請選取 [ 取得 市集中的工作]。 URL 字串中的 之後 itemName 的值是 myPublisherId 和 myExtensionId 。 您也可以將工作新增至 發行管線 ，並在編輯工作時選取 [ 檢視 YAML ] 來尋找完整名稱。
工作版本
工作已設定版本，您必須指定管線中使用的工作主要版本。 這有助於防止發行新版的工作時發生問題。 工作通常回溯相容，但在某些情況下，您可能會在工作自動更新時遇到無法預期的錯誤。
例如，當發行新的次要版本 (1.2 到 1.3) 時，您的組建或版本會自動使用新版本。 不過，如果新的主要版本發行 (例如 2.0) ，則您的組建或版本將會繼續使用您指定的主要版本，直到您編輯管線並手動變更為新的主要版本為止。 組建或發行記錄檔將包含新的主要版本可用警示。
您可以藉由在簽署 (範例之後 @ 指定工作的完整版本號碼，來設定要使用的次要版本： GoTool@0.3.1) 。 您只能使用組織中存在的工作版本。
在 YAML 中，您會在 @ 工作名稱中使用 指定主要版本。
例如，若要釘選到工作 PublishTestResults 的第 2 版：
steps:
- task: PublishTestResults@2
TFS 中無法使用 YAML 管線。
工作控制項選項
每個工作都會提供一些 控制項選項。
控制項選項可在 區段上 task 作為索引鍵使用。
- task: string # reference to a task and version, e.g. "VSBuild@1"
condition: expression # see below
continueOnError: boolean # 'true' if future steps should run even if this step fails; defaults to 'false'
enabled: boolean # whether or not to run this step; defaults to 'true'
timeoutInMinutes: string # how long to wait before timing out the task
控制項選項可在 區段上 task 作為索引鍵使用。
- task: string # reference to a task and version, e.g. "VSBuild@1"
condition: expression # see below
continueOnError: boolean # 'true' if future steps should run even if this step fails; defaults to 'false'
enabled: boolean # whether or not to run this step; defaults to 'true'
timeoutInMinutes: string # how long to wait before timing out the task
target: string # 'host' or the name of a container resource to target
控制項選項可在 區段上 task 作為索引鍵使用。
- task: string # reference to a task and version, e.g. "VSBuild@1"
condition: expression # see below
continueOnError: boolean # 'true' if future steps should run even if this step fails; defaults to 'false'
enabled: boolean # whether or not to run this step; defaults to 'true'
retryCountOnTaskFailure: number # Max number of retries; default is zero
timeoutInMinutes: string # how long to wait before timing out the task
target: string # 'host' or the name of a container resource to target
注意
指定的工作或工作無法不定期決定作業/階段是否繼續。 其所能執行的動作是提供 成功 或 失敗的狀態，而下游工作/作業各有條件計算，可讓他們決定是否要執行。 預設條件，其有效「如果我們處於成功狀態，請執行」。
在錯誤時繼續 ，會以細微的方式改變這一點。 它會有效地「技巧」所有下游步驟/作業，以針對做出該決策的目的，將任何結果視為「成功」。 或者，換句話說，它會指出「當您決定包含結構的條件時，請勿考慮這項工作失敗」。
當工作開始執行時，逾時期間就會開始。 它不包含工作排入佇列或正在等候代理程式的時間。
在此 YAML 中， PublishTestResults@2 即使上一個步驟因為 succeededOrFailed () 條件而失敗，仍會執行。
steps:
- task: UsePythonVersion@0
inputs:
versionSpec: '3.x'
architecture: 'x64'
- task: PublishTestResults@2
inputs:
testResultsFiles: "**/TEST-*.xml"
condition: succeededOrFailed()
條件
只有在具有相同代理程式組件區的所有先前直接和間接相依性都成功時。 如果您有不同的代理程式集區，則這些階段或作業將會同時執行。 如果 YAML 中沒有設定條件，則這是預設值。
即使先前的相依性失敗、除非已取消執行。 在此
succeededOrFailed()條件的 YAML 中使用。即使先前的相依性失敗、即使已取消執行。 在此
always()條件的 YAML 中使用。只有在先前的相依性失敗時。 在此
failed()條件的 YAML 中使用。
步驟目標
工作會在執行內容中執行，也就是代理程式主機或容器。
個別步驟可以藉由指定 target 來覆寫其內容。
可用的選項是以代理程式主機為目標以及管線中定義之任何容器的字 host 組。
例如：
resources:
containers:
- container: pycontainer
image: python:3.11
steps:
- task: SampleTask@1
target: host
- task: AnotherTask@1
target: pycontainer
在這裡，會在 SampleTask 主機上執行，並在 AnotherTask 容器中執行。
如果工作失敗，重試次數
使用 retryCountOnTaskFailure 來指定工作失敗時重試次數。 預設值是零。
- task: <name of task>
retryCountOnTaskFailure: <max number of retries>
...
注意
- 需要代理程式 2.194.0 版或更新版本。 不支援無代理程式工作。
- 失敗的工作會以秒為單位重試。 每個重試之間的等候時間會在每次嘗試失敗之後增加。
- 沒有關于工作等冪性的假設。 例如，如果工作有副作用 (，如果部分建立外部資源) ，則第二次執行時可能會失敗。
- 沒有可供工作使用之重試計數的相關資訊。
- 系統會將警告新增至工作記錄，指出在重試之前失敗。
- 嘗試重試工作的所有嘗試都會顯示在 UI 中，做為相同工作節點的一部分。
TFS 中無法使用 YAML 管線。
環境變數
Azure DevOps Server 2019 和更新版本中支援 YAML 管線。
每個工作都有一個 env 屬性，這是字串組的清單，這些字串組代表對應至工作進程的環境變數。
task: AzureCLI@2
displayName: Azure CLI
inputs: # Specific to each task
env:
ENV_VARIABLE_NAME: value
ENV_VARIABLE_NAME2: value
...
下列範例會 script 執行步驟，這是 命令列工作的快捷方式，後面接著對等的工作語法。 此範例會將值指派給 AZURE_DEVOPS_EXT_PAT 環境變數，以用來向 Azure DevOps CLI 進行驗證。
# Using the script shortcut syntax
- script: az pipelines variable-group list --output table
env:
AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
displayName: 'List variable groups using the script step'
# Using the task syntax
- task: CmdLine@2
inputs:
script: az pipelines variable-group list --output table
env:
AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
displayName: 'List variable groups using the command line task'
(Azure Pipelines) 建置工具安裝程式
工具安裝程式可讓您的組建管線安裝及控制相依性。 具體而言，您可以：
立即安裝工具或執行時間 (即使在 Microsoft 裝載的代理程式 上) CI 組建。
針對多個版本的相依性驗證您的應用程式或程式庫，例如Node.js。
例如，您可以設定組建管線，以針對多個版本的 Node.js執行和驗證您的應用程式。
範例：在多個版本的 Node.js 上測試及驗證您的應用程式
使用下列內容，在專案的基底目錄中建立 azure-pipelines.yml 檔案。
pool:
vmImage: ubuntu-latest
steps:
# Node install
- task: NodeTool@0
displayName: Node install
inputs:
versionSpec: '12.x' # The version we're installing
# Write the installed version to the command line
- script: which node
建立新的組建管線 並加以執行。 觀察組建的執行方式。 如果Node.js 工具安裝程式 尚未在代理程式上，則會下載Node.js版本。 命令列腳本會記錄磁片上Node.js版本的位置。
TFS 中無法使用 YAML 管線。
工具：Node.js安裝程式
公用程式：命令列工具安裝程式工作
如需工具安裝程式工作的清單，請參閱 工具安裝程式工作。
停用內建和 Marketplace 工作
在 [組織設定] 頁面上，您可以停用 Marketplace 工作、內建工作或兩者。
停用 Marketplace 工作有助於增加管線 的安全性 。
如果您同時停用內建和 Marketplace 工作，則只會提供您使用 tfx 安裝的工作。
相關文章
說明及支援
- 請參閱 我們的疑難排解 頁面
- 取得Stack Overflow的建議，並隨意張貼您的問題、搜尋解答，或在我們的Azure DevOps 開發人員社群上建議功能。 支援 頁面。