Condividi tramite

Tipi di attività e utilizzo

  • Articolo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Un'attività esegue un'azione in una pipeline ed è uno script o una routine in pacchetto astratta con un set di input. Le attività sono i blocchi predefiniti per definire l'automazione in una pipeline.

Quando si esegue un processo, tutte le attività vengono eseguite in sequenza, una dopo l'altra. Per eseguire lo stesso set di attività in parallelo su più agenti o per eseguire alcune attività senza usare un agente, vedere Processi.

Per impostazione predefinita, tutte le attività vengono eseguite nello stesso contesto, sia nell'host che in un contenitore di processi.

Facoltativamente, è possibile usare le destinazioni dei passaggi per controllare il contesto per una singola attività.

Altre informazioni su come specificare le proprietà per un'attività con le attività predefinite.

Quando si esegue un processo, tutte le attività vengono eseguite in sequenza, una dopo l'altra, in un agente. Per eseguire lo stesso set di attività in parallelo su più agenti o per eseguire alcune attività senza usare un agente, vedere Processi.

Per altre informazioni sugli attributi generali supportati dalle attività, vedere le informazioni di riferimento su YAML per steps.task.

Attività personalizzate

Azure DevOps include attività predefinite per abilitare scenari di compilazione e distribuzione fondamentali. È anche possibile creare un'attività personalizzata.

Visual Studio Marketplace offre inoltre molte estensioni, ognuna delle quali, se installata nella sottoscrizione o nella raccolta, estende il catalogo attività con una o più attività. È anche possibile scrivere estensioni personalizzate per aggiungere attività ad Azure Pipelines.

Nelle pipeline YAML si fa riferimento alle attività in base al nome. Se un nome corrisponde sia a un'attività predefinita che a un'attività personalizzata, l'attività predefinita ha la precedenza. È possibile usare il GUID dell'attività o un nome completo per l'attività personalizzata per evitare questo rischio:

steps:
- task: myPublisherId.myExtensionId.myContributionId.myTaskName@1 #format example
- task: qetza.replacetokens.replacetokens-task.replacetokens@3 #working example

Per trovare myPublisherId e myExtensionId, selezionare Ottieni in un'attività nel marketplace. I valori dopo nella itemName stringa URL sono myPublisherId e myExtensionId. È anche possibile trovare il nome completo aggiungendo l'attività a una pipeline di versione e selezionando Visualizza YAML durante la modifica dell'attività.

Versioni delle attività

Le attività vengono con controllo delle versioni ed è necessario specificare la versione principale dell'attività usata nella pipeline. Ciò consente di evitare problemi quando vengono rilasciate nuove versioni di un'attività. Le attività sono in genere compatibili con le versioni precedenti, ma in alcuni scenari è possibile che si verifichino errori imprevedibili quando un'attività viene aggiornata automaticamente.

Quando viene rilasciata una nuova versione secondaria (ad esempio, da 1.2 a 1.3), la pipeline usa automaticamente la nuova versione. Tuttavia, se viene rilasciata una nuova versione principale (ad esempio 2.0), la pipeline continua a usare la versione principale specificata fino a quando non si modifica la pipeline e si passa manualmente alla nuova versione principale. Il log includerà un avviso che indica che è disponibile una nuova versione principale.

È possibile impostare la versione secondaria usata specificando il numero di versione completo di un'attività dopo il @ segno (ad esempio: GoTool@0.3.1). È possibile usare solo le versioni delle attività esistenti per l'organizzazione.

In YAML specificare la versione principale usando @ nel nome dell'attività. Ad esempio, per aggiungere alla versione 2 dell'attività PublishTestResults :

steps:
- task: PublishTestResults@2

Le pipeline YAML non sono disponibili in TFS.

Opzioni di controllo delle attività

Ogni attività offre alcune opzioni di controllo.

Le opzioni di controllo sono disponibili come chiavi nella task sezione .

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.

Le opzioni di controllo sono disponibili come chiavi nella task sezione .

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.

Le opzioni di controllo sono disponibili come chiavi nella task sezione .

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
  retryCountOnTaskFailure: string # Number of retries if the task fails.

Nota

Un'attività o un processo specificato non può decidere unilateralmente se il processo/fase continua. Ciò che può fare è offrire uno stato di esito positivo o negativo e le attività/i processi downstream hanno un calcolo delle condizioni che consente loro di decidere se eseguire o meno. Condizione predefinita che viene eseguita in modo efficace se si è in uno stato di esito positivo.

Continua in caso di errore modifica questa situazione in modo sottile. In effetti "trucchi" tutti i passaggi/processi downstream nel considerare qualsiasi risultato come "successo" ai fini del processo decisionale. Oppure per metterlo in un altro modo, dice "non considerare l'errore di questa attività quando si sta prendendo una decisione sulla condizione della struttura contenitore".

Il periodo di timeout inizia all'avvio dell'esecuzione dell'attività. Non include l'ora in cui l'attività è in coda o è in attesa di un agente.

Nota

Le pipeline possono avere un timeout a livello di processo specificato oltre a un timeout a livello di attività. Se l'intervallo di timeout a livello di processo è trascorso prima del completamento del passaggio, il processo in esecuzione viene terminato, anche se il passaggio è configurato con un intervallo di timeout più lungo. Per altre informazioni, vedere Timeout.

In questo YAML, PublishTestResults@2 viene eseguito anche se il passaggio precedente ha esito negativo a causa della condizione succeededOrFailed().

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.x'
    architecture: 'x64'
- task: PublishTestResults@2
  inputs:
    testResultsFiles: "**/TEST-*.xml"
  condition: succeededOrFailed()

Condizioni

  • Solo quando tutte le dipendenze dirette e indirette precedenti con lo stesso pool di agenti hanno esito positivo. Se sono presenti pool di agenti diversi, tali fasi o processi vengono eseguiti simultaneamente. Questa condizione è l'impostazione predefinita se non viene impostata alcuna condizione in YAML.

  • Anche se una dipendenza precedente ha esito negativo, a meno che l'esecuzione non venga annullata. Usare succeededOrFailed() in YAML per questa condizione.

  • Anche se una dipendenza precedente ha esito negativo e anche se l'esecuzione viene annullata. Usare always() in YAML per questa condizione.

  • Solo quando una dipendenza precedente ha esito negativo. Usare failed() in YAML per questa condizione.

Destinazione passaggio

Le attività vengono eseguite in un contesto di esecuzione, ovvero l'host dell'agente o un contenitore. Un singolo passaggio può eseguire l'override del contesto specificando un oggetto target. Le opzioni disponibili sono la parola host per specificare come destinazione l'host dell'agente e tutti i contenitori definiti nella pipeline. Ad esempio:

resources:
  containers:
  - container: pycontainer
    image: python:3.11

steps:
- task: SampleTask@1
  target: host
- task: AnotherTask@1
  target: pycontainer

In questo caso, l'oggetto SampleTask viene eseguito nell'host ed AnotherTask eseguito in un contenitore.

Numero di tentativi se l'attività non è riuscita

Usare retryCountOnTaskFailure per specificare il numero di tentativi in caso di errore dell'attività. Il valore predefinito è zero tentativi. Per altre informazioni sulle proprietà delle attività, vedere steps.task nello schema YAML.

- task: <name of task>
  retryCountOnTaskFailure: <max number of retries>
   ...

Nota

  • Richiede l'agente versione 2.194.0 o successiva. In Azure DevOps Server 2022 i tentativi non sono supportati per le attività senza agente. Per altre informazioni, vedere Aggiornamento del servizio Azure DevOps 16 novembre 2021 - Tentativi automatici per un'attività e aggiornamento del servizio Azure DevOps 14 giugno 2025 - Tentativi per le attività del server.
  • Il tempo di attesa tra ogni tentativo aumenta dopo ogni tentativo non riuscito. Il primo tentativo viene eseguito in secondi.
  • Non esiste alcun presupposto sulla idempotenza dell'attività. Se l'attività ha effetti collaterali (ad esempio, se ha creato parzialmente una risorsa esterna), potrebbe non riuscire la seconda volta che viene eseguita.
  • Non sono disponibili informazioni sul numero di tentativi reso disponibile per l'attività.
  • Viene aggiunto un avviso ai log attività che indica che non è riuscito prima di riprovare.
  • Tutti i tentativi di ripetizione di un'attività vengono visualizzati nell'interfaccia utente come parte dello stesso nodo attività.

Le pipeline YAML non sono disponibili in TFS.

Variabili di ambiente

Ogni attività ha una env proprietà che rappresenta un elenco di coppie di stringhe che rappresentano le variabili di ambiente mappate nel processo di attività.

- task: AzureCLI@2
  displayName: Azure CLI
  inputs: # Specific to each task
  env:
    ENV_VARIABLE_NAME: value
    ENV_VARIABLE_NAME2: value
  ...

Nell'esempio seguente viene eseguito il script passaggio , ovvero un collegamento per l'attività Riga di comando, seguito dalla sintassi di attività equivalente. Questo esempio assegna un valore alla variabile di ambiente, usata per l'autenticazione con l'interfaccia della AZURE_DEVOPS_EXT_PAT riga di comando di Azure DevOps.

# 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'


- task: Bash@3
  inputs:
     targetType: # specific to each task
  env:
    ENV_VARIABLE_NAME: value
    ENV_VARIABLE_NAME2: value
  ...

Nell'esempio seguente viene eseguito il script passaggio , ovvero un collegamento per il Bash@3, seguito dalla sintassi dell'attività equivalente. In questo esempio viene assegnato un valore alla ENV_VARIABLE_NAME variabile di ambiente e viene restituito il valore.

# Using the script shortcut syntax
- script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: "my value"
  displayName: 'echo environment variable'

# Using the task syntax
- task: Bash@2
  inputs:
    script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: "my value"
  displayName: 'echo environment variable'

Programmi di installazione degli strumenti di compilazione (Azure Pipelines)

I programmi di installazione degli strumenti consentono alla pipeline di compilazione di installare e controllare le dipendenze. In particolare, è possibile:

  • Installare uno strumento o un runtime in tempo reale (anche sugli agenti ospitati da Microsoft) just-in-time per la compilazione CI.

  • Convalidare l'app o la libreria in base a più versioni di una dipendenza, ad esempio Node.js.

Ad esempio, è possibile configurare la pipeline di compilazione per l'esecuzione e la convalida dell'app per più versioni di Node.js.

Esempio: Testare e convalidare l'app in più versioni di Node.js

Creare un file azure-pipelines.yml nella directory di base del progetto con il contenuto seguente.

pool:
  vmImage: ubuntu-latest

steps:
# Node install
- task: UseNode@1
  displayName: Node install
  inputs:
    version: '16.x' # The version we're installing
# Write the installed version to the command line
- script: which node

Creare una nuova pipeline di compilazione ed eseguirla. Osservare come viene eseguita la compilazione. Il programma di installazione dello strumento di Node.js scarica la versione Node.js se non è già presente nell'agente. Lo script della riga di comando registra il percorso della versione Node.js su disco.

Le pipeline YAML non sono disponibili in TFS.

Attività del programma di installazione degli strumenti

Per un elenco delle attività del programma di installazione degli strumenti, vedere Attività del programma di installazione degli strumenti.

Disabilitazione delle attività predefinite e del Marketplace

Nella pagina delle impostazioni dell'organizzazione è possibile disabilitare le attività del Marketplace, le attività incluse o entrambe. La disabilitazione delle attività del Marketplace consente di aumentare la sicurezza delle pipeline. Se si disabilitano sia le attività predefinite che le attività del Marketplace, sono disponibili solo le attività installate con tfx .

Assistenza e supporto