Risolvere i problemi di esecuzione delle pipeline

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Se l'esecuzione della pipeline non viene completata, usare le informazioni di diagnostica e i log nella pagina di riepilogo dell'esecuzione della pipeline per risolvere il problema. Questa guida fornisce istruzioni per la diagnosi degli errori della pipeline tramite log, strumenti di analisi degli errori e tecniche comuni per la risoluzione dei problemi. Informazioni su come identificare le cause radice e implementare soluzioni per mantenere le pipeline in esecuzione senza problemi.

Tip

È possibile usare l'intelligenza artificiale per facilitare questa attività più avanti in questo articolo, oppure vedere Abilitare l'assistenza AI con Azure DevOps MCP Server per iniziare.

Visualizza i log

Selezionare il messaggio di errore per visualizzare i log per l'attività che non è stata completata.

La pagina dei log mostra l'errore selezionato. In questo esempio si verifica un errore nell'attività cmd-line , in cui il echo comando viene immesso come ech.

È possibile visualizzare il log non elaborato per l'attività scegliendo Visualizza log non elaborato ed è possibile eseguire ricerche nel log usando Trova.

Analizzare i log dell'attività non riuscita per ottenere informazioni sugli errori e indicazioni sul motivo per cui l'attività ha esito negativo. Per impostazione predefinita, i log nonverbose vengono generati da un'esecuzione della pipeline. Se i log predefiniti non indicano la causa del problema, è possibile ottenere altre informazioni configurando i log dettagliati.

Pagina di analisi degli errori

L'assistenza per la risoluzione dei problemi è disponibile tramite la pagina Analisi degli errori . Spostare il mouse sulla riga delle informazioni sull'errore e scegliere l'icona Visualizza analisi .

Scegliere Visualizza agente per gli agenti self-hosted (o Informazioni sull'immagine dell'agente ospitato per gli agenti ospitati da Microsoft) per visualizzare altre informazioni sull'agente usato per eseguire la pipeline e Visualizzare il log per visualizzare i log di esecuzione della pipeline.

Scegliere il nome dell'attività sotto Dettagli di runtime per visualizzare informazioni sull'attività.

In questo esempio, puoi vedere che c'è un errore nel Value del Script. Scegliere Informazioni su questa attività per visualizzare la documentazione per l'attività.

Se il problema non è evidente dalla pagina di riepilogo dell'esecuzione della pipeline o dall'esplorazione dei log, vedere la sezione Problemi comuni seguenti e vedere Esaminare i log per diagnosticare i problemi della pipeline per informazioni sul download dei log completi che includono altre informazioni di diagnostica.

Problemi comuni

• Questa pipeline richiede l'autorizzazione per accedere a una risorsa prima che l'esecuzione possa continuare
• Timeout del lavoro
• Problemi durante il download del codice
• La mia pipeline non riesce in un passaggio della riga di comando, come MSBUILD
• Errori di file o cartelle in uso
• Errori intermittenti o incoerenti di MSBuild
• Il processo smette di rispondere
• Terminazioni di riga per più piattaforme
• Variabili con l'apostrofo accodato
• Problemi relativi alla connessione al servizio
• Pipeline non riceve più segnali dall'agente

Analisi delle attività per le esecuzioni di pipeline non riuscite

Azure DevOps fornisce un'impostazione Task Insights per le esecuzioni di pipeline non riuscite, che, se abilitata, fornisce notifiche popup degli errori di compilazione con un collegamento per visualizzare un report.

Per configurare questa impostazione, passare a Funzionalità di anteprima, trovare Approfondimenti attività per esecuzioni non riuscite della pipeline e scegliere l'impostazione desiderata.

Notifiche per le esecuzioni non riuscite

Azure DevOps include notifiche integrate per i fallimenti delle pipeline. Per abilitare le notifiche:

1. Passare a Impostazioni progetto>Notifiche per il progetto.
2. Scegliere il tipo di notifica che si vuole ricevere. Per ricevere una notifica ogni volta che un'esecuzione della pipeline ha esito negativo, selezionare Una compilazione non riesce.

Questa pipeline richiede l'autorizzazione per accedere a una risorsa prima che l'esecuzione possa continuare

Se la pipeline non sembra avviarsi o viene visualizzato un messaggio di errore come This pipeline needs permission to access a resource before this run can continue, verificare se la pipeline è in attesa di un'autorizzazione per essere eseguita da una risorsa, ad esempio una connessione al servizio o un pool di agenti.

1. Passare alla pipeline e avviare manualmente una esecuzione.
2. Il messaggio Questa pipeline richiede l'autorizzazione per accedere a una risorsa prima che questa esecuzione possa continuare. Selezionare Visualizza accanto al messaggio.
3. Nella schermata In attesa di revisione selezionare Consenti e nella schermata di conferma selezionare di nuovo Consenti .

Questa azione aggiunge in modo esplicito la pipeline come utente autorizzato della risorsa.

Esistono due modi per autorizzare le pipeline ad accedere al pool di agenti.

• Autorizzare pipeline specifiche: autorizzare singolarmente pipeline specifiche da un progetto di Azure DevOps per l'esecuzione nel pool.
• Configurare l'accesso aperto: configurare un pool di agenti a livello di progetto in modo che sia disponibile per tutte le pipeline in tale progetto.

Autorizzare pipeline specifiche

È possibile autorizzare singolarmente l'esecuzione di pipeline specifiche in un pool di agenti seguendo la procedura descritta nella sezione precedente quando si riceve un messaggio come This pipeline needs permission to access a resource before this run can continue.

È anche possibile aggiungere e rimuovere manualmente pipeline dall'elenco autorizzato eseguendo la procedura seguente. Questa procedura viene eseguita a livello di progetto nell'organizzazione Azure DevOps.

1. In Azure DevOps passare a Impostazioni progetto, Agent pools, scegliere il pool self-hosted e scegliere Security.
2. Per aggiungere una pipeline all'elenco autorizzato, scegliere +.
3. Scegliere X(Revoca accesso) per rimuovere una pipeline dall'elenco autorizzato.

Configurare l'accesso aperto

Alcune risorse consentono di configurare l'accesso aperto in modo che ogni nuova definizione della pipeline non richieda l'autorizzazione esplicita.

La configurazione di Open access richiede autorizzazioni di amministratore di Project .

Per configurare Open access per i pool di agenti:

1. In Azure DevOps passare a Impostazioni progetto, Agent pools, scegliere il pool self-hosted e scegliere Security.
2. Scegliere Altre azioni, Apri accesso, per abilitare l'accesso aperto e scegliere di nuovo Apri accesso per confermare.
3. Per revocare l'accesso aperto, scegliere Limita l'autorizzazione.

Per verificare se Open access è disponibile per altri tipi di risorse, vedere Manage security in Azure Pipelines e cercare Open access.

Per altre informazioni sull'accesso aperto per i pool di agenti, vedere Impostare le autorizzazioni della pipeline per un singolo pool di agenti e autorizzazioni di pipeline.

Timeout del lavoro

Una pipeline può funzionare a lungo e poi fallire a causa del timeout del processo. Il timeout del processo dipende strettamente dall'agente in uso. Gli agenti gratuiti ospitati da Microsoft hanno un timeout massimo di 60 minuti per job per un repository privato e di 360 minuti per un repository pubblico.

Per aumentare il timeout massimo per un processo, è possibile scegliere una delle opzioni seguenti.

• Acquistare un agente ospitato da Microsoft che offre 360 minuti per tutti i processi, indipendentemente dal repository usato
• Usare un agente self-hosted per escludere eventuali problemi di timeout dovuti all'agente

Altre informazioni sul timeout del lavoro.

Annotazioni

Se i processi dell'agente ospitato da Microsoft vanno in timeout, verificare che il timeout della pipeline sia impostato su un valore maggiore rispetto al timeout massimo per un'attività. Per verificare, vedere Timeout.

Problemi durante il download del codice

• La mia pipeline sta fallendo in un passaggio di checkout
• Problemi relativi al controllo della versione di Team Foundation

La mia pipeline sta fallendo in un passaggio di checkout

Se si utilizza un passaggio checkout in un repository Git di Azure Repos nella propria organizzazione situato in un progetto diverso rispetto alla pipeline, assicurarsi che l'impostazione Limitare l'ambito di autorizzazione del processo al progetto corrente sia disabilitata oppure seguire i passaggi in Identità di build con ambito per assicurarsi che la pipeline abbia accesso al repository.

Quando la pipeline non riesce ad accedere al repository a causa di un ambito di autorizzazione del processo limitato, si riceverà l'errore Git fetch failed with exit code 128 e i log contengono una voce simile a Remote: TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting.

Assicurati che la pipeline fallisca immediatamente con Could not find a project that corresponds with the repository, e che il nome del progetto e del repository siano corretti nel passaggio checkout o nella dichiarazione della risorsa del repository.

Problemi relativi al controllo della versione di Team Foundation

• Ottieni fonti che non scaricano alcuni file
• Ottenere sorgenti tramite Team Foundation Proxy

Ottieni fonti che non scaricano alcuni file

È possibile che venga visualizzato un messaggio nel log "Tutti i file aggiornati" dal tf get comando . Verificare che l'identità integrata del servizio disponga dell'autorizzazione per scaricare le sorgenti. Per consentire il download delle origini, è necessaria l'autorizzazione per l'identità Project Collection Build Service o Project Build Service, a seconda dell'ambito di autorizzazione selezionato nella scheda Generale della pipeline di compilazione. Nell'interfaccia utente Web del controllo della versione è possibile esplorare i file di progetto a qualsiasi livello della gerarchia di cartelle e controllare le impostazioni di sicurezza.

Ottenere sorgenti tramite Team Foundation Proxy

Il modo più semplice per configurare l'agente per ottenere le origini tramite un proxy di Team Foundation consiste nell'impostare le variabili TFSPROXY di ambiente che puntano al server proxy TFVC per l'esecuzione dell'agente come utente.

Windows:

    set TFSPROXY=http://tfvcproxy:8081
    setx TFSPROXY=http://tfvcproxy:8081 // If the agent service is running as NETWORKSERVICE or any service account you can't easily set user level environment variable

macOS/Linux:

    export TFSPROXY=http://tfvcproxy:8081

La mia pipeline non riesce in un passaggio della riga di comando, come MSBUILD

È utile limitare se un errore di compilazione o versione è il risultato di un problema di prodotto Azure Pipelines (agente o attività). Gli errori di compilazione e rilascio possono anche derivare da comandi esterni.

Controllare i log per la riga di comando esatta eseguita dall'attività non riuscita. Il tentativo di eseguire il comando in locale dalla riga di comando potrebbe riprodurre il problema. Può essere utile eseguire il comando in locale dal computer e/o accedere al computer ed eseguire il comando come account del servizio.

Ad esempio, il problema si verifica durante la parte MSBuild della pipeline di compilazione. State usando l'attività MSBuild o Visual Studio Build? In tal caso, provare a eseguire lo stesso comando MSBuild in un computer locale usando gli stessi argomenti. Se è possibile riprodurre il problema in un computer locale, i passaggi successivi consentono di analizzare il problema di MSBuild .

Layout del file

L'ubicazione degli strumenti, delle librerie, delle intestazioni e di altri elementi necessari per una compilazione potrebbe essere diversa nell'agente ospitato rispetto al computer locale. Se una compilazione non riesce perché non riesce a trovare uno di questi file, è possibile usare gli script seguenti per esaminare il layout nell'agente. Ciò potrebbe aiutare a rilevare il file mancante.

Creare una nuova pipeline YAML in un percorso temporaneo, ad esempio un nuovo repository creato per la risoluzione dei problemi. Come scritto, lo script cerca le directory sul tuo percorso. Facoltativamente, è possibile modificare la SEARCH_PATH= riga per eseguire ricerche in altre posizioni.

# Script for Linux and macOS
pool: { vmImage: ubuntu-latest } # or whatever pool you use
steps:
- checkout: none
- bash: |
    SEARCH_PATH=$PATH  # or any colon-delimited list of paths
    IFS=':' read -r -a PathDirs <<< "$SEARCH_PATH"
    echo "##[debug] Found directories"
    for element in "${PathDirs[@]}"; do
        echo "$element"
    done;
    echo;
    echo;  
    echo "##[debug] Found files"
    for element in "${PathDirs[@]}"; do
        find "$element" -type f
    done

# Script for Windows
pool: { vmImage: windows-2019 } # or whatever pool you use
steps:
- checkout: none
- powershell: |
    $SEARCH_PATH=$Env:Path
    Write-Host "##[debug] Found directories"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Write-Host "$Dir"
    }
    Write-Host ""
    Write-Host ""
    Write-Host "##[debug] Found files"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Get-ChildItem $Dir -File -ErrorAction Continue | ForEach-Object -Process {
        Write-Host $_.FullName
      }
    }

Differenze tra il prompt dei comandi locale e l'agente

Tenere presente che alcune differenze sono effettive quando si esegue un comando in un computer locale e quando una compilazione o una versione è in esecuzione in un agente. Se l'agente è configurato per l'esecuzione come servizio in Linux, macOS o Windows, non viene eseguito all'interno di una sessione interattiva con accesso. Senza una sessione con accesso interattivo, esistono altre limitazioni per l'interazione dell'interfaccia utente.

Errori di file o cartelle in uso

File or folder in use gli errori sono indicati da messaggi di errore come:

• Access to the path [...] is denied.
• The process cannot access the file [...] because it is being used by another process.
• Access is denied.
• Can't move [...] to [...]

Passaggi per la risoluzione dei problemi:

• Rilevare file e cartelle in uso
• Esclusione antivirus
• MSBuild e /nodeReuse:false
• MSBuild e /maxcpucount:[n]

Rilevare file e cartelle in uso

In Windows, gli strumenti come Process Monitor possono essere per acquisire una traccia degli eventi di file in una directory specifica. In alternativa, per uno snapshot in tempo, è possibile usare strumenti come Esplora processi o Handle .

Esclusione antivirus

L'analisi antivirus dei file può causare errori di utilizzo di file o cartelle durante una compilazione o una versione e il completamento delle compilazioni potrebbe richiedere più tempo. L'aggiunta di esclusioni antivirus per le directory e i processi dell'agente self-hosted può aiutare a risolvere questi problemi.

Avviso

L'esclusione di file o processi dall'analisi antivirus può rendere il dispositivo o i dati più vulnerabili. Valutare i rischi ed escludere solo i percorsi sicuri.

Processi da escludere:

• Agent.Listener.exe
• Agent.Worker.exe
• AgentService.exe

Directory da escludere (e le relative sottodirectory):

• Directory di installazione dell'agente (ad esempio, C:\agent o /home/user/myagent)
• Cartella di lavoro dell'agente: <agent_directory>\_work
• Cartella di diagnostica dell'agente: <agent_directory>\_diag
• Crea cartelle di output configurate per la tua pipeline, come directory di staging, percorsi di distribuzione degli artefatti e percorsi di pubblicazione dei simboli.
• %ProgramFiles%\Microsoft Visual Studio\<VersionNumber> (Windows)
• C:\Windows\Microsoft.NET\Framework\<VersionNumber>\Temporary ASP.NET Files (Windows)
• C:\Windows\Microsoft.NET\Framework64\<VersionNumber>\Temporary ASP.NET Files (Windows)

Per ulteriori informazioni, vedere esclusioni dalla scansione antivirus.

MSBuild e /nodeReuse:false

Se si richiama MSBuild durante la compilazione, assicurarsi di passare l'argomento /nodeReuse:false (in forma breve /nr:false). In caso contrario, i processi MSBuild continuano a essere in esecuzione al termine della compilazione. I processi rimangono per qualche tempo nell'attesa di un potenziale build successivo.

Questa funzionalità di MSBuild può interferire con i tentativi di eliminare o spostare una directory a causa di un conflitto con la directory di lavoro dei processi MSBuild.

Le attività di MSBuild e Visual Studio Build aggiungono già /nr:false agli argomenti passati a MSBuild. Tuttavia, se si richiama MSBuild dal proprio script, è necessario specificare l'argomento .

MSBuild e /maxcpucount:[n]

Per impostazione predefinita, le attività di compilazione, ad esempio MSBuild e Visual Studio Build eseguire MSBuild con l'opzione /m. In alcuni casi questo può causare problemi, ad esempio problemi di accesso a più file di processo.

Provare ad aggiungere l'argomento /m:1 alle attività di compilazione per forzare MSBuild a eseguire solo un processo alla volta.

Problemi relativi all'uso dei file potrebbero verificarsi quando si utilizza la funzionalità di processi concorrenti di MSBuild. Non specificando l'argomento /maxcpucount:[n] (forma /m:[n]breve) viene indicato a MSBuild di usare solo un singolo processo. Se si utilizzano le attività di build di MSBuild o Visual Studio, potrebbe essere necessario specificare "/m:1" per sovrascrivere l'argomento "/m" aggiunto di default.

Errori intermittenti o incoerenti di MSBuild

Se si verificano errori intermittenti o incoerenti di MSBuild, provare a indicare a MSBuild di usare un solo processo. Errori intermittenti o incoerenti potrebbero indicare che la configurazione di destinazione non è compatibile con la funzionalità di processo simultaneo di MSBuild. Vedere MSBuild e /maxcpucount:[n].

Il processo smette di rispondere

Il processo smette di rispondere alle cause e alla procedura di risoluzione dei problemi:

• In attesa di input
• Dump del processo
• Progetto WiX

In attesa di input

Un processo che smette di rispondere potrebbe indicare che un processo è in attesa di input.

L'esecuzione dell'agente dalla riga di comando durante una sessione interattiva attiva potrebbe aiutare a identificare se un processo richiede l'intervento dell'utente tramite un dialogo.

L'esecuzione dell'agente come servizio può aiutare a eliminare la necessità per i programmi di richiedere un input. Ad esempio, in .NET, i programmi potrebbero basarsi sul booleano System.Environment.UserInteractive per determinare se richiedere o meno. Quando l'agente è in esecuzione come servizio Windows, il valore è false.

Dump del processo

L'analisi di un dump del processo può aiutare a identificare ciò su cui un processo bloccato sta attendendo.

Progetto WiX

La compilazione di un progetto WiX quando sono abilitati logger MSBuild personalizzati può causare il deadlock di WiX in attesa del flusso di output. L'aggiunta dell'argomento MSBuild aggiuntivo /p:RunWixToolsOutOfProc=true consente di risolvere il problema.

Terminazioni di riga per più piattaforme

Quando si eseguono pipeline su più piattaforme, a volte è possibile riscontrare problemi con terminazioni di riga diverse. Storicamente, Linux e macOS usavano i caratteri di avanzamento riga (LF) mentre Windows usava un ritorno a capo insieme a un avanzamento di riga (CRLF). Git tenta di compensare la differenza rendendo automaticamente le righe che terminano in LF nel repo, ma in CRLF nella directory di lavoro su Windows.

La maggior parte degli strumenti di Windows funziona correttamente con le terminazioni LF uniche, e questo comportamento automatico può causare più problemi di quanti ne risolve. Se si verificano problemi in base alle terminazioni di riga, è consigliabile configurare Git per preferire LF ovunque. A tale scopo, aggiungere un .gitattributes file alla radice del repository. In tale file aggiungere la riga seguente:

* text eol=lf

Variabili con l'apostrofo accodato

Se la pipeline include uno script Bash che imposta le variabili usando il ##vso comando , è possibile che venga aggiunto un altro ' al valore della variabile impostata. Ciò si verifica a causa di un'interazione con set -x. La soluzione consiste nel disabilitare temporaneamente set -x prima di impostare una variabile. La sintassi Bash per eseguire questa operazione è set +x.

set +x
echo ##vso[task.setvariable variable=MY_VAR]my_value
set -x

Com'è possibile?

Molti script Bash includono il comando per facilitare il set -x debug. Bash mostra esattamente quale comando è stato eseguito e lo stampa su stdout. In questo modo l'agente visualizzerà il ##vso comando due volte e la seconda volta Bash aggiunse il ' carattere alla fine.

Si consideri ad esempio questa pipeline:

steps:
- bash: |
    set -x
    echo ##vso[task.setvariable variable=MY_VAR]my_value

In stdout l'agente vede due righe:

##vso[task.setvariable variable=MY_VAR]my_value
+ echo '##vso[task.setvariable variable=MY_VAR]my_value'

Quando l'agente vede la prima riga, MY_VAR verrà impostata sul valore corretto, "my_value". Tuttavia, quando incontra la seconda riga, l'agente processa tutto fino alla fine della stessa. MY_VAR è impostato su "my_value'".

Le librerie non sono installate per le applicazioni Python quando lo script viene eseguito.

Quando viene distribuita un'applicazione Python, in alcuni casi viene eseguita una pipeline CI/CD e il codice viene distribuito correttamente, ma il file requirements.txt responsabile dell'installazione di tutte le librerie di dipendenze non viene eseguito.

Per installare le dipendenze, utilizzare uno script post-distribuzione nell'attività di distribuzione di App Service. Nell'esempio seguente viene illustrato il comando che è necessario usare nello script di post-distribuzione. È possibile aggiornare lo script per lo scenario.

D:\home\python364x64\python.exe -m pip install -r requirements.txt

Problemi relativi alla connessione al servizio

Per risolvere i problemi relativi alle connessioni al servizio, vedere Risoluzione dei problemi di connessione al servizio. Per risolvere in modo specifico le connessioni al servizio usando l'identità del carico di lavoro per l'autenticazione, vedere Risolvere i problemi relativi alle connessioni del servizio identità del carico di lavoro.

Pipeline non riceve più segnali dall'agente

Se la pipeline ha esito negativo con un messaggio simile a We stopped hearing from agent <agent name>. Verify the agent machine is running and has a healthy network connection., verificare l'utilizzo delle risorse da parte dell'agente per vedere se il computer dell'agente sta esaurendo le risorse. A partire da Sprint 228, Azure Pipelines i log contengono metriche di utilizzo delle risorse per ogni passaggio.

Quando si usano i servizi di Azure DevOps, è possibile visualizzare l'utilizzo delle risorse nei log, tra cui l'utilizzo del disco, l'utilizzo della memoria e l'utilizzo della CPU, abilitando i log verbose. Al termine della pipeline, cercare nei log voci di registro per Agent environment resources ogni passaggio.

2024-02-28T17:41:15.1315148Z ##[debug]Agent environment resources - Disk: D:\ Available 12342.00 MB out of 14333.00 MB, Memory: Used 1907.00 MB out of 7167.00 MB, CPU: Usage 17.23%

Per informazioni sull'acquisizione di altri log di utilizzo delle risorse, vedere Acquisire i dettagli sull'utilizzo delle risorse.

Abilitare Storage Explorer per distribuire contenuto statico come .css e .js in un sito Web statico da Azure DevOps tramite Azure Pipelines

In questo scenario è possibile usare l'attività Copia file di Azure per caricare il contenuto nel sito Web. È possibile usare uno degli strumenti descritti in Caricamento del contenuto per caricare il contenuto nel contenitore Web.

Usare l'intelligenza artificiale per risolvere i problemi relativi alle esecuzioni della pipeline

Se ci si connette Azure DevOps MCP Server all'agente di intelligenza artificiale in modalità agente, è possibile usare i prompt del linguaggio naturale per analizzare le esecuzioni non riuscite, visualizzare i dettagli del log e suggerire correzioni per i problemi comuni della pipeline.

Task	Richiesta di esempio
Diagnosticare un'esecuzione non riuscita	Get the most recent failed run for the <Contoso-CI> pipeline and summarize the root cause from the logs
Trova i log delle attività non riuscite	Show me the failing task in build <12345> and include the surrounding 50 lines of log output
Confronta con l'ultimo successo	Compare the failing run of <Contoso-CI> with the last successful run and tell me what changed
Analizzare i test instabili	List tests that failed intermittently across the last 10 runs of the <Contoso-CI> pipeline
Analizzare gli errori di autorizzazione	Build <12345> failed with a resource authorization error. Identify which resource needs approval and how to grant it
Analizzare i problemi dell'agente	Check the agent that ran build <12345> for capacity, capability, and connectivity problems
Analizzare i timeout	Find jobs in the <Contoso-CI> pipeline that exceeded their timeout in the past week and show their durations
Individuare schemi di errore comuni	Cluster the failure messages from the last 20 failed runs of <Contoso-CI> and rank the top causes
Suggerire correzioni YAML	Read the failing job in build <12345> and propose a YAML change that resolves the error
Controllare l'integrità della connessione al servizio	List service connections used by <Contoso-CI> and flag any that are expired or about to expire

Annotazioni

La modalità agente e il server MCP usano il linguaggio naturale, quindi è possibile modificare queste richieste o porre domande di completamento per perfezionare i risultati.

Contenuti correlati

• Esaminare i log per individuare altri strumenti di diagnostica.
• Panoramica del server MCP di Azure DevOps
• Esaminare i log per eseguire la diagnostica dei problemi della pipeline
• Azure Pipelines concetti chiave