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 procedura impacchettata e 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.

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 qualificato 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 su 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 rilascio e selezionando Visualizza YAML durante la modifica dell'attività.

Versioni delle attività

Le attività sono versionate, e devi 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à che esistono per la tua organizzazione.

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

steps:
- task: PublishTestResults@2

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.
  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 effettivamente eseguita se si è in uno stato di successo.

Continua in caso di errore modifica questa situazione in modo sottile. In effetti "inganna" tutti i passaggi/lavori downstream per considerare qualsiasi risultato come "successo" ai fini della decisione. Oppure per metterlo in un altro modo, dice "non considerare l'errore di questa attività mentre prendi una decisione sulla condizione della struttura contenitrice".

Il periodo di timeout inizia all'avvio dell'esecuzione dell'attività. Non include il tempo 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.

Obiettivo passi

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 ripetizioni. Per altre informazioni sulle proprietà delle attività, vedere steps.task nello schema YAML.

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

Nota

  • Richiede la versione 2.194.0 o successiva dell'agente. In Azure DevOps Server 2022 i tentativi non sono supportati per le attività senza agente. Per ulteriori 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 numero massimo di tentativi consentiti è 10.
  • Il tempo di attesa tra i tentativi aumenta dopo ogni tentativo non riuscito, secondo una strategia di backoff esponenziale. Il primo tentativo si verifica dopo 1 secondo, il secondo tentativo dopo 4 secondi e il 10° tentativo dopo 100 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à.

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 eseguita la script fase, che è una scorciatoia per l'attività Riga di comando, seguita dalla sintassi dell'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 una scorciatoia per Bash@3, seguito dalla sintassi del compito 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 build (Azure Pipelines)

Gli strumenti di installazione consentono alla pipeline di build di installare e gestire le tue dipendenze. In particolare, è possibile:

  • Installare uno strumento o un runtime al volo (anche sugli agenti ospitati da Microsoft) giusto in tempo per la build 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.

Attività dell'installer 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, puoi disabilitare le attività del Marketplace, le attività della posta in arrivo 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