Note sulla versione Azure DevOps Server 2020

| Developer Community Requisiti | disistema Condizioni di licenza DevOps | Blog | SHA-1 Hashes

In questo articolo sono disponibili informazioni relative alla versione più recente per Azure DevOps Server.

Per altre informazioni sull'installazione o l'aggiornamento di una distribuzione Azure DevOps Server, vedere Requisiti Azure DevOps Server. Per scaricare i prodotti Azure DevOps, visitare la pagina download Azure DevOps Server.

L'aggiornamento diretto a Azure DevOps Server 2020 è supportato da Azure DevOps Server 2019 o Team Foundation Server 2015 o versione successiva. Se la distribuzione TFS è in TFS 2010 o versioni precedenti, è necessario eseguire alcuni passaggi provvisori prima di eseguire l'aggiornamento a Azure DevOps Server 2019. Per altre informazioni, vedere Installare e configurare Azure DevOps in locale.


Aggiornamento sicuro da Azure DevOps Server 2019 a Azure DevOps Server 2020

Azure DevOps Server 2020 introduce un nuovo modello di conservazione di esecuzione della pipeline (build) che funziona in base alle impostazioni a livello di progetto.

Azure DevOps Server 2020 gestisce in modo diverso la conservazione della compilazione, in base ai criteri di conservazione a livello di pipeline. Alcune configurazioni dei criteri comportano l'eliminazione delle esecuzioni della pipeline dopo l'aggiornamento. Le esecuzioni della pipeline mantenute manualmente o mantenute da una versione non verranno eliminate dopo l'aggiornamento.

Per altre informazioni su come eseguire l'aggiornamento sicuro da Azure DevOps Server 2019 a Azure DevOps Server 2020, leggere il post di blog.

data di rilascio Azure DevOps Server 2020.0.2: 17 maggio 2022

Azure DevOps Server 2020.0.2 è un roll up delle correzioni di bug. È possibile installare direttamente Azure DevOps Server 2020.0.2 o eseguire l'aggiornamento da Azure DevOps Server 2020 o Team Foundation Server 2013 o versione successiva.

Nota

Lo strumento di migrazione dei dati sarà disponibile per Azure DevOps Server 2020.0.2 circa tre settimane dopo questa versione. È possibile visualizzare l'elenco delle versioni attualmente supportate per l'importazione qui.

Questa versione include correzioni per quanto segue:

  • Impossibile ignorare la coda di compilazione usando il pulsante "Esegui successivo". In precedenza, il pulsante "Esegui successivo" è stato abilitato solo per gli amministratori della raccolta di progetti.

  • Revocare tutti i token di accesso personale dopo che l'account Active Directory di un utente è disabilitato.

data di rilascio Azure DevOps Server 2020.0.1 Patch 9: 26 gennaio 2022

È stata rilasciata una patch per Azure DevOps Server 2020.0.1 che include correzioni per quanto segue.

  • Email notifiche non sono state inviate quando si usa il @mention controllo in un elemento di lavoro.
  • Correzione dell'errore TF400813 durante l'cambio di account. Questo errore si è verificato quando è stato aggiornato da TFS 2018 a Azure DevOps Server 2020.0.1.
  • Correzione del problema con la pagina di riepilogo panoramica del progetto che non riesce a caricare.
  • Miglioramento della sincronizzazione utente di Active Directory.
  • È stata risolta la vulnerabilità di Elasticsearch rimuovendo la classe jndilookup dai file binari log4j.

Procedura di installazione

  1. Aggiornare il server con patch 9.
  2. Controllare il valore del Registro di sistema in HKLM:\Software\Elasticsearch\Version. Se il valore del Registro di sistema non è presente, aggiungere un valore stringa e impostare la versione su 5.4.1 (Nome = versione, Valore = 5.4.1).
  3. Eseguire il comando PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update di aggiornamento come specificato nel file readme. Potrebbe restituire un avviso come: Impossibile connettersi al server remoto. Non chiudere la finestra, perché l'aggiornamento esegue tentativi fino al completamento.

Nota

Se Azure DevOps Server e Elasticsearch vengono installati in computer diversi, seguire la procedura descritta di seguito.

  1. Aggiornare il server con Patch 9..
  2. Controllare il valore del Registro di sistema in HKLM:\Software\Elasticsearch\Version. Se il valore del Registro di sistema non è presente, aggiungere un valore stringa e impostare la versione su 5.4.1 (Nome = versione, Valore = 5.4.1).
  3. Copiare il contenuto della cartella denominata zip, disponibile nella C:\Program Files\{TFS Version Folder}\Search\zip cartella file remota elasticsearch.
  4. Eseguire Configure-TFSSearch.ps1 -Operation update nel computer del server Elasticsearch.

Hash SHA-256: B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD81545E

Azure DevOps Server 2020.0.1 Data di rilascio patch 8: 15 dicembre 2021

La patch 8 per Azure DevOps Server 2020.0.1 include correzioni per quanto segue.

  • Problema di localizzazione per gli stati di layout degli elementi di lavoro personalizzati.
  • Problema di localizzazione nel modello di notifica tramite posta elettronica.
  • Problema con i log della console che vengono troncati quando sono presenti più collegamenti identici in una riga.
  • Problema con la valutazione delle regole NOTSAMEAS quando sono state definite più regole NOTSAMEAS per un campo.

data di rilascio Azure DevOps Server 2020.0.1 Patch 7: 26 ottobre 2021

La patch 7 per Azure DevOps Server 2020.0.1 include correzioni per quanto segue.

  • In precedenza, Azure DevOps Server potrebbe creare solo connessioni a GitHub Enterprise Server. Con questa patch, gli amministratori del progetto possono creare connessioni tra Azure DevOps Server e repository in GitHub.com. Questa impostazione è disponibile nella pagina Connessioni GitHub in Impostazioni progetto.
  • Risolvere il problema con il widget Piano di test. Il report di esecuzione del test mostrava un utente non corretto nei risultati.
  • Correzione del problema con la pagina di riepilogo panoramica del progetto che non riesce a caricare.
  • Risolvere il problema con i messaggi di posta elettronica non inviati per confermare l'aggiornamento del prodotto.

Azure DevOps Server 2020.0.1 Data di rilascio patch 6: 14 settembre 2021

La patch 6 per Azure DevOps Server 2020.0.1 include correzioni per quanto segue.

  • Correzione dell'errore di download/caricamento degli artefatti.
  • Risolvere il problema con i dati dei risultati dei test incoerenti.

Azure DevOps Server 2020.0.1 Data di rilascio patch 5: 10 agosto 2021

La patch 5 per Azure DevOps Server 2020.0.1 include correzioni per quanto segue.

  • Correzione dell'errore dell'interfaccia utente della definizione di compilazione.
  • Modifica della cronologia di esplorazione per visualizzare i file anziché il repository radice.
  • Risolvere il problema con i processi di recapito tramite posta elettronica per alcuni tipi di elemento di lavoro.

Azure DevOps Server 2020.0.1 Patch 4 Data di rilascio: 15 giugno 2021

La patch 4 per Azure DevOps Server 2020.0.1 include correzioni per quanto segue.

  • Risolvere il problema relativo all'importazione dei dati. L'importazione dei dati richiedeva molto tempo per i clienti che hanno molti test case non aggiornati. Ciò è dovuto ai riferimenti che hanno aumentato le dimensioni della tbl_testCaseReferences tabella. Con questa patch sono stati rimossi riferimenti ai test case non aggiornati per velocizzare il processo di importazione dei dati.

data di rilascio Azure DevOps Server 2020.0.1 Patch 3: 11 maggio 2021

È stata rilasciata una patch per Azure DevOps Server 2020.0.1 che corregge quanto segue.

  • Dati dei risultati dei test incoerenti quando si usa Microsoft.TeamFoundation.TestManagement.Client.

Se si ha Azure DevOps Server 2020.0.1, è necessario installare Azure DevOps Server 2020.0.1 Patch 3.

Verifica dell'installazione

  • Opzione 1: Eseguire devops2020.0.1patch3.exe CheckInstall, devops2020.0.1patch3.exe è il file scaricato dal collegamento precedente. L'output del comando indica che la patch è stata installata o che non è installata.

  • Opzione 2: Controllare la versione del file seguente: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 viene installato per c:\Program Files\Azure DevOps Server 2020 impostazione predefinita. Dopo aver installato Azure DevOps Server 2020.0.1 Patch 3, la versione sarà 18.170.31228.1.

Azure DevOps Server 2020.0.1 Patch 2 Data di rilascio: 13 aprile 2021

Nota

Se si ha Azure DevOps Server 2020, è necessario prima eseguire l'aggiornamento a Azure DevOps Server 2020.0.1 . Una volta eseguita la versione 2020.0.1, installare Azure DevOps Server 2020.0.1 Patch 2

È stata rilasciata una patch per Azure DevOps Server 2020.0.1 che corregge quanto segue.

Per implementare le correzioni per questa patch, è necessario seguire i passaggi elencati di seguito per l'installazione generale delle patch, AzureResourceGroupDeploymentV2 e AzureResourceManagerTemplateDeploymentV3 attività.

Installazione generale delle patch

Se si ha Azure DevOps Server 2020.0.1, è necessario installare Azure DevOps Server 2020.0.1 Patch 2.

Verifica dell'installazione

  • Opzione 1: Eseguire devops2020.0.1patch2.exe CheckInstall, devops2020.0.1patch2.exe è il file scaricato dal collegamento precedente. L'output del comando indica che la patch è stata installata o che non è installata.

  • Opzione 2: Controllare la versione del file seguente: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 viene installato per c:\Program Files\Azure DevOps Server 2020 impostazione predefinita. Dopo aver installato Azure DevOps Server 2020.0.1 Patch 2, la versione sarà 18.170.31123.3.

Installazione dell'attività AzureResourceGroupDeploymentV2

Nota

Tutti i passaggi indicati di seguito devono essere eseguiti in un computer Windows

Installazione

  1. Estrarre il pacchetto AzureResourceGroupDeploymentV2.zip in una nuova cartella nel computer. Ad esempio: D:\tasks\AzureResourceGroupDeploymentV2.

  2. Scaricare e installare Node.js 14.15.1 e npm (incluso nel download di Node.js) in base al computer.

  3. Aprire un prompt dei comandi in modalità amministratore ed eseguire il comando seguente per installare tfx-cli.

npm install -g tfx-cli
  1. Creare un token di accesso personale con privilegi di accesso completo e copiarlo. Questo token di accesso personale verrà usato quando si esegue il comando di accesso tfx .

  2. Eseguire il comando seguente dal prompt dei comandi. Quando richiesto, immettere l'URL del servizio e il token di accesso personale.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

  1. Eseguire il comando seguente per caricare l'attività nel server. Usare il percorso del file estratto .zip dal passaggio 1.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Installazione dell'attività AzureResourceManagerTemplateDeploymentV3

Nota

Tutti i passaggi indicati di seguito devono essere eseguiti in un computer Windows

Installazione

  1. Estrarre il pacchetto AzureResourceManagerTemplateDeploymentV3.zip in una nuova cartella nel computer. Ad esempio:D:\tasks\AzureResourceManagerTemplateDeploymentV3.

  2. Scaricare e installare Node.js 14.15.1 e npm (incluso nel download Node.js) in base alle esigenze del computer.

  3. Aprire un prompt dei comandi in modalità amministratore ed eseguire il comando seguente per installare tfx-cli.

npm install -g tfx-cli
  1. Creare un token di accesso personale con privilegi di accesso completo e copiarlo. Questo token di accesso personale verrà usato quando si esegue il comando di accesso tfx .

  2. Eseguire il comando seguente dal prompt dei comandi. Quando richiesto, immettere l'URL del servizio e il token di accesso personale.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

  1. Eseguire il comando seguente per caricare l'attività nel server. Usare il percorso del file estratto .zip dal passaggio 1.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

data di rilascio Azure DevOps Server 2020.0.1 Patch 1: 9 febbraio 2021

È stata rilasciata una patch per Azure DevOps Server 2020.0.1 che corregge quanto segue. Vedere il post di blog per altre informazioni.

Azure DevOps Server 2020 Patch 3 Data di rilascio: 9 febbraio 2021

È stata rilasciata una patch per Azure DevOps Server 2020 che corregge quanto segue. Vedere il post di blog per altre informazioni.

data di rilascio Azure DevOps Server 2020.0.1: 19 gennaio 2021

Azure DevOps Server 2020.0.1 è un roll up di correzioni di bug. È possibile installare direttamente Azure DevOps Server 2020.0.1 o aggiornare da un'installazione esistente. Le versioni supportate per l'aggiornamento sono Azure DevOps Server 2020, Azure DevOps Server 2019 e Team Foundation Server 2012 o versione successiva.

Questa versione include correzioni per i bug seguenti:

  • Risolvere un problema di aggiornamento da Azure DevOps Server 2019 in cui il proxy Git potrebbe interrompere il funzionamento dopo l'aggiornamento.
  • Correggere l'eccezione System.OutOfMemoryException per le raccolte non ENU precedenti a Team Foundation Server 2017 durante l'aggiornamento a Azure DevOps Server 2020. Risolve il problema segnalato in questo ticket di feedback Developer Community.
  • Errore di manutenzione causato da Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll mancanti. Risolve il problema segnalato in questo ticket di feedback Developer Community.
  • Correggere l'errore di nome colonna non valido in Analytics durante l'aggiornamento a Azure DevOps Server 2020. Risolve il problema segnalato in questo ticket di feedback Developer Community.
  • Stored XSS durante la visualizzazione dei passaggi del test case nei risultati del test case.
  • Errore del passaggio di aggiornamento durante la migrazione dei dati dei punti a TCM.

Azure DevOps Server 2020 Patch 2 Data di rilascio: 12 gennaio 2021

È stata rilasciata una patch per Azure DevOps Server 2020 che corregge quanto segue. Vedere il post di blog per altre informazioni.

  • I dettagli sull'esecuzione dei test non visualizzano i dettagli dei passaggi di test per i dati di cui è stata eseguita la migrazione tramite OpsHub Migration
  • Eccezione sull'inizializzatore per 'Microsoft.TeamFoundation.TestManagement.Server.TCMLogger'
  • Le compilazioni non gestite vengono eliminate immediatamente dopo la migrazione a Azure DevOps Server 2020
  • Correzione dell'eccezione del provider di dati

Azure DevOps Server 2020 Patch 1 Date: 8 dicembre 2020

È stata rilasciata una patch per Azure DevOps Server 2020 che corregge quanto segue. Vedere il post di blog per altre informazioni.

  • CVE-2020-17145: vulnerabilità spoofing Azure DevOps Server e Team Foundation Services

data di rilascio Azure DevOps Server 2020: 6 ottobre 2020

Azure DevOps Server 2020 è un roll up di correzioni di bug. Include tutte le funzionalità del Azure DevOps Server 2020 RC2 rilasciate in precedenza.

Nota

Azure DevOps 2020 Server ha un problema con l'installazione di uno degli assembly usati dal File System virtuale Git (GVFS).

Se si esegue l'aggiornamento da Azure DevOps 2019 (qualsiasi versione) o da un candidato alla versione di Azure DevOps 2020 e l'installazione nella stessa directory della versione precedente, l'assembly Microsoft.TeamFoundation.Git.dll non verrà installato. È possibile verificare che il problema sia stato raggiunto cercando Microsoft.TeamFoundation.Git.dll in <Install Dir>\Version Control Proxy\Web Services\bine <Install Dir>\Application Tier\TFSJobAgent<Install Dir>\Tools cartelle. Se il file è mancante, è possibile eseguire una riparazione per ripristinare i file mancanti.

Per eseguire un ripristino, passare alla Settings -> Apps & Features Azure DevOps Server computer/macchina virtuale ed eseguire un ripristino nel server Azure DevOps 2020. Al termine della riparazione, è possibile riavviare il computer/macchina virtuale.

data di rilascio Azure DevOps Server 2020 RC2: 11 agosto 2020

Azure DevOps Server 2020 RC2 è un roll up di correzioni di bug. Include tutte le funzionalità del Azure DevOps Server 2020 RC1 rilasciate in precedenza.

data di rilascio Azure DevOps Server 2020 RC1: 10 luglio 2020

È stato rilasciato nuovamente Azure DevOps Server 2020 RC1 per correggere questo ticket di feedback Developer Community.

In precedenza, dopo l'aggiornamento da Azure DevOps Server 2019 Update 1.1 a Azure DevOps Server 2020 RC1, non è stato possibile visualizzare i file nel Repos, Pipelines e Wiki dell'interfaccia utente Web. Si è verificato un messaggio di errore che indica che si è verificato un errore imprevisto all'interno di questa area della pagina. È possibile provare a ricaricare questo componente o aggiornare l'intera pagina. Con questa versione è stato risolto questo problema. Vedere il post di blog per altre informazioni.

data di rilascio Azure DevOps Server 2020 RC1: 30 giugno 2020

Riepilogo delle novità di Azure DevOps Server 2020

Azure DevOps Server 2020 introduce molte nuove funzionalità. Tra le caratteristiche principali:

È anche possibile passare a singole sezioni per visualizzare tutte le nuove funzionalità per ogni servizio:


Generale

Disponibilità generale dell'interfaccia della riga di comando di Azure DevOps

A febbraio è stata introdotta l'estensione Azure DevOps per l'interfaccia della riga di comando di Azure. L'estensione consente di interagire con Azure DevOps dalla riga di comando. Abbiamo raccolto il feedback che ci ha aiutato a migliorare l'estensione e aggiungere altri comandi. Ora siamo lieti di annunciare che l'estensione è disponibile a livello generale.

Per altre informazioni sull'interfaccia della riga di comando di Azure DevOps, vedere la documentazione qui.

Usare il profilo di pubblicazione per distribuire App Web di Azure per Windows dal Centro distribuzione

È ora possibile usare l'autenticazione basata sul profilo di pubblicazione per distribuire le app Web di Azure per Windows dal Centro distribuzione. Se si dispone dell'autorizzazione per la distribuzione in un'app Web di Azure per Windows usando il relativo profilo di pubblicazione, sarà possibile configurare la pipeline usando questo profilo nei flussi di lavoro del Centro distribuzione.

Boards

Aggiungere il filtro "Elemento di lavoro padre" alla scheda attività e al backlog sprint

È stato aggiunto un nuovo filtro sia alla scheda Sprint che al backlog Sprint. In questo modo è possibile filtrare gli elementi backlog a livello di requisiti (prima colonna a sinistra) dal relativo padre. Ad esempio, nella schermata seguente è stata filtrata la visualizzazione per visualizzare solo le storie utente in cui l'elemento padre è "La mia grande funzionalità".

Screenshot che mostra il nuovo filtro Elemento di lavoro padre.

Migliorare l'esperienza di gestione degli errori : campi obbligatori in Bug/Attività

Storicamente, dalla scheda Kanban, se si sposta un elemento di lavoro da una colonna a un'altra in cui le regole del campo attivate cambiano lo stato, la scheda visualizzerà solo un messaggio di errore rosso che forzarà l'apertura dell'elemento di lavoro per comprendere la causa radice. In sprint 170 è stata migliorata l'esperienza in modo da poter fare clic sul messaggio di errore rosso per visualizzare i dettagli dell'errore senza dover aprire l'elemento di lavoro stesso.

Screenshot che mostra la finestra di dialogo Campi mancanti visualizzata quando si fa clic sul messaggio di errore rosso.

Ricarica live dell'elemento di lavoro

In precedenza, quando si aggiorna un elemento di lavoro e un secondo membro del team apportava modifiche allo stesso elemento di lavoro, il secondo utente perdeva le modifiche. A questo punto, purché si modificano entrambi campi diversi, verranno visualizzati gli aggiornamenti live delle modifiche apportate all'elemento di lavoro.

Breve video che illustra come funziona il ricaricamento attivo dell'elemento di lavoro.

Gestire iterazioni e percorsi di area dalla riga di comando

È ora possibile gestire le iterazioni e i percorsi di area dalla riga di comando usando i az boards iteration comandi e az boards area . Ad esempio, è possibile configurare e gestire percorsi di iterazione e aree in modo interattivo dall'interfaccia della riga di comando o automatizzare l'intera configurazione usando uno script. Per altre informazioni sui comandi e sulla sintassi, vedere la documentazione qui.

Colonna padre dell'elemento di lavoro come opzione di colonna

A questo punto è possibile visualizzare l'elemento padre di ogni elemento di lavoro nel backlog del prodotto o il backlog sprint. Per abilitare questa funzionalità, passare a Opzioni colonna nel backlog desiderato, quindi aggiungere la colonna Padre .

Screenshot di un backlog con l'opzione Opzioni colonna chiamata.

Modificare il processo usato da un progetto

Gli strumenti devono cambiare man mano che il team esegue, è ora possibile cambiare i progetti da qualsiasi modello di processo out-of-box in qualsiasi altro processo out-of-the-box. Ad esempio, è possibile modificare il progetto usando Agile to Scrum o Basic to Agile. Qui è disponibile la documentazione dettagliata.

Screenshot della scheda Progetti con l'opzione Modifica processo chiamata.

Nascondere i campi personalizzati dal layout

È ora possibile nascondere i campi personalizzati dal layout del modulo durante la personalizzazione del processo. Il campo sarà comunque disponibile dalle query e dalle API REST. Questo è utile per tenere traccia di campi aggiuntivi durante l'integrazione con altri sistemi.

Screenshot che mostra l'opzione Nascondi dal layout.

Ottenere informazioni dettagliate sull'integrità del team con tre nuovi report Azure Boards

Non è possibile correggere ciò che non è possibile vedere. Pertanto, si vuole tenere d'occhio lo stato e l'integrità dei processi di lavoro. Con questi report, è più facile tenere traccia delle metriche importanti con uno sforzo minimo in Azure Boards.

I tre nuovi report interattivi sono: Burndown, Diagramma di flusso cumulativo (CFD) e Velocità. È possibile visualizzare i report nella nuova scheda analisi.

Le metriche come sprint burndown, il flusso di velocità del lavoro e del team offrono visibilità sullo stato di avanzamento del team e consentono di rispondere alle domande, ad esempio:

  • Quanto lavoro abbiamo lasciato in questo sprint? Siamo in pista per completarlo?
  • Quale passaggio del processo di sviluppo richiede più tempo? Possiamo fare qualcosa su di esso?
  • In base alle iterazioni precedenti, quanto lavoro dovremmo pianificare per il prossimo sprint?

Nota

I grafici illustrati in precedenza nelle intestazioni sono stati sostituiti con questi report avanzati.

I nuovi report sono completamente interattivi e consentono di modificarli per le proprie esigenze. È possibile trovare i nuovi report nella scheda Analisi in ogni hub.

  • Il grafico di burndown è disponibile nell'hub Sprints .

    Screenshot del grafico burndown nella scheda Analisi.

  • I report CFD e Velocità possono essere accessibili dalla scheda Analisi in Schede e Backlog facendo clic sulla scheda pertinente.

    Screenshot del report Diagramma flusso cumulativo e del report Velocità nella scheda Analisi.

Con i nuovi report sono disponibili maggiori controlli e informazioni sul team. Di seguito sono riportati alcuni esempi:

  • I report Sprint Burndown e Velocità possono essere impostati per usare il conteggio degli elementi di lavoro o la somma di lavoro rimanenti.
  • È possibile modificare l'intervallo di tempo del burndown sprint senza influire sulle date del progetto. Quindi, se il team spende in genere il primo giorno di ogni pianificazione dello sprint, è ora possibile trovare la corrispondenza con il grafico per riflettere questo.
  • Il grafico Burndown ora presenta una filigrana che mostra i fine settimana.
  • Il report CFD consente di rimuovere colonne della scheda come Design per ottenere maggiore attenzione sul flusso su cui i team hanno il controllo.

Ecco un esempio del report CFD che mostra il flusso per gli ultimi 30 giorni del backlog Storie.

Screenshot del diagramma di flusso cumulativo nella scheda Analisi.

Il grafico Velocità può ora essere monitorato per tutti i livelli di backlog. Ad esempio, è ora possibile aggiungere funzionalità e epiche, mentre prima del grafico precedente sono supportati solo i requisiti. Ecco un esempio di report sulla velocità per le ultime 6 iterazioni del backlog Funzionalità.

Screenshot del grafico Velocità nella scheda Analisi.

Personalizzare le colonne di Taskboard

Siamo lieti di annunciare che è stata aggiunta un'opzione per personalizzare le colonne nella scheda attività. È ora possibile aggiungere, rimuovere, rinominare e riordinare le colonne.

Per configurare le colonne nella scheda attività, passare a Opzioni colonna.

Screenshot di una scheda attività con l'opzione Opzioni colonna chiamata.

Questa funzionalità è stata prioritaria in base a un suggerimento del Developer Community.

Disattiva per visualizzare o nascondere gli elementi di lavoro figlio completati nel backlog

Molte volte, quando si affina il backlog, si vogliono visualizzare solo gli elementi che non sono stati completati. A questo momento, è possibile visualizzare o nascondere gli elementi figlio completati nel backlog.

Se l'interruttore è attivo, verranno visualizzati tutti gli elementi figlio in uno stato completato. Quando l'interruttore è disattivato, tutti gli elementi figlio in uno stato completato verranno nascosti dal backlog.

Breve video che mostra come mostrare o nascondere elementi figlio sul backlog.

Tag più recenti visualizzati durante l'assegnazione di tag a un elemento di lavoro

Quando si contrassegna un elemento di lavoro, l'opzione completa automaticamente verrà ora visualizzata fino a cinque dei tag usati più di recente. In questo modo sarà più facile aggiungere le informazioni corrette agli elementi di lavoro.

Screenshot che mostra i tag usati più recenti visualizzati durante l'assegnazione di tag a un elemento di lavoro.

Regole di sola lettura e necessarie per l'appartenenza al gruppo

Le regole dell'elemento di lavoro consentono di impostare azioni specifiche sui campi dell'elemento di lavoro per automatizzare il comportamento. È possibile creare una regola per impostare un campo su sola lettura o obbligatorio in base all'appartenenza al gruppo. Ad esempio, è possibile concedere ai proprietari dei prodotti la possibilità di impostare la priorità delle funzionalità, rendendo invece di sola lettura per tutti gli altri utenti.

Screenshot della finestra di dialogo Nuova regola elemento di lavoro che mostra la sezione Condizioni e la sezione Azioni.

Personalizzare i valori di selezione del sistema

È ora possibile personalizzare i valori per qualsiasi elenco di selezione di sistema (ad eccezione del campo motivo), ad esempio Gravità, Attività, Priorità e così via. Le personalizzazioni dell'elenco di selezione sono con ambito in modo che sia possibile gestire valori diversi per lo stesso campo per ogni tipo di elemento di lavoro.

Breve video che illustra come personalizzare i valori di selezione del sistema.

Nuovo parametro URL elemento di lavoro

Condividere i collegamenti agli elementi di lavoro con il contesto della scheda o del backlog con il nuovo parametro URL dell'elemento di lavoro. È ora possibile aprire una finestra di dialogo dell'elemento di lavoro sulla scheda, sul backlog o sull'esperienza sprint aggiungendo il parametro ?workitem=[ID] all'URL.

Chiunque condividi il collegamento con verrà quindi suolo con lo stesso contesto che hai avuto quando hai condiviso il collegamento!

Indicare persone, elementi di lavoro e PR nei campi di testo

Come abbiamo ascoltato il feedback, abbiamo sentito che hai voluto parlare di persone, elementi di lavoro e PR nell'area di descrizione dell'elemento di lavoro (e altri campi HTML) nell'elemento di lavoro e non solo nei commenti. A volte si sta collaborando con un utente in un elemento di lavoro o si vuole evidenziare una richiesta di richiesta nella descrizione dell'elemento di lavoro, ma non è stato possibile aggiungere tali informazioni. Ora è possibile menzionare persone, elementi di lavoro e PR in tutti i campi di testo lunghi nell'elemento di lavoro.

È possibile visualizzare un esempio qui.

Screenshot che mostra che è possibile menzionare persone, elementi di lavoro e PR nell'area Descrizione elemento di lavoro.

  • Per usare le menzioni delle persone, digitare il segno e il @ nome della persona che si vuole menzionare. @mentions nei campi dell'elemento di lavoro genereranno notifiche tramite posta elettronica, ad esempio ciò che fa per i commenti.
  • Per usare le menzioni dell'elemento di lavoro, digitare il segno seguito dall'ID # dell'elemento di lavoro o dal titolo. #mentions creerà un collegamento tra i due elementi di lavoro.
  • Per usare le menzioni pr, aggiungere un oggetto ! seguito dall'ID richiesta o dal nome.

Reazioni sui commenti di discussione

Uno degli obiettivi principali è quello di rendere gli elementi di lavoro più collaborativi per i team. Recentemente abbiamo condotto un sondaggio su Twitter per scoprire quali funzionalità di collaborazione vuoi nelle discussioni sull'elemento di lavoro. Portando reazioni ai commenti ha vinto il sondaggio, quindi li aggiungiamo! Ecco i risultati del sondaggio di Twitter.

Screenshot del sondaggio twitter di Azure DevOps che mostra che il 35% degli intervistati ha voluto che le reazioni sulle funzionalità dei commenti.

È possibile aggiungere reazioni a qualsiasi commento e sono disponibili due modi per aggiungere le tue reazioni, ovvero l'icona sorridente nell'angolo superiore destro di qualsiasi commento, nonché nella parte inferiore di un commento accanto a eventuali reazioni esistenti. Puoi aggiungere tutte e sei le reazioni se vuoi, o solo una o due. Per rimuovere la reazione, fare clic sulla reazione nella parte inferiore del commento e verrà rimossa. Di seguito è possibile vedere l'esperienza dell'aggiunta di una reazione, oltre a ciò che le reazioni sembrano su un commento.

Screenshot che mostra che è possibile aggiungere reazioni ai commenti in due modi diversi.

Aggiungere report Azure Boards al dashboard

Nell'aggiornamento sprint 155 sono state incluse le versioni aggiornate dei report CFD e Velocity. Questi report sono disponibili nella scheda Analisi di Schede e Backlog. È ora possibile aggiungere i report direttamente al dashboard. Per aggiungere i report, passare il puntatore del mouse sul report, selezionare i puntini di sospensione "..." menu e Copia nel dashboard.

Screenshot che mostra l'opzione Copia nel dashboard.

Tenere traccia dello stato di avanzamento degli elementi padre usando rollup nel backlog di Boards

Le colonne di rollup mostrano barre di stato e/o totali di campi numerici o elementi discendenti all'interno di una gerarchia. Gli elementi discendenti corrispondono a tutti gli elementi figlio all'interno della gerarchia. Una o più colonne di rollup possono essere aggiunte a un backlog di prodotto o portfolio.

Qui, ad esempio, viene illustrato Lo stato di avanzamento degli elementi di lavoro che visualizza le barre di stato per gli elementi di lavoro crescente in base alla percentuale di elementi discendenti chiusi. Gli elementi discendenti per Epics includono tutte le funzionalità figlio e gli elementi di lavoro figlio o figlio. Gli elementi discendenti per Funzionalità includono tutte le storie utente figlio e gli elementi di lavoro figlio.

Screenshot degli elementi di lavoro in un backlog.

Aggiornamenti live di Taskboard

La scheda attività viene ora aggiornata automaticamente quando si verificano modifiche. Mentre altri membri del team spostano o riordinano le schede nella scheda attività, la scheda aggiornerà automaticamente con queste modifiche. Non è più necessario premere F5 per visualizzare le modifiche più recenti.

Supporto per i campi personalizzati nelle colonne rollup

È ora possibile eseguire l'rollup in qualsiasi campo, inclusi i campi personalizzati. Quando si aggiunge una colonna Rollup, è comunque possibile selezionare una colonna Rollup dall'elenco Rapido, tuttavia, se si vuole eseguire l'rollup nei campi numerici che non fanno parte del modello di processo out of the box, è possibile configurare il proprio come segue:

  1. Nel backlog fare clic su "Opzioni di colonna". Nel pannello fare quindi clic su "Aggiungi colonna rollup" e Configurare l'rollup personalizzato.

    Screenshot dell'elenco a discesa Aggiungi colonna cumulativa.

  2. Scegliere tra barra di stato e Totale.
  3. Selezionare un tipo di elemento di lavoro o un livello Backlog (in genere i backlog aggregano diversi tipi di elemento di lavoro).
  4. Selezionare il tipo di aggregazione. Numero di elementi di lavoro o Sum. Per Sum è necessario selezionare il campo da riepilogare.
  5. Il pulsante OK consente di tornare al pannello delle opzioni di colonna in cui è possibile riordinare la nuova colonna personalizzata.

Screenshot del pannello delle opzioni di colonna che mostra la nuova colonna personalizzata.

Si noti che non è possibile modificare la colonna personalizzata dopo aver fatto clic su OK. Se è necessario apportare una modifica, rimuovere la colonna personalizzata e aggiungere un'altra come desiderato.

Nuova regola per nascondere i campi in un modulo dell'elemento di lavoro in base alla condizione

È stata aggiunta una nuova regola al motore regole ereditate per consentire di nascondere i campi in un modulo dell'elemento di lavoro. Questa regola nasconde i campi in base all'appartenenza al gruppo di utenti. Ad esempio, se l'utente appartiene al gruppo "proprietario del prodotto", è possibile nascondere un campo specifico per sviluppatori. Per altre informazioni, vedere la documentazione qui.

Impostazioni di notifica degli elementi di lavoro personalizzate

Rimanere aggiornati sugli elementi di lavoro rilevanti per l'utente o il team è incredibilmente importante. Aiuta i team a collaborare e rimanere traccia dei progetti e assicura che tutte le parti giuste siano coinvolte. Tuttavia, diversi stakeholder hanno diversi livelli di investimento in diversi sforzi, e riteniamo che sia necessario riflettere nella capacità di seguire lo stato di un elemento di lavoro.

In precedenza, se si vuole seguire un elemento di lavoro e ottenere notifiche su tutte le modifiche apportate, si otterrebbero notifiche di posta elettronica per qualsiasi e tutte le modifiche apportate all'elemento di lavoro. Dopo aver preso in considerazione il feedback, stiamo facendo seguito un elemento di lavoro più flessibile per tutti gli stakeholder. A questo punto, verrà visualizzato un nuovo pulsante impostazioni accanto al pulsante Segui nell'angolo superiore destro dell'elemento di lavoro. Verrà visualizzata una finestra popup che consente di configurare le opzioni seguenti.

Screenshot dell'angolo in alto a destra di un elemento di lavoro con il puntatore del mouse sull'icona a forma di ingranaggio.

In Impostazioni di notifica è possibile scegliere tra tre opzioni di notifica. Prima di tutto, puoi essere completamente annullata. In secondo luogo, è possibile essere completamente sottoscritti, in cui si ottengono notifiche per tutte le modifiche all'elemento di lavoro. Infine, è possibile scegliere di ricevere una notifica per alcuni degli eventi di modifica principali e cruciali dell'elemento di lavoro. È possibile selezionare solo una o tutte e tre le opzioni. In questo modo i membri del team seguono gli elementi di lavoro a un livello superiore e non vengono distratti da ogni singola modifica apportata. Con questa funzionalità, elimineremo i messaggi di posta elettronica non necessari e ti consentiranno di concentrarsi sulle attività cruciali a mano.

Screenshot della finestra di dialogo Impostazioni notifiche che mostra il pulsante di opzione Personalizzato selezionato insieme all'opzione Stato modificato e all'opzione Iterazione modificata.

È entusiasta di rilasciare il controllo Distribuzione nel modulo dell'elemento di lavoro. Questo controllo collega gli elementi di lavoro a una versione e consente di tenere traccia facilmente della posizione in cui è stato distribuito l'elemento di lavoro. Per altre informazioni, vedere la documentazione qui.

Screenshot che mostra il controllo Distribuzione nel modulo dell'elemento di lavoro.

Importare elementi di lavoro da un file CSV

Fino a questo momento, l'importazione di elementi di lavoro da un file CSV dipende dall'uso del plug-in di Excel. In questo aggiornamento viene fornita un'esperienza di importazione di prima classe direttamente da Azure Boards in modo da poter importare elementi di lavoro nuovi o aggiornare gli elementi di lavoro esistenti. Per altre informazioni, vedere la documentazione qui.

Breve video che illustra come importare elementi di lavoro da un file CSV.

Aggiungere il campo padre alle schede dell'elemento di lavoro

Il contesto padre è ora disponibile nella scheda Kanban come nuovo campo per le schede dell'elemento di lavoro. È ora possibile aggiungere il campo Padre alle schede, ignorando la necessità di usare soluzioni alternative, ad esempio tag e prefissi.

Screenshot che mostra una scheda elemento di lavoro con l'opzione Padre chiamata.

Aggiungere il campo padre al backlog e alle query

Il campo padre è ora disponibile quando si visualizzano i backlog e i risultati delle query. Per aggiungere il campo padre, usare la visualizzazione Opzioni colonna .

Screenshot della sezione Opzioni colonna con l'opzione Padre chiamata.

Repos

Metriche di code coverage e criteri di ramo per le richieste pull

È ora possibile visualizzare le metriche di code coverage per le modifiche all'interno della visualizzazione richiesta pull (PR). Ciò garantisce che le modifiche siano state testate in modo adeguato tramite test automatizzati. Lo stato della copertura verrà visualizzato come commento nella panoramica della richiesta di richiesta. È possibile visualizzare i dettagli delle informazioni di copertura per ogni riga di codice modificata nella visualizzazione diff del file.

Screenshot che mostra che è possibile visualizzare le metriche di code coverage per le modifiche all'interno della visualizzazione richiesta pull (PR).

Screenshot di una richiesta pull diff che mostra una nuova riga di codice aggiunta a un file.

Inoltre, i proprietari del repository possono ora impostare i criteri di code coverage e impedire l'unione di modifiche di grandi dimensioni e non sottoposte a test in un ramo. Le soglie di copertura desiderate possono essere definite in un file di impostazioni archiviato nella radice del repository e dei criteri di copertura possono essere definiti usando la configurazione esistente di un azurepipelines-coverage.ymlcriterio di ramo per funzionalità di servizi aggiuntivi in Azure Repos.

Screenshot dell'opzione Aggiungi criteri di stato denominata e la sezione Aggiungi criteri di stato visualizzata quando si seleziona l'opzione..

Filtrare le notifiche di commento dalle richieste pull

I commenti nelle richieste pull possono spesso generare un sacco di rumore a causa delle notifiche. È stata aggiunta una sottoscrizione personalizzata che consente di filtrare le notifiche di commento che si sottoscrivono in base all'età dei commenti, al commento, ai commenti eliminati, agli utenti menzionati, all'autore della richiesta pull, al ramo di destinazione e ai partecipanti al thread. È possibile creare queste sottoscrizioni di notifica facendo clic sull'icona utente nell'angolo superiore destro e passando a Impostazioni utente.

Screenshot che mostra come filtrare le notifiche di commento dalle richieste pull.

Screenshot che mostra la pagina Criteri di filtro e il contenuto dell'elenco a discesa Campo.

Hook di servizio per i commenti delle richieste pull

È ora possibile creare hook di servizio per i commenti in una richiesta pull in base al repository e al ramo di destinazione.

Screenshot della procedura guidata New Service Hooks Subscription (Nuova sottoscrizione di Hook del servizio).

Criteri per bloccare i file con modelli specificati

Gli amministratori possono ora impostare un criterio per impedire il push dei commit in un repository in base ai tipi di file e ai percorsi. I criteri di convalida del nome file bloccano i push corrispondenti al modello specificato.

Screenshot che mostra la sezione Criteri con l'opzione Di convalida nome file impostata su Attiva.

Risolvere gli elementi di lavoro tramite commit usando parole chiave

È ora possibile risolvere gli elementi di lavoro tramite commit eseguiti nel ramo predefinito usando parole chiave come correzione, correzioni o correzioni. Ad esempio, è possibile scrivere : "questa modifica è stata fissa #476" nel messaggio di commit e nell'elemento di lavoro #476 verrà completata quando il commit viene eseguito il push o l'unione nel ramo predefinito. Per altre informazioni, vedere la documentazione qui.

Granularità per i revisori automatici

In precedenza, quando si aggiungono revisori a livello di gruppo a una richiesta pull, è stata necessaria un'approvazione solo dal gruppo aggiunto. È ora possibile impostare criteri che richiedono più revisori da un team per approvare una richiesta pull quando si aggiungono revisori automatici. È inoltre possibile aggiungere un criterio per impedire ai richiedenti di approvare le proprie modifiche.

Screenshot che mostra la finestra di dialogo Includi automaticamente revisori.

Usare l'autenticazione basata su account del servizio per connettersi al servizio Azure Kubernetes

In precedenza, durante la configurazione di Azure Pipelines dal Centro distribuzione del servizio Azure Kubernetes, è stata usata una connessione di Azure Resource Manager. Questa connessione ha avuto accesso all'intero cluster e non solo allo spazio dei nomi per cui è stata configurata la pipeline. Con questo aggiornamento, le pipeline useranno l'autenticazione basata su account del servizio per connettersi al cluster in modo che abbia accesso solo allo spazio dei nomi associato alla pipeline.

Anteprima dei file markdown nella richiesta pull diff side-by-side

È ora possibile visualizzare un'anteprima di come verrà visualizzato un file markdown usando il nuovo pulsante Anteprima . Inoltre, è possibile visualizzare il contenuto completo di un file dalla diff side-by-side selezionando il pulsante Visualizza .

Screenshot che mostra un file markdown in un progetto con le opzioni Visualizza e Anteprima chiamate.

Scadenza dei criteri di compilazione per le compilazioni manuali

I criteri applicano gli standard di qualità del codice e di gestione delle modifiche del team. In precedenza, è possibile impostare criteri di scadenza per le compilazioni automatizzate. È ora possibile impostare i criteri di scadenza della compilazione per le compilazioni manuali.

Screenshot della finestra di dialogo Aggiungi criteri di compilazione con la sezione Scadenza compilazione.

Aggiungere un criterio per bloccare i commit in base al messaggio di posta elettronica dell'autore del commit

Gli amministratori possono ora impostare un criterio push per impedire il push dei commit in un repository per il quale il messaggio di posta elettronica dell'autore del commit non corrisponde al modello specificato.

Screenshot che mostra Criteri per tutti i repository Git nella scheda Criteri con l'opzione Di convalida della posta elettronica dell'autore commit impostata su Sì.

Questa funzionalità è stata prioritaria in base a un suggerimento del Developer Community per offrire un'esperienza simile. Continuerà a mantenere aperto il ticket e incoraggiare gli utenti a indicare quali altri tipi di criteri push si desidera visualizzare.

Contrassegnare i file come esaminati in una richiesta pull

A volte, è necessario esaminare le richieste pull che contengono modifiche a un numero elevato di file e può essere difficile tenere traccia dei file già esaminati. Ora è possibile contrassegnare i file come esaminati in una richiesta pull.

È possibile contrassegnare un file come esaminato usando il menu a discesa accanto a un nome file o facendo clic sul nome del file.

Nota

Questa funzionalità è destinata solo a tenere traccia dello stato di avanzamento durante la revisione di una richiesta pull. Non rappresenta il voto sulle richieste pull, pertanto questi contrassegni saranno visibili solo al revisore.

Screenshot che mostra un progetto con la visualizzazione in Esplora file e Contrassegna come opzioni esaminate visibili.

Questa funzionalità è stata prioritaria in base a un suggerimento del Developer Community.

Nuova interfaccia utente Web per le pagine di destinazione Azure Repos

È ora possibile provare le nuove pagine di destinazione moderne, veloci e per dispositivi mobili all'interno di Azure Repos. Queste pagine sono disponibili come pagine di destinazione New Repos. Le pagine di destinazione includono tutte le pagine, ad eccezione dei dettagli della richiesta pull, dei dettagli del commit e del confronto tra rami.

Web

Screenshot della nuova interfaccia utente Web per Azure Repos pagine di destinazione.

Dispositivi mobili

Screenshot della nuova interfaccia utente per dispositivi mobili per Azure Repos pagine di destinazione.

Amministrazione dei criteri di ramo tra repository

I criteri di ramo sono una delle potenti funzionalità di Azure Repos che consentono di proteggere rami importanti. Anche se la possibilità di impostare i criteri a livello di progetto esiste nell'API REST, non esiste alcuna interfaccia utente. A questo punto, gli amministratori possono impostare criteri in un ramo specifico o nel ramo predefinito in tutti i repository nel progetto. Ad esempio, un amministratore potrebbe richiedere due revisori minimi per tutte le richieste pull effettuate in ogni ramo principale in ogni repository nel progetto. È possibile trovare la funzionalità Aggiungi protezione ramo nelle impostazioni del progetto Repos.

Screenshot della finestra di dialogo Aggiungi protezione ramo.

Nuove pagine di destinazione della piattaforma Web

L'esperienza utente delle pagine di destinazione repos è stata aggiornata per renderla moderna, veloce e semplice per dispositivi mobili. Ecco due esempi delle pagine aggiornate, continueremo ad aggiornare altre pagine negli aggiornamenti futuri.

Esperienza Web:

Screenshot delle pagine di destinazione della piattaforma Web.

Esperienza per dispositivi mobili:

Screenshot della pagina File di conversione della piattaforma mobile.

Screenshot della pagina Commit di conversione della piattaforma mobile.

Supporto per il linguaggio Kotlin

Siamo lieti di annunciare che ora supportiamo l'evidenziazione del linguaggio Kotlin nell'editor di file. L'evidenziazione migliora la leggibilità del file di testo Kotlin e consente di analizzare rapidamente gli errori. Questa funzionalità è stata prioritaria in base a un suggerimento del Developer Community.

Screenshot di un file Kotlin visualizzato nell'interfaccia utente.

Sottoscrizione di notifica personalizzata per le richieste pull bozza

Per ridurre il numero di notifiche di posta elettronica da richieste pull, è ora possibile creare una sottoscrizione di notifica personalizzata per le richieste pull create o aggiornate nello stato bozza. È possibile ricevere messaggi di posta elettronica in particolare per le richieste pull bozza o filtrare i messaggi di posta elettronica dalle richieste pull bozza, in modo che il team non riceva una notifica prima che la richiesta pull sia pronta per essere esaminata.

Screenshot della finestra di dialogo Nuova sottoscrizione che mostra che Bozza è stata aggiunta come opzione alla funzionalità Criteri di filtro.

Miglioramento dell'azione pr

Quando si hanno molte richieste pull da esaminare, è possibile capire dove eseguire prima di tutto l'azione. Per migliorare l'azione delle richieste pull, è ora possibile creare più query personalizzate nella pagina dell'elenco delle richieste pull con diverse nuove opzioni da filtrare, ad esempio lo stato bozza. Queste query creeranno sezioni separate e collapible nella pagina delle richieste pull oltre a "Create by me" e "Assigned to me". È anche possibile rifiutare di esaminare una richiesta pull aggiunta tramite il menu Vote o il menu di scelta rapida nella pagina dell'elenco delle richieste pull. Nelle sezioni personalizzate verranno ora visualizzate schede separate per le richieste pull su cui è stata fornita o rifiutata la revisione. Queste query personalizzate funzioneranno tra repository nella scheda "Richieste pull personali" della home page della raccolta. Se si vuole tornare a una richiesta pull, è possibile contrassegnarlo e verrà visualizzato nella parte superiore dell'elenco. Infine, le richieste pull impostate sul completamento automatico verranno contrassegnate con una pillola che indica "Completamento automatico" nell'elenco.

Pipelines

Pipeline in più fasi

Stiamo lavorando a un'esperienza utente aggiornata per gestire le pipeline. Questi aggiornamenti rendono le pipeline moderne e coerenti con la direzione di Azure DevOps. Inoltre, questi aggiornamenti riuniscono pipeline di compilazione classiche e pipeline YAML a più fasi in un'unica esperienza. È semplice per dispositivi mobili e offre vari miglioramenti alla gestione delle pipeline. È possibile eseguire il drill-down e visualizzare i dettagli della pipeline, i dettagli dell'esecuzione, l'analisi della pipeline, i dettagli del processo, i log e altro ancora.

Le funzionalità seguenti sono incluse nella nuova esperienza:

  • visualizzazione e gestione di più fasi
  • approvazione delle esecuzioni della pipeline
  • scorrere fino all'indietro nei log mentre è ancora in corso una pipeline
  • Integrità per ramo di una pipeline.

Distribuzione continua in YAML

Microsoft è lieta di fornire funzionalità CD YAML di Azure Pipelines. È ora disponibile un'esperienza YAML unificata in modo da poter configurare ognuna delle pipeline in modo da eseguire l'integrazione continua, la distribuzione continua o l'integrazione continua e la distribuzione continua. Le funzionalità CD YAML introducono diverse nuove funzionalità avanzate disponibili per tutte le raccolte che usano pipeline YAML a più fasi. Tra le caratteristiche principali:

Se si è pronti per iniziare la compilazione, vedere la documentazione o il blog per la creazione di pipeline CI/CD a più fasi.

Gestire le variabili della pipeline nell'editor YAML

È stata aggiornata l'esperienza per la gestione delle variabili della pipeline nell'editor YAML. Non è più necessario passare all'editor classico per aggiungere o aggiornare variabili nelle pipeline YAML.

Screenshot che mostra la finestra di dialogo Variabili.

Approvare le versioni direttamente dall'hub Delle versioni

L'azione sulle approvazioni in sospeso è stata resa più semplice. In precedenza era possibile approvare una versione dalla pagina dei dettagli della versione. È ora possibile approvare le versioni direttamente dall'hub Delle versioni.

Screenshot che mostra come approvare le versioni direttamente dall'hub di rilascio.

Integrazione di Bitbucket e altri miglioramenti per iniziare a usare le pipeline

L'esperienza guidata introduttiva per Pipelines è stata aggiornata per funzionare con i repository Bitbucket. Azure Pipelines analizzerà ora il contenuto del repository Bitbucket e consiglierà un modello YAML per iniziare.

Una richiesta comune con la procedura guidata introduttiva è stata la possibilità di rinominare il file generato. Attualmente, viene archiviato come azure-pipelines.yml nella radice del repository. È ora possibile aggiornare il file in un percorso o un nome file diverso prima di salvare la pipeline.

Infine, si avrà più controllo quando si archivia il azure-pipelines.yml file in un ramo diverso perché è possibile scegliere di ignorare la creazione di una richiesta pull da tale ramo.

Anteprima del documento YAML completamente analizzato senza eseguire il commit o l'esecuzione della pipeline

È stata aggiunta un'anteprima ma non è stata eseguita la modalità per le pipeline YAML. È ora possibile provare una pipeline YAML senza eseguirne il commit in un repository o eseguirlo. Data una pipeline esistente e un nuovo payload YAML facoltativo, questa nuova API restituirà la pipeline YAML completa. Negli aggiornamenti futuri questa API verrà usata in una nuova funzionalità dell'editor.

Per gli sviluppatori: POST a con un corpo JSON simile al dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview seguente:

{
  "PreviewRun": true,
  "YamlOverride": "
# your new YAML here, optionally
"
}

La risposta conterrà il codice YAML sottoposto a rendering.

Pianificazioni Cron in YAML

In precedenza, è possibile usare l'editor dell'interfaccia utente per specificare un trigger pianificato per le pipeline YAML. Con questa versione è possibile pianificare le compilazioni usando la sintassi cron nel file YAML e sfruttare i vantaggi seguenti:

  1. Configurazione come codice: è possibile tenere traccia delle pianificazioni insieme alla pipeline come parte del codice.
  2. Espressivo: si dispone di una potenza più espressiva nella definizione di pianificazioni rispetto a quelle che è stato possibile usare con l'interfaccia utente. Ad esempio, è più semplice specificare una singola pianificazione che avvia un'esecuzione ogni ora.
  3. Standard del settore: molti sviluppatori e amministratori hanno già familiarità con la sintassi cron.
schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

Abbiamo anche reso più semplice diagnosticare i problemi con le pianificazioni cron. Le esecuzioni pianificate nel menu Esegui pipeline offrono un'anteprima delle prossime esecuzioni pianificate per la pipeline per diagnosticare gli errori con le pianificazioni cron.

Screenshot che mostra il menu Esegui pipeline con l'opzione Esecuzioni pianificate evidenziata.

Aggiornamenti all'interfaccia utente delle connessioni al servizio

Microsoft sta lavorando a un'esperienza utente aggiornata per gestire le connessioni al servizio. Questi aggiornamenti rendono l'esperienza di connessione del servizio moderna e coerente con la direzione di Azure DevOps. Abbiamo introdotto la nuova interfaccia utente per le connessioni al servizio come funzionalità di anteprima all'inizio di quest'anno. Grazie a tutti coloro che hanno provato la nuova esperienza e hanno fornito il loro prezioso feedback a noi.

Screenshot della finestra di dialogo Nuova connessione al servizio.

Oltre all'aggiornamento dell'esperienza utente, sono state aggiunte anche due funzionalità fondamentali per l'utilizzo delle connessioni al servizio nelle pipeline YAML: autorizzazioni e approvazioni e controlli della pipeline.

Screenshot che mostra il menu Modifica in una pipeline YAML con l'opzione Approvazioni e controlli visibile.

La nuova esperienza utente verrà attivata per impostazione predefinita con questo aggiornamento. Sarà comunque possibile rifiutare esplicitamente l'anteprima.

Nota

Si prevede di introdurre condivisione tra progetti di connessioni al servizio come nuova funzionalità. Altre informazioni sull'esperienza di condivisione e sui ruoli di sicurezza sono disponibili qui.

Ignorare le fasi in una pipeline YAML

Quando si avvia un'esecuzione manuale, a volte è possibile ignorare alcune fasi della pipeline. Ad esempio, se non si vuole eseguire la distribuzione nell'ambiente di produzione o se si vuole ignorare la distribuzione in alcuni ambienti nell'ambiente di produzione. È ora possibile eseguire questa operazione con le pipeline YAML.

Il pannello della pipeline di esecuzione aggiornato presenta un elenco di fasi dal file YAML e si ha la possibilità di ignorare una o più di queste fasi. È necessario prestare attenzione quando si ignorano le fasi. Ad esempio, se la prima fase produce alcuni artefatti necessari per le fasi successive, non è consigliabile ignorare la prima fase. Il pannello di esecuzione visualizza un avviso generico ogni volta che si ignorano le fasi con dipendenze downstream. È necessario stabilire se tali dipendenze sono vere dipendenze degli artefatti o se sono presenti solo per la sequenziazione delle distribuzioni.

Screenshot che mostra la sezione Esegui pipeline con l'opzione Fasi per l'esecuzione evidenziata.

Ignorare una fase equivale a riwiring le dipendenze tra le fasi. Tutte le dipendenze downstream immediate della fase ignorata vengono effettuate in base all'elemento padre upstream della fase ignorata. Se l'esecuzione ha esito negativo e se si tenta di rieseguire una fase non riuscita, tale tentativo avrà anche lo stesso comportamento di salto. Per modificare le fasi ignorate, è necessario avviare una nuova esecuzione.

Screenshot che mostra la sezione Fasi da eseguire con l'opzione di sviluppo e l'opzione di distribuzione selezionata.

Connessioni al servizio nuova interfaccia utente come esperienza predefinita

È disponibile una nuova interfaccia utente per le connessioni al servizio. Questa nuova interfaccia utente è basata su standard di progettazione moderni e include varie funzionalità critiche per supportare pipeline CD YAML a più fasi, ad esempio approvazioni, autorizzazioni e condivisione tra progetti.

Screenshot della finestra di dialogo Esegui pipeline.

Altre informazioni sulle connessioni al servizio sono disponibili qui.

Selezione della versione della risorsa pipeline nella finestra di dialogo Crea esecuzione

È stata aggiunta la possibilità di raccogliere manualmente le versioni delle risorse della pipeline nella finestra di dialogo crea esecuzione. Se si usa una pipeline come risorsa in un'altra pipeline, è ora possibile selezionare la versione di tale pipeline durante la creazione di un'esecuzione.

Screenshot della finestra di dialogo Fasi da eseguire.

az Miglioramenti dell'interfaccia della riga di comando per Azure Pipelines

Comandi di gestione delle variabili della pipeline e gruppi di variabili

Può essere difficile convertire le pipeline basate su YAML da un progetto a un altro perché è necessario configurare manualmente le variabili della pipeline e i gruppi di variabili. Tuttavia, con i comandi di gestione delle variabili della pipeline e del gruppo di variabili, è ora possibile creare uno script per la configurazione e la gestione delle variabili e dei gruppi di variabili che possono essere a loro volta controllati dalla versione, consentendo di condividere facilmente le istruzioni per spostare e configurare pipeline da un progetto a un altro.

Eseguire la pipeline per un ramo PR

Quando si crea una richiesta di richiesta di richiesta, è difficile convalidare se le modifiche potrebbero interrompere l'esecuzione della pipeline nel ramo di destinazione. Tuttavia, con la funzionalità per attivare un'esecuzione della pipeline o una coda di una compilazione per un ramo PR, è ora possibile convalidare e visualizzare le modifiche in corso eseguendola sulla pipeline di destinazione. Per altre informazioni, vedere az pipelines runs run and az pipelines build queue command documentation (Az pipelines run and az pipelines build queue command documentation).

Ignorare la prima esecuzione della pipeline

Quando si creano pipeline, a volte si vuole creare e eseguire il commit di un file YAML e non attivare l'esecuzione della pipeline perché può causare un'esecuzione non riuscita a causa di un'ampia gamma di motivi: l'infrastruttura non è pronta o deve creare e aggiornare gruppi di variabili/variabili e così via. Con l'interfaccia della riga di comando di Azure DevOps, è ora possibile ignorare la prima esecuzione automatica della pipeline creando una pipeline includendo il parametro --skip-first-run. Per altre informazioni, vedere az pipeline create command documentation(az pipeline create command documentation ).

Miglioramento del comando dell'endpoint di servizio

I comandi dell'interfaccia della riga di comando dell'endpoint di servizio supportano solo azure rm e l'endpoint del servizio github configurati e di gestione. Tuttavia, con questa versione, i comandi dell'endpoint di servizio consentono di creare qualsiasi endpoint di servizio fornendo la configurazione tramite file e fornisce comandi ottimizzati: az devops service-endpoint github e az devops service-endpoint azurerm, che forniscono supporto per la prima classe per creare endpoint di servizio di questi tipi. Per altre informazioni, vedere la documentazione del comando .

Processi di distribuzione

Un processo di distribuzione è un tipo speciale di processo usato per distribuire l'app in un ambiente. Con questo aggiornamento è stato aggiunto il supporto per i riferimenti ai passaggi in un processo di distribuzione. Ad esempio, è possibile definire un set di passaggi in un file e fare riferimento a esso in un processo di distribuzione.

È stato aggiunto anche il supporto per proprietà aggiuntive al processo di distribuzione. Ecco ad esempio alcune proprietà di un processo di distribuzione che è ora possibile impostare,

  • timeoutInMinutes - Tempo di esecuzione del processo prima dell'annullamento automatico
  • cancelTimeoutInMinutes - Tempo di esecuzione sempre anche se le attività annullate prima di terminarle
  • condizione : eseguire il processo in modo condizionale
  • variabili : i valori hardcoded possono essere aggiunti direttamente o gruppi di variabili, un gruppo di variabili supportato da un insieme di credenziali delle chiavi di Azure può essere fatto riferimento o è possibile fare riferimento a un set di variabili definite in un file.
  • continueOnError : se i processi futuri devono essere eseguiti anche se il processo di distribuzione ha esito negativo; impostazione predefinita su 'false'

Per altre informazioni sui processi di distribuzione e sulla sintassi completa per specificare un processo di distribuzione, vedere Processo di distribuzione.

Visualizzazione delle informazioni sulle pipeline CD associate nelle pipeline CI

È stato aggiunto il supporto alle pipeline YAML cd in cui le pipeline CI vengono definite risorse della pipeline. Nella visualizzazione esecuzione della pipeline CI verrà ora visualizzata una nuova scheda "Pipeline associate" in cui è possibile trovare tutte le esecuzioni della pipeline che usano la pipeline e gli artefatti da esso.

Screenshot che mostra le informazioni sulle pipeline CD associate nelle pipeline CI.

Supporto per i pacchetti GitHub nelle pipeline YAML

Di recente è stato introdotto un nuovo tipo di risorsa denominato pacchetti che aggiunge il supporto per l'utilizzo di pacchettiNuGet e npm da GitHub come risorsa nelle pipeline YAML. Come parte di questa risorsa, è ora possibile specificare il tipo di pacchetto (NuGet o npm) che si vuole usare da GitHub. È anche possibile abilitare trigger di pipeline automatizzati al rilascio di una nuova versione del pacchetto. Oggi il supporto è disponibile solo per l'utilizzo di pacchetti da GitHub, ma si prevede di estendere il supporto per l'utilizzo di pacchetti da altri repository di pacchetti, ad esempio NuGet, npm, AzureArtifacts e molti altri. Per informazioni dettagliate, vedere l'esempio seguente:

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # Github service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the packge to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Nota

Oggi i pacchetti GitHub supportano solo l'autenticazione basata su PAT, il che significa che la connessione al servizio GitHub nella risorsa del pacchetto deve essere di tipo PAT. Una volta revocata questa limitazione, verrà fornito il supporto per altri tipi di autenticazione.

Per impostazione predefinita, i pacchetti non vengono scaricati automaticamente nei processi, quindi perché è stata introdotta una macro getPackage che consente di usare il pacchetto definito nella risorsa. Per informazioni dettagliate, vedere l'esempio seguente:

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

È stato aggiunto un collegamento alla visualizzazione delle risorse degli ambienti Kubernetes in modo da poter passare al pannello di Azure per il cluster corrispondente. Questo vale per gli ambienti mappati agli spazi dei nomi nei cluster servizio Azure Kubernetes.

Screenshot della visualizzazione risorse dell'ambiente Kubernetes con il collegamento cluster servizio Azure Kubernetes chiamato.

Filtri delle cartelle di rilascio nelle sottoscrizioni di notifica

Le cartelle consentono di organizzare le pipeline per semplificare la individuabilità e il controllo della sicurezza. Spesso è possibile configurare notifiche di posta elettronica personalizzate per tutte le pipeline di versione, rappresentate da tutte le pipeline in una cartella. In precedenza, è necessario configurare più sottoscrizioni o avere query complesse nelle sottoscrizioni per ottenere messaggi di posta elettronica incentrati. Con questo aggiornamento è ora possibile aggiungere una clausola di cartella di versione alla distribuzione completata e approvare gli eventi in sospeso e semplificare le sottoscrizioni.

Screenshot dei filtri delle cartelle di rilascio nelle sottoscrizioni di notifica.

Attualmente è possibile collegare automaticamente gli elementi di lavoro alle compilazioni classiche. Tuttavia, questa operazione non è stata possibile con le pipeline YAML. Con questo aggiornamento abbiamo risolto questo divario. Quando si esegue correttamente una pipeline usando codice da un ramo specificato, Azure Pipelines associa automaticamente l'esecuzione a tutti gli elementi di lavoro (che vengono dedotti tramite i commit in tale codice). Quando si apre l'elemento di lavoro, sarà possibile visualizzare le esecuzioni in cui è stato compilato il codice per tale elemento di lavoro. Per configurare questa operazione, usare il pannello delle impostazioni di una pipeline.

Annullare la fase in una pipeline YAML a più fasi

Quando si esegue una pipeline YAML a più fasi, è ora possibile annullare l'esecuzione di una fase mentre è in corso. Questo è utile se si sa che la fase avrà esito negativo o se si ha un'altra esecuzione che si vuole avviare.

Fasi di ripetizione dei tentativi non riuscite

Una delle funzionalità più richieste nelle pipeline multi-stage è la possibilità di riprovare una fase non riuscita senza dover iniziare dall'inizio. Con questo aggiornamento si aggiunge una parte importante di questa funzionalità.

È ora possibile riprovare una fase della pipeline quando l'esecuzione ha esito negativo. Tutti i processi non riusciti nel primo tentativo e quelli che dipendono in modo transitivo da tali processi non riusciti vengono tutti riprovati.

Ciò consente di risparmiare tempo in diversi modi. Ad esempio, quando si eseguono più processi in una fase, è possibile che ogni fase esegua test in una piattaforma diversa. Se i test in una piattaforma hanno esito negativo mentre altri passano, è possibile risparmiare tempo non eseguendo nuovamente i processi passati. Come un altro esempio, una fase di distribuzione potrebbe non essere riuscita a causa della connessione di rete flaky. Riprovare questa fase consente di risparmiare tempo non avendo la necessità di produrre un'altra compilazione.

Esistono alcune lacune note in questa funzionalità. Ad esempio, non è possibile ripetere una fase annullata in modo esplicito. Stiamo lavorando per chiudere queste lacune negli aggiornamenti futuri.

Approvazioni nelle pipeline YAML a più fasi

Le pipeline CD YAML possono contenere approvazioni manuali. I proprietari dell'infrastruttura possono proteggere gli ambienti e cercare approvazioni manuali prima di una fase in qualsiasi pipeline distribuirli. Con la separazione completa dei ruoli tra i proprietari dell'infrastruttura (ambiente) e dell'applicazione (pipeline), si garantisce l'accesso manuale per la distribuzione in una determinata pipeline e ottenere il controllo centrale nell'applicare gli stessi controlli in tutte le distribuzioni all'ambiente.

Screenshot del menu Aggiungi risorse con l'opzione Verifica sottolineata.

La pipeline esegue la distribuzione in fase di sviluppo si arresterà per l'approvazione all'inizio della fase.

Screenshot che mostra che una distribuzione è in attesa di approvazione.

Aumento del limite e della frequenza di timeout dei gate

In precedenza, il limite di timeout di gate nelle pipeline di rilascio era di tre giorni. Con questo aggiornamento, il limite di timeout è stato aumentato a 15 giorni per consentire le porte con durate più lunghe. Abbiamo anche aumentato la frequenza del cancello a 30 minuti.

Nuovo modello di immagine di compilazione per Dockerfile

In precedenza, quando si crea una nuova pipeline per un Dockerfile nella nuova creazione della pipeline, il modello consiglia di eseguire il push dell'immagine in un Registro Azure Container e distribuirlo in un servizio Azure Kubernetes. È stato aggiunto un nuovo modello per consentire di compilare un'immagine usando l'agente senza la necessità di eseguire il push in un registro contenitori.

Screenshot della finestra di dialogo Docker.

Nuova attività per la configurazione delle impostazioni dell'app Servizio app di Azure

Servizio app di Azure consente la configurazione tramite varie impostazioni, ad esempio impostazioni dell'app, stringhe di connessione e altre impostazioni di configurazione generali. È ora disponibile una nuova attività di Azure Pipelines Servizio app di Azure Impostazioni che supporta la configurazione di queste impostazioni in blocco usando la sintassi JSON nell'app Web o in uno dei relativi slot di distribuzione. Questa attività può essere usata insieme ad altre attività del servizio app per distribuire, gestire e configurare app Web, app per le funzioni o altri servizi app in contenitori.

Screenshot che mostra la finestra di dialogo Impostazioni Servizio app di Azure.

Servizio app di Azure ora supporta Lo scambio con l'anteprima

Servizio app di Azure ora supporta Lo scambio con anteprima sugli slot di distribuzione. Questo è un buon modo per convalidare l'app con la configurazione di produzione prima che l'app venga effettivamente scambiata da uno slot di staging nello slot di produzione. Ciò garantisce inoltre che lo slot di destinazione/produzione non verifichi tempi di inattività.

Servizio app di Azure attività supporta ora questo scambio a più fasi tramite le nuove azioni seguenti:

  • Avvia scambio con anteprima : avvia uno scambio con un'anteprima (scambio a più fasi) e applica lo slot di destinazione (ad esempio, lo slot di produzione) allo slot di origine.
  • Completare lo scambio con anteprima : quando si è pronti per completare lo scambio in sospeso, selezionare l'azione Completa scambio con anteprima.
  • Annulla scambio con anteprima : per annullare uno scambio in sospeso, selezionare Annulla scambio con anteprima.

Screenshot che mostra la finestra di dialogo gestione Servizio app di Azure con la nuova impostazione di scambio a più fasi nell'elenco a discesa Azione.

Filtro a livello di fase per Registro Azure Container e Docker Hub artefatti

In precedenza, i filtri delle espressioni regolari per Registro Azure Container e gli artefatti Docker Hub erano disponibili solo a livello di pipeline di rilascio. Sono stati aggiunti anche a livello di fase.

Screenshot che mostra che è possibile usare espressioni regolari a livello di staging.

Miglioramenti alle approvazioni nelle pipeline YAML

È stata abilitata la configurazione delle approvazioni nelle connessioni di servizio e nei pool di agenti. Per le approvazioni, seguire la separazione dei ruoli tra i proprietari dell'infrastruttura e gli sviluppatori. Configurando le approvazioni sulle risorse, ad esempio ambienti, connessioni di servizio e pool di agenti, si garantisce che tutte le esecuzioni della pipeline che usano le risorse richiedono prima l'approvazione.

L'esperienza è simile alla configurazione delle approvazioni per gli ambienti. Quando un'approvazione è in sospeso in una risorsa a cui fa riferimento in una fase, l'esecuzione della pipeline attende fino a quando la pipeline non viene approvata manualmente.

Screenshot che mostra la scheda Criteri con la pagina Usa approvazioni manuali e l'opzione Crea visibile.

Supporto dei test della struttura dei contenitori in Azure Pipelines

L'utilizzo dei contenitori nelle applicazioni aumenta e quindi la necessità di test e convalida affidabili. Azure Pipelines offre ora supporto per i test della struttura dei contenitori. Questo framework offre un modo pratico e potente per verificare il contenuto e la struttura dei contenitori.

È possibile convalidare la struttura di un'immagine in base a quattro categorie di test che possono essere eseguiti insieme: test di comando, test di esistenza dei file, test di contenuto file e test dei metadati. È possibile usare i risultati nella pipeline per prendere decisioni su go/no. I dati di test sono disponibili nell'esecuzione della pipeline con un messaggio di errore che consente di risolvere meglio gli errori.

Immettere i dettagli del file di configurazione e dell'immagine

Screenshot che mostra la pagina Test struttura contenitore.

Testare i dati e il riepilogo

Screenshot che mostra che sono disponibili dati di riepilogo e test.

Decorator della pipeline per le pipeline di rilascio

I decoratori della pipeline consentono di aggiungere passaggi all'inizio e alla fine di ogni processo. Questa operazione è diversa dall'aggiunta di passaggi a una singola definizione perché si applica a tutte le pipeline in una raccolta.

Sono stati supportati i decoratori per le compilazioni e le pipeline YAML, con i clienti che li usano per controllare centralmente i passaggi nei loro processi. È ora in corso l'estensione del supporto per rilasciare le pipeline. È possibile creare estensioni per aggiungere passaggi destinati al nuovo punto di contributo e verranno aggiunti a tutti i processi dell'agente nelle pipeline di rilascio.

Distribuire Azure Resource Manager (ARM) a livello di sottoscrizione e gruppo di gestione

In precedenza sono supportate le distribuzioni solo a livello di gruppo di risorse. Con questo aggiornamento è stato aggiunto il supporto per distribuire i modelli di Resource Manager ai livelli di sottoscrizione e di gruppo di gestione. Ciò consente di distribuire insieme un set di risorse, ma di inserirli in gruppi di risorse o sottoscrizioni diversi. Ad esempio, la distribuzione della macchina virtuale di backup per Azure Site Recovery in un gruppo di risorse e una posizione separati.

Funzionalità CD per le pipeline YAML a più fasi

È ora possibile usare gli artefatti pubblicati dalla pipeline CI e abilitare i trigger di completamento della pipeline. Nelle pipeline YAML a più fasi viene presentata pipelines come risorsa. In YAML è ora possibile fare riferimento a un'altra pipeline e abilitare anche i trigger CD.

Ecco lo schema YAML dettagliato per la risorsa pipeline.

resources: 
  pipelines:
  - pipeline: MyAppCI  # identifier for the pipeline resource
    project:  DevOpsProject # project for the build pipeline; optional input for current project
    source: MyCIPipeline  # source pipeline definition name
    branch: releases/M159  # branch to pick the artifact, optional; defaults to all branches
    version: 20190718.2 # pipeline run number to pick artifact; optional; defaults to last successfully completed run
    trigger:     # Optional; Triggers are not enabled by default.
      branches:  
        include:  # branches to consider the trigger events, optional; defaults to all branches.
        - main
        - releases/*
        exclude:   # branches to discard the trigger events, optional; defaults to none.
        - users/*  

È inoltre possibile scaricare gli artefatti pubblicati dalla risorsa della pipeline usando l'attività - download .

steps: 
- download: MyAppCI  # pipeline resource identifier
    artifact:  A1 # name of the artifact to download; optional; defaults to all artifacts

Per altre informazioni, vedere la documentazione relativa ai download degli artefatti qui.

Orchestrare la strategia di distribuzione canary nell'ambiente per Kubernetes

Uno dei vantaggi principali della distribuzione continua degli aggiornamenti dell'applicazione è la possibilità di eseguire rapidamente il push degli aggiornamenti nella produzione per microservizi specifici. In questo modo è possibile rispondere rapidamente ai cambiamenti nei requisiti aziendali. L'ambiente è stato introdotto come concetto di prima classe che abilita l'orchestrazione delle strategie di distribuzione e facilita le versioni di inattività zero. In precedenza è stata supportata la strategia runOnce che ha eseguito i passaggi una volta in sequenza. Con il supporto per la strategia canary nelle pipeline multi-stage, è ora possibile ridurre il rischio eseguendo lentamente la distribuzione della modifica a un piccolo subset. Man mano che si ottiene maggiore attendibilità nella nuova versione, è possibile iniziare a implementarla in più server nell'infrastruttura e indirizzare più utenti a esso.

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

La strategia canary per Kuberenetes distribuisce prima le modifiche con i pod del 10% seguiti dal 20% durante il monitoraggio dell'integrità durante il postRouteTraffic. Se tutto va bene, promuoverà il 100%.

Si stanno cercando commenti e suggerimenti iniziali sul supporto per le risorse delle macchine virtuali negli ambienti e l'esecuzione di una strategia di distribuzione in sequenza tra più computer. Contattaci per registrarci .

Criteri di approvazione per le pipeline YAML

Nelle pipeline YAML viene seguita una configurazione di approvazione controllata dal proprietario della risorsa. I proprietari delle risorse configurano le approvazioni nella risorsa e tutte le pipeline che usano la risorsa sospendeno per le approvazioni prima dell'inizio della fase che utilizza la risorsa. È comune per i proprietari di applicazioni basate su SOX limitare la richiesta della distribuzione da approvare le proprie distribuzioni.

È ora possibile usare opzioni di approvazione avanzate per configurare i criteri di approvazione come il richiedente non devono approvare, richiedere l'approvazione da un subset di utenti e timeout di approvazione.

Screenshot che mostra la finestra di dialogo Crea approvazioni.

Registro Azure Container come risorsa della pipeline di prima classe

Se è necessario usare un'immagine del contenitore pubblicata in Registro Azure Container (Registro Azure Container) come parte della pipeline e attivare la pipeline ogni volta che è stata pubblicata una nuova immagine, è possibile usare la risorsa contenitore ACR.

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

È inoltre possibile accedere ai meta-dati dell'immagine del Registro Azure Container usando variabili predefinite. L'elenco seguente include le variabili del Registro Azure Container disponibili per definire una risorsa contenitore del Registro Azure Container nella pipeline.

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

Miglioramenti per valutare i criteri di controllo degli artefatti nelle pipeline

È stato migliorato il controllo dell'artefatto di valutazione per semplificare l'aggiunta di criteri da un elenco delle definizioni dei criteri fuori casella. La definizione dei criteri verrà generata automaticamente e aggiunta alla configurazione del controllo che può essere aggiornata se necessario.

Screenshot che mostra la finestra di dialogo Valuta artefatto con l'opzione Usa modelli sottolineata.

Screenshot che mostra la finestra di dialogo Configura criteri di artefatto con l'elenco di modelli da includere.

Supporto per le variabili di output in un processo di distribuzione

È ora possibile definire le variabili di output negli hook del ciclo di vita di un processo di distribuzione e usarle in altri passaggi e processi downstream all'interno della stessa fase.

Durante l'esecuzione di strategie di distribuzione, è possibile accedere alle variabili di output tra processi usando la sintassi seguente.

  • Per la strategia runOnce : $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
  • Per la strategia canary : $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
  • Per la strategia in sequenza : $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]
// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
  pool:
    vmImage: 'ubuntu-16.04'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: echo $(setvarStep.myOutputVar)
          name: echovar

 // Map the variable from the job
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-16.04'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

Altre informazioni su come impostare una variabile di output multi-job

Evitare il rollback delle modifiche critiche

Nelle pipeline di rilascio classiche, è comune basarsi sulle distribuzioni pianificate per gli aggiornamenti regolari. Tuttavia, quando si ha una correzione critica, è possibile scegliere di avviare una distribuzione manuale fuori banda. In questo caso, le versioni precedenti continuano a rimanere pianificate. Ciò ha rappresentato una sfida poiché la distribuzione manuale verrà eseguito il rollback quando le distribuzioni riprendevano in base alla pianificazione. Molti di voi hanno segnalato questo problema e ora è stato risolto. Con la correzione, tutte le distribuzioni pianificate precedenti all'ambiente verranno annullate quando si avvia manualmente una distribuzione. Questa opzione è applicabile solo quando l'opzione di accodamento è selezionata come "Distribuisci più recente e annulla altri".

Autorizzazione semplificata delle risorse nelle pipeline YAML

Una risorsa è qualsiasi elemento usato da una pipeline esterna alla pipeline. Le risorse devono essere autorizzate prima che possano essere usate. In precedenza, quando si usano risorse non autorizzate in una pipeline YAML, non è stato possibile eseguire un errore di autorizzazione delle risorse. È necessario autorizzare le risorse dalla pagina di riepilogo dell'esecuzione non riuscita. Inoltre, la pipeline non è riuscita se usa una variabile che fa riferimento a una risorsa non autorizzata.

È ora possibile gestire più facilmente le autorizzazioni delle risorse. Invece di non riuscire l'esecuzione, l'esecuzione attenderà le autorizzazioni per le risorse all'inizio della fase che utilizza la risorsa. Un proprietario di risorse può visualizzare la pipeline e autorizzare la risorsa dalla pagina Sicurezza.

Screenshot che mostra una fase dev in uno stato in attesa con un indicatore che indica che è necessaria l'autorizzazione.

Valutare il controllo dell'artefatto

È ora possibile definire un set di criteri e aggiungere la valutazione dei criteri come controllo su un ambiente per gli artefatti dell'immagine del contenitore. Quando viene eseguita una pipeline, l'esecuzione viene sospesa prima di avviare una fase che usa l'ambiente. Il criterio specificato viene valutato rispetto ai metadati disponibili per la distribuzione dell'immagine. Il controllo passa quando il criterio ha esito positivo e contrassegna la fase come non riuscita se il controllo ha esito negativo.

Screenshot della finestra di dialogo Valuta criteri dell'artefatto.

Aggiornamenti all'attività di distribuzione del modello di Resource Manager

In precedenza non sono stati filtrate le connessioni al servizio nell'attività di distribuzione dei modelli di Resource Manager. Ciò può comportare un errore nella distribuzione se si seleziona una connessione del servizio con ambito inferiore per eseguire distribuzioni di modelli di Resource Manager in un ambito più ampio. È stato ora aggiunto il filtro delle connessioni al servizio per filtrare le connessioni di servizio con ambito inferiore in base all'ambito di distribuzione scelto.

RivediApp nell'ambiente

ReviewApp distribuisce ogni richiesta pull dal repository Git a una risorsa di ambiente dinamica. I revisori possono verificare come tali modifiche siano presenti e funzionino con altri servizi dipendenti prima di essere uniti al ramo principale e distribuiti nella produzione. In questo modo è possibile creare e gestire le risorse reviewApp e trarre vantaggio da tutte le funzionalità di tracciabilità e diagnosi delle funzionalità di ambiente. Usando la parola chiave reviewApp , è possibile creare un clone di una risorsa (creare dinamicamente una nuova risorsa in base a una risorsa esistente in un ambiente) e aggiungere la nuova risorsa all'ambiente.

Di seguito è riportato un frammento di codice YAML di esempio dell'uso di reviewApp in ambienti.

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MasterNamespace

Raccogliere metadati automatici e specificati dall'utente dalla pipeline

È ora possibile abilitare la raccolta di metadati automatica e specificata dall'utente dalle attività della pipeline. È possibile usare i metadati per applicare i criteri di artefatto in un ambiente usando il controllo degli artefatti di valutazione.

Screenshot della finestra di dialogo Generale con l'opzione Pubblica metadati dalle pipeline attivate.

Distribuzioni di macchine virtuali con ambienti

Una delle funzionalità più richieste negli ambienti è stata la distribuzione di macchine virtuali. Con questo aggiornamento si abilita la risorsa macchina virtuale in Ambienti. È ora possibile orchestrare le distribuzioni in più computer ed eseguire aggiornamenti in sequenza usando pipeline YAML. È anche possibile installare l'agente in ogni server di destinazione direttamente e guidare la distribuzione in sequenza a tali server. È inoltre possibile usare il catalogo attività completo nei computer di destinazione.

Screenshot della finestra di dialogo Nuovo ambiente con l'opzione Macchine virtuali selezionata e chiamata.

Una distribuzione in sequenza sostituisce le istanze della versione precedente di un'applicazione con istanze della nuova versione dell'applicazione in un set di computer (set in sequenza) in ogni iterazione.

Ad esempio, sotto gli aggiornamenti della distribuzione in sequenza fino a cinque destinazioni in ogni iterazione. maxParallel determina il numero di destinazioni che possono essere distribuite in parallelo. Gli account di selezione per il numero di destinazioni che devono rimanere disponibili in qualsiasi momento, esclusi gli obiettivi distribuiti. Viene inoltre usata per determinare le condizioni di esito positivo e negativo durante la distribuzione.

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTaffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

Nota

Con questo aggiornamento, tutti gli artefatti disponibili dalla pipeline corrente e dalle risorse della pipeline associate vengono scaricati solo nell'hook deploy del ciclo di vita. È tuttavia possibile scegliere di scaricare specificando l'attività Scarica artefatto pipeline. Esistono alcune lacune note in questa funzionalità. Ad esempio, quando si riprova una fase, la distribuzione verrà eseguita nuovamente in tutte le macchine virtuali non solo destinazioni non riuscite. Stiamo lavorando per chiudere queste lacune negli aggiornamenti futuri.

Controllo aggiuntivo delle distribuzioni

Azure Pipelines ha supportato distribuzioni controllate con approvazioni manuali per qualche tempo. Con i miglioramenti più recenti, è ora disponibile un controllo aggiuntivo sulle distribuzioni. Oltre alle approvazioni, i proprietari delle risorse possono ora aggiungere automatizzati checks per verificare i criteri di sicurezza e qualità. Questi controlli possono essere usati per attivare le operazioni e quindi attendere il completamento. Usando i controlli aggiuntivi, è ora possibile definire criteri di integrità in base a più origini e assicurarsi che tutte le distribuzioni destinate alle risorse siano sicure, indipendentemente dalla pipeline YAML che esegue la distribuzione. La valutazione di ogni controllo può essere ripetuta periodicamente in base all'intervallo di ripetizione dei tentativi specificato per il controllo. Sono ora disponibili i controlli aggiuntivi seguenti:

  • Richiamare qualsiasi API REST ed eseguire la convalida in base al corpo della risposta o al callback dal servizio esterno
  • Richiamare una funzione di Azure ed eseguire la convalida in base alla risposta o a un callback dalla funzione
  • Eseguire query su regole di Monitoraggio di Azure per gli avvisi attivi
  • Assicurarsi che la pipeline estende uno o più modelli YAML

Screenshot della finestra di dialogo Aggiungi controllo.

Notifica di approvazione

Quando si aggiunge un'approvazione a un ambiente o una connessione al servizio, tutte le pipeline a più fasi che usano la risorsa attenderanno automaticamente l'approvazione all'inizio della fase. I responsabili di approvazione designati devono completare l'approvazione prima che la pipeline possa continuare.

Con questo aggiornamento, i responsabili dell'approvazione vengono inviati una notifica di posta elettronica per l'approvazione in sospeso. Gli utenti e i proprietari del team possono rifiutare o configurare sottoscrizioni personalizzate usando le impostazioni di notifica.

Screenshot di una notifica di approvazione.

Configurare le strategie di distribuzione da portale di Azure

Con questa funzionalità è stato reso più semplice configurare le pipeline che usano la strategia di distribuzione desiderata, ad esempio Rolling, Canary o Blue-Green. Usando queste strategie predefinite, è possibile implementare gli aggiornamenti in modo sicuro e attenuare i rischi di distribuzione associati. Per accedere a questo problema, fare clic sull'impostazione "Recapito continuo" in una macchina virtuale di Azure. Nel riquadro di configurazione verrà richiesto di selezionare i dettagli del progetto Azure DevOps in cui verrà creata la pipeline, il gruppo di distribuzione, la pipeline di compilazione che pubblica il pacchetto da distribuire e la strategia di distribuzione desiderata. In futuro verrà configurata una pipeline completamente funzionale che distribuisce il pacchetto selezionato in questa macchina virtuale.

Per altre informazioni, vedere la documentazione relativa alla configurazione delle strategie di distribuzione.

Screenshot che mostra la finestra di dialogo recapito continuo.

Parametri di runtime

I parametri di runtime consentono di avere più controllo sui valori che possono essere passati a una pipeline. A differenza delle variabili, i parametri di runtime hanno tipi di dati e non diventano automaticamente variabili di ambiente. Con i parametri di runtime è possibile:

  • Fornire valori diversi agli script e alle attività in fase di esecuzione
  • Tipi di parametri di controllo, intervalli consentiti e impostazioni predefinite
  • Selezionare dinamicamente processi e fasi con espressione di modello

Per altre informazioni sui parametri di runtime, vedere la documentazione qui.

Usare la parola chiave estende nelle pipeline

Attualmente, le pipeline possono essere inserite in modelli, promuovendo il riutilizzo e riducendo la piastra caldaia. La struttura complessiva della pipeline è ancora stata definita dal file YAML radice. Con questo aggiornamento è stato aggiunto un modo più strutturato per usare i modelli di pipeline. Un file YAML radice può ora usare la parola chiave estende per indicare che la struttura della pipeline principale può essere trovata in un altro file. Ciò consente di controllare quali segmenti possono essere estesi o modificati e quali segmenti sono fissi. Sono stati inoltre migliorati i parametri della pipeline con i tipi di dati per cancellare gli hook che è possibile fornire.

Questo esempio illustra come è possibile fornire semplici hook per l'autore della pipeline da usare. Il modello eseguirà sempre una compilazione, eseguirà facoltativamente passaggi aggiuntivi forniti dalla pipeline e quindi eseguirà un passaggio di test facoltativo.


# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

Variabili di controllo che possono essere sostituite in fase di coda

In precedenza, è possibile usare l'interfaccia utente o l'API REST per aggiornare i valori di qualsiasi variabile prima di avviare una nuova esecuzione. Anche se l'autore della pipeline può contrassegnare determinate variabili come _settable at queue time_, il sistema non ha applicato questo, né ha impedito l'impostazione di altre variabili. In altre parole, l'impostazione è stata usata solo per richiedere input aggiuntivi durante l'avvio di una nuova esecuzione.

È stata aggiunta una nuova impostazione di raccolta che applica il _settable at queue time_ parametro. In questo modo sarà possibile controllare quali variabili possono essere modificate quando si avvia una nuova esecuzione. In futuro, non è possibile modificare una variabile che non è contrassegnata dall'autore come _settable at queue time_.

Nota

Questa impostazione è disattivata per impostazione predefinita nelle raccolte esistenti, ma sarà attiva per impostazione predefinita quando si crea una nuova raccolta Azure DevOps.

Nuove variabili predefinite nella pipeline YAML

Le variabili consentono di ottenere bit chiave di dati in varie parti della pipeline. Con questo aggiornamento sono state aggiunte alcune variabili predefinite a un processo di distribuzione. Queste variabili vengono impostate automaticamente dal sistema, con ambito per il processo di distribuzione specifico e di sola lettura.

  • Environment.Id : ID dell'ambiente.
  • Environment.Name: nome dell'ambiente destinato al processo di distribuzione.
  • Environment.ResourceId: ID della risorsa nell'ambiente di destinazione del processo di distribuzione.
  • Environment.ResourceName: nome della risorsa nell'ambiente di destinazione del processo di distribuzione.

Eseguire il checkout di più repository

Le pipeline si basano spesso su più repository. È possibile disporre di repository diversi con origine, strumenti, script o altri elementi necessari per compilare il codice. In precedenza, è necessario aggiungere questi repository come sottomoduli o come script manuali per eseguire il checkout git. A questo punto è possibile recuperare e controllare altri repository, oltre a quello usato per archiviare la pipeline YAML.

Ad esempio, se si dispone di un repository denominato MyCode con una pipeline YAML e un secondo repository denominato Strumenti, la pipeline YAML avrà un aspetto simile al seguente:

resources:
  repositories:
  - repository: tools
    name: Tools
    type: git

steps:
- checkout: self
- checkout: tools
- script: dir $(Build.SourcesDirectory)

Il terzo passaggio mostrerà due directory, MyCode e Tools nella directory di origini.

sono supportati Azure Repos repository Git, GitHub e Bitbucket Cloud. Per altre informazioni, vedere Estrazione multi-repository.

Recupero dei dettagli in fase di esecuzione su più repository

Quando una pipeline è in esecuzione, Azure Pipelines aggiunge informazioni sul repository, il ramo e il commit che ha attivato l'esecuzione. Ora che le pipeline YAML supportano il controllo di più repository, è anche possibile conoscere il repository, il ramo e il commit selezionati per altri repository. Questi dati sono disponibili tramite un'espressione di runtime, che ora è possibile eseguire il mapping in una variabile. Ad esempio:

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: echo "Tools version: $TOOLS_REF"

Consenti riferimenti al repository ad altre raccolte di Azure Repos

In precedenza, quando si fa riferimento ai repository in una pipeline YAML, tutti i repository Azure Repos devono trovarsi nella stessa raccolta della pipeline. A questo punto, è possibile puntare ai repository in altre raccolte usando una connessione al servizio. Ad esempio:

resources:
  repositories:
  - repository: otherrepo
    name: ProjectName/RepoName
    endpoint: MyServiceConnection
steps:
- checkout: self
- checkout: otherrepo

MyServiceConnection punta a un'altra raccolta Azure DevOps e dispone di credenziali che possono accedere al repository in un altro progetto. Entrambi i repos, self e otherrepo, finiranno estratto.

Importante

MyServiceConnectiondeve essere una connessione al servizio Azure Repos/Team Foundation Server, vedere l'immagine seguente.

Screenshot della pagina Impostazioni progetto con l'opzione Azure Repos/Team Foundation Server evidenziata.

Meta-dati delle risorse della pipeline come variabili predefinite

Nella pipeline sono state aggiunte variabili predefinite per le pipeline YAML. Ecco l'elenco delle variabili di risorsa della pipeline disponibili.

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

kustomize and kompose as bake options in KubernetesManifest task

kustomize (parte dell'interfaccia della riga di comando di Kubernetes) consente di personalizzare i file YAML non elaborati e liberi dal modello per più scopi e lasciare invariato l'originale YAML. Un'opzione per kustomize è stata aggiunta nell'azione bake dell'attività KubernetesManifest in modo che qualsiasi cartella contenente kustomization.yaml possa essere usata per generare i file manifesto usati nell'azione di distribuzione dell'attività KubernetesManifest.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Kompose trasforma un file Docker Compose in una risorsa Kubernetes.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Supporto per le credenziali di amministratore del cluster nell'attività HelmDeploy

In precedenza, l'attività HelmDeploy usava le credenziali utente del cluster per le distribuzioni. Ciò ha generato richieste di accesso interattive e pipeline non riuscite per un cluster abilitato per il controllo degli accessi in base al ruolo basato su Azure Active Directory. Per risolvere questo problema, è stata aggiunta una casella di controllo che consente di usare le credenziali di amministratore del cluster anziché le credenziali utente del cluster.

Screenshot dei grafici Helm che mostrano la casella di controllo Usa credenziali di amministratore del cluster.

Input degli argomenti nell'attività Docker Compose

Un nuovo campo è stato introdotto nell'attività Docker Compose per consentire di aggiungere argomenti come --no-cache. L'argomento verrà passato dall'attività quando si eseguono comandi come la compilazione.

Screenshot dell'attività Docker Compose che mostra la nuova casella di testo Argomenti.

Miglioramenti delle attività di rilascio di GitHub

Sono stati apportati diversi miglioramenti all'attività GitHub Release. È ora possibile avere un controllo migliore sulla creazione del rilascio usando il campo modello di tag specificando un'espressione regolare del tag e la versione verrà creata solo quando il commit di attivazione viene contrassegnato con una stringa corrispondente.

Screenshot che mostra l'attività di rilascio di GitHub con le sezioni Task version e Tag Pattern denominate.

Sono state aggiunte anche funzionalità per personalizzare la creazione e la formattazione del changelog. Nella nuova sezione per la configurazione del changelog è ora possibile specificare la versione in base alla quale deve essere confrontata la versione corrente. La versione Compare to release può essere l'ultima versione completa (esclude le versioni precedenti), l'ultima versione non bozza o qualsiasi versione precedente corrispondente al tag di rilascio specificato. Inoltre, l'attività fornisce il campo del tipo changelog per formattare il changelog. In base alla selezione, il changelog visualizzerà un elenco di commit o un elenco di problemi/PR classificati in base alle etichette.

Screenshot che mostra l'attività di rilascio di GitHub con le sezioni Confronto e tipo changelog evidenziate.

Aprire l'attività del programma di installazione dell'agente criteri

Open Policy Agent è un motore di criteri open source per utilizzo generico che consente un'applicazione dei criteri unificata e con riconoscimento del contesto. È stata aggiunta l'attività di installazione di Open Policy Agent. È particolarmente utile per l'applicazione dei criteri in-pipeline rispetto all'infrastruttura come provider di codice.

Ad esempio, Open Policy Agent può valutare i file dei criteri rego e i piani Terraform nella pipeline.

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

Supporto per gli script di PowerShell nell'attività dell'interfaccia della riga di comando di Azure

In precedenza, è possibile eseguire script batch e bash come parte di un'attività dell'interfaccia della riga di comando di Azure. Con questo aggiornamento, è stato aggiunto il supporto per gli script di base di PowerShell e PowerShell all'attività.

Screenshot dell'attività dell'interfaccia della riga di comando di Azure che mostra che PowerShell e Powershell Core sono opzioni nell'elenco a discesa Tipo di script.

Distribuzioni canary basate su Interfaccia mesh del servizio nell'attività KubernetesManifest

In precedenza, quando la strategia canary è stata specificata nell'attività KubernetesManifest, l'attività creerebbe carichi di lavoro baseline e canary le cui repliche equivalevano a una percentuale delle repliche usate per carichi di lavoro stabili. Ciò non corrisponde esattamente alla suddivisione del traffico fino alla percentuale desiderata a livello di richiesta. Per risolvere questo problema, è stato aggiunto il supporto per le distribuzioni canary basate su Service Mesh all'attività KubernetesManifest.

L'astrazione dell'interfaccia di Service Mesh consente la configurazione plug-and-play con provider di mesh del servizio, ad esempio Linkerd e Istio. Ora l'attività KubernetesManifest elimina il duro lavoro del mapping degli oggetti TrafficSplit di SMI ai servizi stabile, baseline e canary durante il ciclo di vita della strategia di distribuzione. La percentuale desiderata di suddivisione del traffico tra stabile, baseline e canary è più accurata perché la divisione del traffico percentuale viene controllata sulle richieste nel piano della mesh del servizio.

Di seguito è riportato un esempio di esecuzione di distribuzioni canary basate su SMI in modo in sequenza.

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

Attività copia file di Azure supporta ora AzCopy V10

L'attività di copia file di Azure può essere usata in una pipeline di compilazione o versione per copiare file in BLOB di archiviazione Microsoft o macchine virtuali . L'attività usa AzCopy, la compilazione dell'utilità della riga di comando per la copia rapida dei dati da e negli account di archiviazione di Azure. Con questo aggiornamento è stato aggiunto il supporto per AzCopy V10 che è la versione più recente di AzCopy.

Il azcopy copy comando supporta solo gli argomenti associati. A causa della modifica nella sintassi di AzCopy, alcune delle funzionalità esistenti non sono disponibili in AzCopy V10. Queste includono:

  • Specifica del percorso del log
  • Pulizia dei file di log e piano dopo la copia
  • Riprendere la copia se il processo ha esito negativo

Le funzionalità aggiuntive supportate in questa versione dell'attività sono:

  • Simboli jolly nel nome/percorso del file dell'origine
  • Dedurre il tipo di contenuto in base all'estensione di file quando non vengono forniti argomenti
  • Definizione della verbosità del log per il file di log passando un argomento

Migliorare la sicurezza della pipeline limitando l'ambito dei token di accesso

Ogni processo eseguito in Azure Pipelines ottiene un token di accesso. Il token di accesso viene usato dalle attività e dagli script per eseguire nuovamente la chiamata ad Azure DevOps. Ad esempio, viene usato il token di accesso per ottenere il codice sorgente, caricare i log, i risultati di test, gli artefatti o eseguire chiamate REST in Azure DevOps. Un nuovo token di accesso viene generato per ogni processo e scade al termine del processo. Con questo aggiornamento sono stati aggiunti i miglioramenti seguenti.

  • Impedire al token di accedere alle risorse all'esterno di un progetto team

    Fino a questo momento, l'ambito predefinito di tutte le pipeline era la raccolta di progetti team. È possibile modificare l'ambito in modo che sia il progetto team nelle pipeline di compilazione classiche. Tuttavia, non è stato disponibile tale controllo per le pipeline YAML o versione classica. Con questo aggiornamento viene presentata un'impostazione di raccolta per forzare ogni processo per ottenere un token con ambito progetto indipendentemente da ciò che è configurato nella pipeline. È stata aggiunta anche l'impostazione a livello di progetto. Ora, ogni nuovo progetto e raccolta creato avrà automaticamente questa impostazione attivata.

    Nota

    L'impostazione della raccolta esegue l'override dell'impostazione del progetto.

    L'attivazione di questa impostazione nei progetti e nelle raccolte esistenti può causare un errore di determinate pipeline se le pipeline accedono alle risorse esterne al progetto team usando i token di accesso. Per attenuare gli errori della pipeline, è possibile concedere in modo esplicito l'accesso dell'account del servizio di compilazione del progetto alla risorsa desiderata. È consigliabile attivare queste impostazioni di sicurezza.

  • Limitare l'accesso all'ambito del servizio di compilazione

    In base al miglioramento della sicurezza della pipeline limitando l'ambito del token di accesso, Azure Pipelines può ora definire l'ambito dell'accesso al repository solo ai repository necessari per una pipeline basata su YAML. Ciò significa che, se il token di accesso delle pipeline dovesse perdere, sarà possibile visualizzare solo i repository usati nella pipeline. In precedenza, il token di accesso è stato valido per qualsiasi repository di Azure Repos nel progetto o potenzialmente per l'intera raccolta.

    Questa funzionalità verrà attivata per impostazione predefinita per nuovi progetti e raccolte. Per le raccolte esistenti, è necessario abilitarla in Impostazioni delle>pipeline delle> raccolte. Quando si usa questa funzionalità, tutti i repository necessari per la compilazione (anche quelli clonato usando uno script) devono essere inclusi nelle risorse del repository della pipeline.

  • Rimuovere determinate autorizzazioni per il token di accesso

    Per impostazione predefinita, viene concessa una serie di autorizzazioni al token di accesso, una di queste autorizzazioni è la compilazione della coda. Con questo aggiornamento, questa autorizzazione è stata rimossa per il token di accesso. Se le pipeline necessitano di questa autorizzazione, è possibile concederla in modo esplicito all'account del servizio di compilazione progetto o all'account del servizio di compilazione della raccolta di progetti a seconda del token usato.

Sicurezza a livello di progetto per le connessioni al servizio

È stata aggiunta la sicurezza a livello di hub per le connessioni al servizio. È ora possibile aggiungere/rimuovere utenti, assegnare ruoli e gestire l'accesso in una posizione centralizzata per tutte le connessioni al servizio.

Screenshot della pagina Connessioni al servizio con l'opzione Sicurezza evidenziata.

Selezione dei passaggi e isolamento dei comandi

Azure Pipelines supporta l'esecuzione di processi in contenitori o nell'host dell'agente. In precedenza, un intero processo è stato impostato su una di queste due destinazioni. Ora, i singoli passaggi (attività o script) possono essere eseguiti nella destinazione scelta. I passaggi possono anche essere destinati ad altri contenitori, in modo che una pipeline possa eseguire ogni passaggio in un contenitore specializzato creato appositamente.

I contenitori possono fungere da limiti di isolamento, impedendo al codice di apportare modifiche impreviste nel computer host. I passaggi per comunicare con e accedere ai servizi dall'agente non sono interessati dall'isolamento dei passaggi in un contenitore. Di conseguenza, viene introdotto anche una modalità di restrizione dei comandi che è possibile usare con le destinazioni dei passaggi. L'attivazione di questa opzione limita i servizi che un passaggio può richiedere dall'agente. Non sarà più in grado di allegare log, caricare artefatti e alcune altre operazioni.

Ecco un esempio completo, che illustra i passaggi in esecuzione nell'host in un contenitore di processi e in un altro contenitore:

resources:
  containers:
  - container: python
    image: python:3.8
  - container: node
    image: node:13.2

jobs:
- job: example
  container: python

  steps:
  - script: echo Running in the job container

  - script: echo Running on the host
    target: host

  - script: echo Running in another container, in restricted commands mode
    target:
      container: node
      commands: restricted

Variabili di sola lettura

Le variabili di sistema sono state documentate come non modificabili, ma in pratica potrebbero essere sovrascritte da un'attività e da attività downstream prelevano il nuovo valore. Con questo aggiornamento, si rafforza la sicurezza delle variabili della pipeline per rendere di sola lettura le variabili di sistema e in fase di coda. È anche possibile impostare una variabile YAML di sola lettura contrassegnandola come indicato di seguito.

variables:
- name: myVar
  value: myValue
  readonly: true

Accesso in base al ruolo per le connessioni al servizio

È stato aggiunto l'accesso in base al ruolo per le connessioni al servizio. In precedenza, la sicurezza della connessione al servizio poteva essere gestita solo tramite gruppi di Azure DevOps predefiniti, ad esempio amministratori di endpoint ed Endpoint Creators.

Come parte di questo lavoro, sono stati introdotti i nuovi ruoli lettore, utente, creatore e amministratore. È possibile impostare questi ruoli tramite la pagina connessioni al servizio nel progetto e queste vengono ereditate dalle singole connessioni. In ogni connessione al servizio è possibile attivare o disattivare l'ereditarietà ed eseguire l'override dei ruoli nell'ambito della connessione al servizio.

Screenshot che mostra l'accesso in base al ruolo per le connessioni al servizio.

Altre informazioni sulla sicurezza delle connessioni al servizio sono disponibili qui.

Condivisione tra progetti di connessioni al servizio

È stato abilitato il supporto per la condivisione delle connessioni al servizio tra progetti. È ora possibile condividere le connessioni al servizio con i progetti in modo sicuro e sicuro.

Screenshot che mostra la condivisione tra progetti delle connessioni al servizio.

Altre informazioni sulla condivisione delle connessioni al servizio sono disponibili qui.

Tracciabilità per pipeline e risorse del Registro Azure Container

Si garantisce la tracciabilità completa di E2E quando le pipeline e le risorse del contenitore del Registro Azure Container vengono usate in una pipeline. Per ogni risorsa utilizzata dalla pipeline YAML, è possibile risalire ai commit, agli elementi di lavoro e agli artefatti.

Nella visualizzazione riepilogo dell'esecuzione della pipeline è possibile visualizzare:

  • Versione della risorsa che ha attivato l'esecuzione. È ora possibile attivare la pipeline al completamento di un'altra esecuzione di una pipeline di Azure o quando viene eseguito il push di un'immagine del contenitore in Registro Azure Container.

    Screenshot che mostra che una pipeline è stata attivata automaticamente.

  • Commit utilizzati dalla pipeline. È anche possibile trovare la suddivisione dei commit per ogni risorsa utilizzata dalla pipeline.

    Screenshot che mostra i commit nella sezione Pipeline corrente.

  • Elementi di lavoro associati a ogni risorsa utilizzata dalla pipeline.

  • Elementi disponibili per l'esecuzione.

    Screenshot che mostra la pagina Artefatti per la pipeline.

Nella visualizzazione distribuzioni dell'ambiente è possibile visualizzare i commit e gli elementi di lavoro per ogni risorsa distribuita nell'ambiente.

Screenshot della sezione Deployment by (Distribuzione per) che mostra la scheda Workitems (Elementi di lavoro).

Supporto per allegati di test di grandi dimensioni

L'attività Pubblica risultati test in Azure Pipelines consente di pubblicare i risultati dei test quando vengono eseguiti test per offrire un'esperienza completa di creazione di report e analisi dei test. Fino ad ora, era previsto un limite di 100 MB per gli allegati di test sia per l'esecuzione del test che per i risultati dei test. Questo limita il caricamento di file di grandi dimensioni, ad esempio dump di arresto anomalo o video. Con questo aggiornamento è stato aggiunto il supporto per allegati di test di grandi dimensioni che consentono di avere tutti i dati disponibili per risolvere i problemi dei test non superati.

È possibile che nei log venga visualizzata l'attività VSTest o Pubblica risultati test che restituisce un errore 403 o 407. Se si usano build self-hosted o agenti di rilascio dietro un firewall che filtra le richieste in uscita, sarà necessario apportare alcune modifiche di configurazione per poter usare questa funzionalità. ​

Screenshot che mostra un errore 403 restituito nei log.

Per risolvere questo problema, è consigliabile aggiornare il firewall per le richieste in uscita a https://*.vstmrblob.vsassets.io. Per informazioni sulla risoluzione dei problemi, vedere la documentazione qui. ​

Nota

Questa operazione è necessaria solo se si usano agenti Azure Pipelines self-hosted e si è protetti da un firewall che filtra il traffico in uscita. Se si usano agenti ospitati da Microsoft nel cloud o che non filtrano il traffico di rete in uscita, non è necessario eseguire alcuna azione.

Visualizzare le informazioni corrette sul pool in ogni processo

In precedenza, quando è stata usata una matrice per espandere i processi o una variabile per identificare un pool, le informazioni sul pool non sono state risolte nelle pagine dei log. Questi problemi sono stati risolti.

Trigger CI per i nuovi rami

È stata una lunga richiesta in sospeso per non attivare compilazioni CI quando viene creato un nuovo ramo e quando tale ramo non ha modifiche. Considera gli esempi che seguono:

  • Usare l'interfaccia Web per creare un nuovo ramo basato su un ramo esistente. Verrà attivata immediatamente una nuova compilazione CI se il filtro di ramo corrisponde al nome del nuovo ramo. Ciò è indesiderato perché il contenuto del nuovo ramo è lo stesso rispetto al ramo esistente.
  • Si dispone di un repository con due cartelle: app e documenti. Si configura un filtro di percorso per l'integrazione continua in modo che corrisponda a "app". In altre parole, non si vuole creare una nuova compilazione se è stato eseguito il push di una modifica nella documentazione. Si crea un nuovo ramo in locale, si apportano alcune modifiche alla documentazione e quindi si esegue il push di tale ramo nel server. È stato usato per attivare una nuova compilazione ci. Questo è indesiderato perché è stato chiesto esplicitamente di non cercare le modifiche nella cartella docs. Tuttavia, a causa del modo in cui è stato gestito un nuovo evento di ramo, sembra che sia stata apportata anche una modifica alla cartella dell'app.

A questo punto, è disponibile un modo migliore per gestire l'integrazione continua per i nuovi rami per risolvere questi problemi. Quando si pubblica un nuovo ramo, vengono cercati in modo esplicito nuovi commit in tale ramo e si verifica se corrispondono ai filtri di percorso.

I processi possono accedere alle variabili di output dalle fasi precedenti

Le variabili di output possono ora essere usate in più fasi in una pipeline basata su YAML. Ciò consente di passare informazioni utili, ad esempio una decisione go/no-go o l'ID di un output generato, da una fase alla successiva. È disponibile anche il risultato (stato) di una fase precedente e i relativi processi.

Le variabili di output vengono comunque generate dai passaggi all'interno dei processi. Invece di fare riferimento a dependencies.jobName.outputs['stepName.variableName'], le fasi fanno riferimento a stageDependencies.stageName.jobName.outputs['stepName.variableName'].

Nota

Per impostazione predefinita, ogni fase di una pipeline dipende da quella appena precedente nel file YAML. Pertanto, ogni fase può usare le variabili di output della fase precedente. È possibile modificare il grafico delle dipendenze, che modificherà anche le variabili di output disponibili. Ad esempio, se la fase 3 richiede una variabile dalla fase 1, sarà necessario dichiarare una dipendenza esplicita nella fase 1.

Disabilitare gli aggiornamenti automatici degli agenti a livello di pool

Attualmente, gli agenti di pipeline verranno aggiornati automaticamente alla versione più recente quando necessario. Ciò si verifica in genere quando è presente una nuova funzionalità o un'attività che richiede una versione più recente dell'agente per funzionare correttamente. Con questo aggiornamento si aggiunge la possibilità di disabilitare gli aggiornamenti automatici a livello di pool. In questa modalità, se nessun agente della versione corretta è connesso al pool, le pipeline avranno esito negativo con un messaggio di errore chiaro anziché richiedere l'aggiornamento degli agenti. Questa funzionalità è principalmente di interesse per i clienti con pool self-hosted e requisiti di controllo delle modifiche molto rigorosi. Gli aggiornamenti automatici sono abilitati per impostazione predefinita e la maggior parte dei clienti non li disabilita.

Sceenshot della pagina Impostazioni predefinite con l'opzione Impostazioni aggiornamento agente attivata e chiamata.

Diagnostica agente

È stata aggiunta la diagnostica per molti problemi comuni relativi all'agente, ad esempio molti problemi di rete e cause comuni di errori di aggiornamento. Per iniziare a usare la diagnostica, usare run.sh --diagnostics o run.cmd --diagnostics in Windows.

Hook di servizio per le pipeline YAML

L'integrazione dei servizi con le pipeline YAML è semplice. Usando gli eventi dei service hook per le pipeline YAML, è ora possibile eseguire attività in app o servizi personalizzati in base allo stato di avanzamento delle esecuzioni della pipeline. Ad esempio, è possibile creare un ticket di supporto tecnico quando è necessaria un'approvazione, avviare un flusso di lavoro di monitoraggio dopo il completamento di una fase o inviare una notifica push ai dispositivi mobili del team quando una fase ha esito negativo.

Il filtro sul nome della pipeline e sul nome della fase è supportato per tutti gli eventi. Gli eventi di approvazione possono essere filtrati anche per ambienti specifici. Analogamente, gli eventi di modifica dello stato possono essere filtrati in base al nuovo stato dell'esecuzione della pipeline o alla fase.

Screenshot della procedura guidata NEW SERVICE HOOKS SUBSCRIPTION che mostra l'elenco a discesa Trigger su questo tipo di evento con le opzioni Di esecuzione chiamate.

Integrazione ottimizzata

Optimizely è una potente piattaforma di test E/B per i team di prodotti. L'integrazione di Azure Pipelines con la piattaforma di sperimentazione ottimizzata consente ai team di prodotti di testare, apprendere e distribuire in modo accelerato, ottenendo tutti i vantaggi di DevOps da Azure Pipelines.

L'estensione Optimizely per Azure DevOps aggiunge i passaggi di implementazione del flag di sperimentazione e funzionalità alle pipeline di compilazione e rilascio, in modo da poter eseguire continuamente l'iterazione, implementare le funzionalità e eseguirne il rollback usando Azure Pipelines.

Altre informazioni sull'estensione Azure DevOps Optimizely sono disponibili qui.

Ottimizzare

Aggiungere una versione di GitHub come origine artefatti

È ora possibile collegare le versioni di GitHub come origine artefatti nelle pipeline di rilascio di Azure DevOps. In questo modo verrà utilizzata la versione di GitHub come parte delle distribuzioni.

Quando si fa clic su Aggiungi un artefatto nella definizione della pipeline di rilascio, si troverà il nuovo tipo di origine gitHub Release . È possibile fornire la connessione al servizio e il repository GitHub per usare la versione di GitHub. È anche possibile scegliere una versione predefinita per la versione di GitHub da usare come versione più recente, specifica del tag o selezionare in fase di creazione della versione. Dopo aver collegato una versione di GitHub, viene scaricato automaticamente e reso disponibile nei processi di rilascio.

Screenshot della finestra di dialogo Aggiungi un artefatto con l'opzione Versione di GitHub selezionata e chiamata.

Integrazione di Terraform con Azure Pipelines

Terraform è uno strumento open source per lo sviluppo, la modifica e la modifica dell'infrastruttura di controllo delle versioni in modo sicuro ed efficiente. Terraform codifica le API nei file di configurazione dichiarativi che consentono di definire e effettuare il provisioning dell'infrastruttura usando un linguaggio di configurazione di alto livello. È possibile usare l'estensione Terraform per creare risorse in tutti i principali provider di infrastrutture: Azure, Amazon Web Services (AWS) e Google Cloud Platform (GCP).

Per altre informazioni sull'estensione Terraform, vedere la documentazione qui.

Screenshot dell'integrazione di Terraform con Azure Pipelines.

Integrazione con Google Analytics

Il framework degli esperimenti di Google Analytics consente di testare quasi tutte le modifiche o le variazioni in un sito Web o un'app per misurare l'impatto su un obiettivo specifico. Ad esempio, potresti avere attività che vuoi che gli utenti completino (ad esempio, effettuare un acquisto, iscriversi per una newsletter) e/o metriche che vuoi migliorare (ad esempio, ricavi, durata sessione, frequenza di rimbalzo). Queste attività consentono di identificare le modifiche che vale la pena implementare in base all'impatto diretto sulle prestazioni della funzionalità.

L'estensione degli esperimenti di Google Analytics per Azure DevOps aggiunge i passaggi di sperimentazione alle pipeline di compilazione e rilascio, in modo da poter eseguire continuamente l'iterazione, apprendere e distribuire in modo accelerato gestendo gli esperimenti su base continua ottenendo tutti i vantaggi di DevOps da Azure Pipelines.

È possibile scaricare l'estensione degli esperimenti di Google Analytics dal Marketplace.

Screenshot che mostra l'attività Esperimenti di Google Analytics.

Aggiornamento dell'integrazione di ServiceNow con Azure Pipelines

L'app Azure Pipelines per ServiceNow consente di integrare Azure Pipelines e ServiceNow Change Management. Con questo aggiornamento è possibile integrare con la versione di New York di ServiceNow. L'autenticazione tra i due servizi può ora essere eseguita usando OAuth e l'autenticazione di base. È inoltre possibile configurare criteri di successo avanzati in modo da poter usare qualsiasi proprietà di modifica per decidere il risultato del gate.

Creare Azure Pipelines da VSCode

È stata aggiunta una nuova funzionalità all'estensione Azure Pipelines per VSCode. A questo momento, sarà possibile creare Azure Pipelines direttamente da VSCode senza uscire dall'IDE.

Screenshot di VS Code con un avviso nell'angolo in basso a destra che indica: la pipeline è stata configurata correttamente.

Gestione e risoluzione di bug flaky

È stata introdotta la gestione dei test flaky per supportare il ciclo di vita end-to-end con rilevamento, creazione di report e risoluzione. Per migliorare ulteriormente la gestione e la risoluzione dei bug di test flaky.

Durante l'analisi del test flaky, è possibile creare un bug usando l'azione Bug che può quindi essere assegnata a uno sviluppatore per analizzare ulteriormente la causa radice del test flaky. Il report di bug include informazioni sulla pipeline, ad esempio il messaggio di errore, la traccia dello stack e altre informazioni associate al test.

Quando viene risolto o chiuso un report di bug, il test verrà automaticamente annullato.

Impostare le attività VSTest per avere esito negativo se non vengono eseguiti un numero minimo di test

L'attività VSTest individua ed esegue test usando input utente (file di test, criteri di filtro e così via) nonché un adattatore di test specifico per il framework di test usato. Le modifiche apportate agli input utente o all'adattatore di test possono causare casi in cui i test non vengono individuati e vengono eseguiti solo un subset dei test previsti. Ciò può causare situazioni in cui le pipeline hanno esito positivo perché i test vengono ignorati anziché perché il codice è di qualità sufficiente. Per evitare questa situazione, è stata aggiunta una nuova opzione nell'attività VSTest che consente di specificare il numero minimo di test che devono essere eseguiti per l'attività da passare.

Screenshot che mostra l'attività Fail se un numero minimo di test non è in esecuzione.

L'opzione VSTest TestResultsDirectory è disponibile nell'interfaccia utente dell'attività

L'attività VSTest archivia i risultati dei test e i file associati nella $(Agent.TempDirectory)\TestResults cartella. È stata aggiunta un'opzione all'interfaccia utente dell'attività per consentire di configurare una cartella diversa per archiviare i risultati dei test. Ora tutte le attività successive che richiedono i file in un percorso specifico possono usarle.

Screenshot che mostra la casella di testo Della cartella Risultati test.

Supporto markdown nei messaggi di errore di test automatizzati

È stato aggiunto il supporto markdown ai messaggi di errore per i test automatizzati. È ora possibile formattare facilmente i messaggi di errore per l'esecuzione del test e il risultato del test per migliorare la leggibilità e semplificare l'esperienza di risoluzione dei problemi degli errori di test in Azure Pipelines. La sintassi markdown supportata è disponibile qui.

Screenshot che mostra il supporto markdown nei messaggi di errore di test automatizzati.

Usare i decorator della pipeline per inserire automaticamente i passaggi in un processo di distribuzione

È ora possibile aggiungere i decoratori della pipeline ai processi di distribuzione. È possibile disporre di qualsiasi passaggio personalizzato (ad esempio scanner di vulnerabilità) inserito automaticamente in ogni esecuzione del ciclo di vita di ogni processo di distribuzione. Poiché i decoratori della pipeline possono essere applicati a tutte le pipeline in una raccolta, questa operazione può essere utilizzata come parte dell'applicazione di procedure di distribuzione sicure.

Inoltre, i processi di distribuzione possono essere eseguiti come processo contenitore insieme ai servizi side-car se definiti.

Test Plans

Pagina Nuovo piano di test

Una nuova pagina di Test Plans (Test Plans *) è disponibile per tutte le raccolte di Azure DevOps. La nuova pagina offre visualizzazioni semplificate che consentono di concentrarsi sull'attività a portata di mano- pianificazione dei test, creazione o esecuzione. È anche inclutter-free e coerente con il resto dell'offerta Azure DevOps.

Screenshot che mostra due piani di test denominati in modo identitario che condividono un archivio back-end.

Aiutami a comprendere la nuova pagina

pagina panoramica del piano di test

La nuova pagina Test Plans ha un totale di 6 sezioni di cui le prime 4 sono nuove, mentre le sezioni Estendibilità grafici & sono le funzionalità esistenti.

  1. Intestazione del piano di test: usare questa opzione per individuare, preferiti, modificare, copiare o clonare un piano di test.
  2. Albero delle suite di test: usare questa opzione per aggiungere, gestire, esportare o ordinare pacchetti di test. Sfruttare questa funzionalità anche per assegnare configurazioni ed eseguire test di accettazione utente.
  3. Definire la scheda: Collate, aggiungere e gestire i test case in una suite di test di scelta tramite questa scheda.
  4. Scheda Esegui: Assegnare ed eseguire test tramite questa scheda o individuare un risultato del test da eseguire per eseguire il drill-in.
  5. Scheda Grafico: tenere traccia dell'esecuzione e dello stato dei test tramite grafici che possono essere aggiunti anche ai dashboard.
  6. Estendibilità: supporta i punti di estendibilità correnti all'interno del prodotto.

Consente di visualizzare un ampio tratto di queste nuove sezioni di seguito.

1. Intestazione del piano di test

pagina dell'intestazione del piano di test

Attività

L'intestazione Piano di test consente di eseguire le attività seguenti:

  • Contrassegnare un piano di test come preferito
  • Deselezionare un piano di test preferito
  • Spostarsi facilmente tra i piani di test preferiti
  • Visualizzare il percorso di iterazione del piano di test, che indica chiaramente se il piano di test è Corrente o Passato
  • Visualizzare il riepilogo rapido del report Stato di test con un collegamento per passare al report
  • Tornare alla pagina All/Mine Test Plans

Opzioni del menu di scelta rapida

Il menu di scelta rapida nell'intestazione Piano di test offre le opzioni seguenti:

  • Copia piano di test: questa è una nuova opzione che consente di copiare rapidamente il piano di test corrente. Altre informazioni sono disponibili di seguito.
  • Modifica piano di test: questa opzione consente di modificare il modulo dell'elemento di lavoro piano di test per gestire i campi dell'elemento di lavoro.
  • Impostazioni del piano di test: questa opzione consente di configurare le impostazioni esecuzione test (per associare pipeline di compilazione o rilascio) e le impostazioni del risultato test

Copiare il piano di test (nuova funzionalità)

pagina del piano di test di copia

È consigliabile creare un nuovo piano di test per sprint/rilascio. In questo caso, in genere il piano di test per il ciclo precedente può essere copiato e con poche modifiche il piano di test copiato è pronto per il nuovo ciclo. Per semplificare questo processo, è stata abilitata una funzionalità "Copia piano di test" nella nuova pagina. Sfruttandolo è possibile copiare o clonare i piani di test. L'API REST di backup è illustrata qui e l'API consente anche di copiare/clonare un piano di test tra progetti.
Per altre linee guida sull'utilizzo Test Plans, vedere qui.

2. Albero delle suite di test

pagina albero delle suite di test

Attività

L'intestazione della suite di test consente di eseguire le attività seguenti:

  • Espandere/comprimere: questa opzione della barra degli strumenti consente di espandere o comprimere l'albero della gerarchia della suite.
  • Mostra i punti di test dai gruppi figlio: questa opzione della barra degli strumenti è visibile solo quando si è nella scheda "Esegui". In questo modo è possibile visualizzare tutti i punti di test per la suite specificata e i relativi figli in una visualizzazione per semplificare la gestione dei punti di test senza dover passare a singole suite una alla volta.
  • Suite di ordine: è possibile trascinare/rilasciare le suite per riordinare la gerarchia delle suite o spostarle da una gerarchia della suite a un'altra all'interno del piano di test.

Opzioni del menu di scelta rapida

Il menu di scelta rapida nell'albero Dei gruppi di test offre le opzioni seguenti:

  • Creare nuove suite: è possibile creare 3 diversi tipi di suite come indicato di seguito:
    • Usare suite statica o suite di cartelle per organizzare i test.
    • Usare la suite basata sui requisiti per collegare direttamente i requisiti/storie utente per la tracciabilità senza problemi.
    • Usare query basate su query per organizzare dinamicamente i test case che soddisfano criteri di query.
  • Assegnare configurazioni: è possibile assegnare configurazioni per la suite (ad esempio: Chrome, Firefox, EdgeChromium) e queste saranno quindi applicabili a tutti i test case esistenti o ai nuovi test case aggiunti più avanti a questa suite.
  • Esporta come pdf/email: esportare le proprietà del piano di test, le proprietà della suite di test e i dettagli dei test case e i punti di test come "email" o "stampa in pdf".
  • Aprire l'elemento di lavoro della suite di test: questa opzione consente di modificare il modulo elemento di lavoro della suite di test per gestire i campi dell'elemento di lavoro.
  • Assegnare i tester per eseguire tutti i test: questa opzione è molto utile per gli scenari UAT (User Acceptance Testing) in cui lo stesso test deve essere eseguito/eseguito da più tester, in genere appartenenti a reparti diversi.
  • Rinomina/Elimina: queste opzioni consentono di gestire il nome della suite o rimuovere la suite e il relativo contenuto dal piano di test.

3. Definire la scheda

definire la pagina della scheda

La scheda Definisci consente di raggruppare, aggiungere e gestire i test case per una suite di test. Mentre la scheda esegui è per assegnare i punti di test ed eseguirli.

La scheda Definisci e alcune operazioni sono disponibili solo per gli utenti con livello di accesso basic + Test Plans equivalente. Tutto il resto deve essere esercitabile da un utente con il livello di accesso "Basic".

Attività

La scheda Definisci consente di eseguire le attività seguenti:

  • Aggiungere nuovo test case usando il modulo dell'elemento di lavoro: questa opzione consente di creare un nuovo test case usando il modulo dell'elemento di lavoro. Il test case creato verrà aggiunto automaticamente alla suite.
  • Aggiungere nuovo test case usando la griglia: questa opzione consente di creare uno o più test case usando la visualizzazione griglia dei test case. I test case creati verranno aggiunti automaticamente alla suite.
  • Aggiungere test case esistenti usando una query: questa opzione consente di aggiungere test case esistenti alla suite specificando una query.
  • Ordina test case trascinando/rilasciando: è possibile riordinare i test case trascinando/eliminando uno o più test case all'interno di una determinata suite. L'ordine dei test case si applica solo ai test case manuali e non ai test automatizzati.
  • Spostare i test case da una suite a un'altra: l'uso del trascinamento/selezione consente di spostare i test case da una suite di test a un'altra.
  • Mostra griglia: è possibile usare la modalità griglia per visualizzare/modificare i test case insieme ai passaggi di test.
  • Visualizzazione schermo intero: è possibile visualizzare il contenuto dell'intera scheda Definisci in modalità schermo intero usando questa opzione.
  • Filtro: usando la barra dei filtri, è possibile filtrare l'elenco dei test case usando i campi "titolo del test case", "assegnato a" e "state". È anche possibile ordinare l'elenco facendo clic sulle intestazioni di colonna.
  • Opzioni di colonna: è possibile gestire l'elenco di colonne visibili nella scheda Definisci usando "Opzioni colonna". L'elenco delle colonne disponibili per la selezione sono principalmente i campi del modulo dell'elemento di lavoro del test case.

Opzioni del menu di scelta rapida

Pagina del menu di scelta rapida della scheda

Il menu di scelta rapida nel nodo Test case all'interno della scheda Definisci offre le opzioni seguenti:

  • Modulo dell'elemento di lavoro open/edit test case: questa opzione consente di modificare un test case usando il modulo dell'elemento di lavoro in cui si modificano i campi dell'elemento di lavoro, inclusi i passaggi di test.
  • Modifica test case: questa opzione consente di modificare in blocco i campi dell'elemento di lavoro del test case. Tuttavia, non è possibile usare questa opzione per modificare in blocco i passaggi di test.
  • Modificare i test case nella griglia: questa opzione consente di modificare in blocco i test case selezionati, inclusi i passaggi di test usando la visualizzazione griglia.
  • Assegnare configurazioni: questa opzione consente di eseguire l'override delle configurazioni a livello di suite con configurazioni a livello di test case.
  • Rimuovere i test case: questa opzione consente di rimuovere i test case dalla suite specificata. Non modifica tuttavia l'elemento di lavoro del test case sottostante.
  • Creare una copia/clonazione dei test case: questa opzione consente di creare una copia/clonazione dei test case selezionati. Vedere di seguito per altri dettagli.
  • Visualizzare gli elementi collegati: questa opzione consente di esaminare gli elementi collegati per un determinato test case. Vedere di seguito per altri dettagli.

Copy/clone test case (nuova funzionalità)

definire la pagina dei test case di copia della scheda

Per gli scenari in cui si vuole copiare/clonare un test case, è possibile usare l'opzione "Copia test case". È possibile specificare il progetto di destinazione, il piano di test di destinazione e la suite di test di destinazione in cui creare il test case copia/clonato. È inoltre possibile specificare se si desidera includere collegamenti/allegati esistenti per il flusso nella copia clonata.

Visualizzare gli elementi collegati (nuova funzionalità)

definire la pagina degli elementi collegati della visualizzazione tabulazioni

La tracciabilità tra artefatti di test, requisiti e bug è una proposta di valore fondamentale del prodotto Test Plans. Usando l'opzione "Visualizza elementi collegati" è possibile esaminare facilmente tutti i requisiti collegati collegati a cui è collegato questo test case, tutti i pacchetti di test/piani di test in cui questo test case è stato usato e tutti i bug che sono stati registrati come parte dell'esecuzione del test.

4. Eseguire scheda

pagina esegui scheda

La scheda Definisci consente di raggruppare, aggiungere e gestire i test case per una suite di test. Mentre la scheda esegui è per assegnare i punti di test ed eseguirli.

Che cos'è un punto di test? I test case da soli non sono eseguibili. Quando si aggiunge un test case a una suite di test, vengono generati i punti di test. Un punto di test è una combinazione unica di test case, suite di test, configurazione e tester. Esempio: se si dispone di un test case come "Funzionalità di accesso di test" e si aggiungono 2 configurazioni come Edge e Chrome, questo risultato è 2 punti di test. È ora possibile eseguire questi punti di test. In fase di esecuzione vengono generati i risultati dei test. Tramite la visualizzazione dei risultati del test (cronologia di esecuzione) è possibile visualizzare tutte le esecuzioni di un punto di test. L'esecuzione più recente per il punto di test è ciò che viene visualizzato nella scheda Esegui.
Di conseguenza, i test case sono entità riutilizzabili. Includendoli in un piano di test o in una suite, i punti di test vengono generati. Eseguendo i punti di test, si determina la qualità del prodotto o del servizio sviluppato.

Uno dei vantaggi principali della nuova pagina è per gli utenti che eseguono principalmente test di esecuzione/rilevamento (devono avere solo un livello di accesso "Basic"), non sono sovraccaricati dalla complessità della gestione della suite (la scheda definisci è nascosta per tali utenti).

La scheda Definisci e alcune operazioni sono disponibili solo per gli utenti con livello di accesso basic + Test Plans equivalente. Tutto il resto, inclusa la scheda "Esegui" deve essere esercitata da un utente con livello di accesso "Basic".

Attività

La scheda Esegui consente di eseguire le attività seguenti:

  • Contrassegnare i punti di test in blocco: questa opzione consente di contrassegnare rapidamente il risultato dei punti di test, superati, non superati, bloccati o non applicabili, senza dover eseguire il test case tramite lo strumento di esecuzione test. Il risultato può essere contrassegnato per uno o più punti di test in un'unica operazione.
  • Esegui test points: questa opzione consente di eseguire i test case singolarmente eseguendo ogni passaggio di test e contrassegnandoli superati/non superati usando un test runner. A seconda dell'applicazione di cui si esegue il test, è possibile usare "Runner Web" per testare un'applicazione Web o "runner desktop" per il test di applicazioni desktop e/o Web. È anche possibile richiamare l'opzione "Esegui con opzioni" per specificare una compilazione in base alla quale eseguire i test da eseguire.
  • Opzioni di colonna: è possibile gestire l'elenco di colonne visibili nella scheda Esegui usando "Opzioni di colonna". L'elenco delle colonne disponibili per la selezione è associato ai punti di test, ad esempio Esegui da, Tester assegnato, Configurazione e così via.
  • Visualizzazione a schermo intero: è possibile visualizzare il contenuto dell'intera scheda Esegui in modalità schermo intero usando questa opzione.
  • Filtro: usando la barra dei filtri, è possibile filtrare l'elenco dei punti di test usando i campi "test case title", "assigned to", "state", "test outcome", "Tester" e "Configuration". È anche possibile ordinare l'elenco facendo clic sulle intestazioni di colonna.

Opzioni del menu di scelta rapida

Pagina del menu di scelta rapida esegui scheda

Il menu di scelta rapida del nodo Punto di test all'interno della scheda Esegui offre le opzioni seguenti:

  • Contrassegna il risultato del test: come sopra, consente di contrassegnare rapidamente il risultato dei punti di test, superati, non superati, bloccati o non applicabili.
  • Eseguire i punti di test: come in precedenza, consente di eseguire i test case tramite test runner.
  • Reimposta test su attivo: questa opzione consente di reimpostare il risultato del test su attivo, ignorando così l'ultimo risultato del punto di test.
  • Modulo apri/modifica elemento di lavoro test case: questa opzione consente di modificare un test case usando il modulo dell'elemento di lavoro in cui si modificano i campi dell'elemento di lavoro, inclusi i passaggi di test.
  • Assegna tester: questa opzione consente di assegnare i punti di test ai tester per l'esecuzione dei test.
  • Visualizza risultato del test: questa opzione consente di visualizzare i dettagli più recenti del risultato del test, inclusi il risultato di ogni passaggio di test, i commenti aggiunti o i bug inseriti.
  • Visualizza cronologia esecuzione: questa opzione consente di visualizzare l'intera cronologia di esecuzione per il punto di test selezionato. Si apre una nuova pagina in cui è possibile modificare i filtri per visualizzare la cronologia di esecuzione non solo del punto di test selezionato, ma anche per l'intero test case.

Test Plans report Stato

Questo report corporato consente di tenere traccia dell'esecuzione e dello stato di uno o più Test Plans in un progetto. Visitare Test Plans > report stato* per iniziare a usare il report.

Screenshot della sezione Test Plans con l'opzione Report di stato evidenziata.

Le tre sezioni del report includono quanto segue:

  1. Riepilogo: mostra una visualizzazione consolidata per i piani di test selezionati.
  2. Tendenza dei risultati: esegue il rendering di uno snapshot giornaliero per fornire una linea di tendenza di esecuzione e stato. Può visualizzare i dati per 14 giorni (impostazione predefinita), 30 giorni o un intervallo personalizzato.
  3. Dettagli: questa sezione consente di eseguire il drill-down in base a ogni piano di test e offre analisi importanti per ogni gruppo di test.

Screenshot del report Stato.

Artifacts

Nota

Azure DevOps Server 2020 non importa feed presenti nel Cestino durante l'importazione dei dati. Se vuoi importare feed che si trovano nel Cestino, ripristinali dal Cestino prima di avviare l'importazione dei dati.

Espressioni di licenza e licenze incorporate

È ora possibile visualizzare i dettagli delle informazioni sulle licenze per i pacchetti NuGet archiviati in Azure Artifacts durante l'esplorazione dei pacchetti in Visual Studio. Questo vale per le licenze rappresentate tramite espressioni di licenza o licenze incorporate. È ora possibile visualizzare un collegamento alle informazioni sulla licenza nella pagina dei dettagli del pacchetto di Visual Studio (freccia rossa nell'immagine seguente).

Screenshot del pacchetto NuGet Newtonsoft.Json con una freccia rossa che punta alla licenza del pacchetto.

Facendo clic sul collegamento si passerà a una pagina Web in cui è possibile visualizzare i dettagli della licenza. Questa esperienza è la stessa per le espressioni di licenza e le licenze incorporate, quindi è possibile visualizzare i dettagli della licenza per i pacchetti archiviati in Azure Artifacts in un'unica posizione (per i pacchetti che specificano le informazioni sulla licenza e sono supportati da Visual Studio).

Screenshot di una finestra del browser che mostra il testo della licenza MIT

Attività di autenticazione semplificate

È ora possibile eseguire l'autenticazione con gli strumenti di gestione pacchetti più diffusi di Azure Pipelines usando attività di autenticazione leggera. Sono inclusi NuGet, npm, PIP, Twine e Maven. In precedenza, è possibile eseguire l'autenticazione con questi strumenti di gestione pacchetti usando attività che hanno fornito una grande quantità di funzionalità, inclusa la possibilità di pubblicare e scaricare pacchetti. Tuttavia, è necessario usare queste attività per tutte le attività che hanno interagito con gli strumenti di gestione pacchetti. Se si dispone di script personalizzati per l'esecuzione di attività come la pubblicazione o il download di pacchetti, non sarà possibile usarli nella pipeline. È ora possibile usare script di progettazione personalizzati nel file YAML della pipeline ed eseguire l'autenticazione con queste nuove attività leggere. Esempio di utilizzo di npm:

Screenshot di un esempio di un'attività di autenticazione leggera.

L'uso del comando "ci" e "publish" in questa illustrazione è arbitrario. È possibile usare qualsiasi comando supportato da Azure Pipelines YAML. In questo modo è possibile avere il controllo completo della chiamata al comando e semplificare l'uso di script condivisi nella configurazione della pipeline. Per altre informazioni, vedere la documentazione dell'attività di autenticazione NuGet, npm, PIP, Twine e Maven .

Miglioramenti al tempo di caricamento delle pagine dei feed

Siamo lieti di annunciare che abbiamo migliorato il tempo di caricamento della pagina del feed. In media, i tempi di caricamento delle pagine del feed sono diminuiti del 10%. I feed più grandi hanno visto il miglioramento maggiore del 99° tempo di caricamento della pagina del feed percentile (tempi di caricamento nel 99% più alto di tutti i feed) diminuito del 75%.

Condividere i pacchetti pubblicamente con feed pubblici

È ora possibile creare e archiviare i pacchetti all'interno di feed pubblici. I pacchetti archiviati all'interno dei feed pubblici sono disponibili per tutti gli utenti su Internet senza autenticazione, indipendentemente dal fatto che si trovino o meno nella raccolta o addirittura connessi a una raccolta di Azure DevOps. Per altre informazioni sui feed pubblici, vedere la documentazione dei feed o passare direttamente all'esercitazione per condividere i pacchetti pubblicamente.

Screenshot che mostra la pagina PublicFeed per i pacchetti.

Configurare upstream in raccolte diverse all'interno di un tenant di AAD

È ora possibile aggiungere un feed in un'altra raccolta associata al tenant di Azure Active Directory (AAD) come origine upstream al feed Artifacts. Il feed può trovare e usare pacchetti dai feed configurati come origini upstream, consentendo la condivisione dei pacchetti facilmente tra le raccolte associate al tenant di AAD. Vedere come configurare questa impostazione nella documentazione.

Usare il provider di credenziali Python per autenticare pip e twine con feed di Azure Artifacts

È ora possibile installare e usare il provider di credenziali Python (artifacts-keyring) per configurare automaticamente l'autenticazione per pubblicare o utilizzare pacchetti Python da o verso un feed di Azure Artifacts. Con il provider di credenziali non è necessario configurare alcun file di configurazione (pip.ini/pip.conf/.pypirc), si passerà semplicemente attraverso un flusso di autenticazione nel Web browser quando si chiama pip o twine per la prima volta. Per altre informazioni , vedere la documentazione.

Feed di Azure Artifacts in Gestione pacchetti di Visual Studio

Vengono ora visualizzate icone, descrizioni e autori dei pacchetti in Gestione pacchetti NuGet di Visual Studio per i pacchetti serviti dai feed di Azure Artifacts. In precedenza, la maggior parte di questi metadati non è stata fornita a Visual Studio.

Aggiornamento dell'esperienza di connessione al feed

La finestra di dialogo Connetti al feed è l'ingresso verso l'uso di Azure Artifacts; contiene informazioni su come configurare client e repository per eseguire il push e il pull dei pacchetti dai feed in Azure DevOps. La finestra di dialogo è stata aggiornata per aggiungere informazioni dettagliate sulla configurazione ed è stata espansa l'estensione degli strumenti per cui vengono fornite le istruzioni.

I feed pubblici sono ora disponibili a livello generale con il supporto upstream

L'anteprima pubblica dei feed pubblici ha ricevuto un'ottima adozione e feedback. In questa versione sono stati estesi funzionalità aggiuntive alla disponibilità generale. È ora possibile impostare un feed pubblico come origine upstream da un feed privato. È possibile mantenere semplici i file di configurazione essendo in grado di upstream sia da che da feed privati e con ambito progetto.

Creare feed con ambito progetto dal portale

Quando sono stati rilasciati feed pubblici, sono stati rilasciati anche feed con ambito progetto. Fino ad ora, i feed con ambito progetto possono essere creati tramite API REST o creando un feed pubblico e quindi trasformando il progetto privato. È ora possibile creare feed con ambito progetto direttamente nel portale da qualsiasi progetto se si dispone delle autorizzazioni necessarie. È anche possibile vedere quali feed sono progetto e quali sono con ambito raccolta nella selezione feed.

Miglioramenti delle prestazioni di npm

Sono state apportate modifiche alla progettazione principale per migliorare il modo in cui vengono archiviati e recapitati pacchetti npm nei feed di Azure Artifacts. Ciò ha consentito di raggiungere una riduzione fino a 10 riduzioni della latenza per alcune delle API più usate per npm.

Miglioramenti all'accessibilità

Sono state distribuite correzioni per risolvere i problemi di accessibilità nella pagina dei feed. Le correzioni includono quanto segue:

  • Creare un'esperienza di feed
  • Esperienza delle impostazioni del feed globale
  • Connettersi all'esperienza di feed

Wiki

Modifica avanzata per le pagine wiki del codice

In precedenza, quando si modifica una pagina wiki del codice, si è stato reindirizzato all'hub Azure Repos per la modifica. Attualmente l'hub repository non è ottimizzato per la modifica markdown.

È ora possibile modificare una pagina wiki del codice nell'editor side-by-side all'interno del wiki. In questo modo è possibile usare la barra degli strumenti rich markdown per creare il contenuto rendendo l'esperienza di modifica identica a quella del wiki del progetto. È comunque possibile scegliere di modificare i repository selezionando l'opzione Modifica in Repos nel menu di scelta rapida.

Screenshot che mostra il menu Modifica con l'opzione Modifica in Repos chiamata.

Creare e incorporare elementi di lavoro da una pagina wiki

Come abbiamo ascoltato il tuo feedback, abbiamo sentito che usi wiki per acquisire documenti di brainstorming, documenti di pianificazione, idee su funzionalità, documenti specifiche, minuti di riunione. Ora è possibile creare facilmente funzionalità e storie utente direttamente da un documento di pianificazione senza uscire dalla pagina wiki.

Per creare un elemento di lavoro, selezionare il testo nella pagina wiki in cui si vuole incorporare l'elemento di lavoro e selezionare Nuovo elemento di lavoro. Ciò consente di risparmiare tempo perché non è necessario creare prima l'elemento di lavoro, passare alla modifica e quindi trovare l'elemento di lavoro da incorporare. Riduce anche il commutatore di contesto perché non si esce dall'ambito wiki.

Breve video che illustra come creare e incorporare elementi di lavoro da una pagina wiki.

Per altre informazioni sulla creazione e l'incorporamento di un elemento di lavoro da wiki, vedere la documentazione qui.

Commenti nelle pagine wiki

In precedenza, non è stato possibile interagire con altri utenti wiki all'interno del wiki. Ciò ha fatto collaborare sul contenuto e ricevere domande risposte a una sfida perché le conversazioni hanno dovuto verificarsi tramite canali di posta elettronica o chat. Con i commenti è ora possibile collaborare con altri utenti direttamente all'interno del wiki. È possibile sfruttare le @mention funzionalità degli utenti all'interno dei commenti per attirare l'attenzione di altri membri del team. Questa funzionalità è stata prioritaria in base a questo ticket di suggerimento. Per altre informazioni sui commenti, vedere la documentazione qui.

Screenshot che mostra come aggiungere commenti nelle pagine wiki.

Nascondere cartelle e file a partire da "." nell'albero wiki

Fino a questo momento, l'albero wiki mostra tutte le cartelle e i file a partire da un punto (.) nell'albero wiki. Negli scenari wiki del codice, le cartelle come .vscode, che devono essere nascoste, vengono visualizzate nell'albero wiki. A questo punto, tutti i file e le cartelle che iniziano con un punto rimarranno nascosti nell'albero wiki, riducendo quindi il disordine non necessario.

Questa funzionalità è stata prioritaria in base a questo ticket di suggerimento.

URL della pagina Wiki breve e leggibile

Non è più necessario usare un URL multilinea per condividere i collegamenti di pagina wiki. Gli ID pagina vengono sfruttati nell'URL per rimuovere i parametri, rendendo quindi l'URL più breve e più semplice da leggere.

La nuova struttura degli URL avrà un aspetto simile al seguente:

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

Questo è un esempio del nuovo URL per una pagina Wiki di Azure DevOps :

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

Questa priorità è stata assegnata in base a questo ticket di suggerimento di funzionalità dal Developer Community.

Scorrimento sincrono per la modifica delle pagine wiki

La modifica delle pagine wiki è ora più semplice con lo scorrimento sincrono tra la modifica e il riquadro di anteprima. Lo scorrimento su un lato scorre automaticamente l'altro lato per mappare le sezioni corrispondenti. È possibile disabilitare lo scorrimento sincrono con il pulsante disattiva.

Screenshot della barra degli strumenti wiki con l'icona di scorrimento synchronus chiamata e il pulsante Disabilita scorrimento sincronizzato sopra di esso.

Nota

Lo stato dell'interruttore di scorrimento sincrono viene salvato per utente e account.

Visite di pagine per le pagine wiki

È ora possibile ottenere informazioni dettagliate sulle visite di pagina per le pagine wiki. L'API REST consente di accedere alle informazioni sulle visite della pagina negli ultimi 30 giorni. È possibile usare questi dati per creare report per le pagine wiki. È inoltre possibile archiviare questi dati nell'origine dati e creare dashboard per ottenere informazioni dettagliate specifiche come le pagine più visualizzate.

Verrà inoltre visualizzato un conteggio delle visite di pagina aggregato per gli ultimi 30 giorni in ogni pagina.

Screenshot che mostra le visite precedenti per una pagina wiki.

Nota

Una visita di pagina viene definita come visualizzazione di pagina da parte di un determinato utente in un intervallo di 15 minuti.

Creazione di report

Report relativi a errori e durata della pipeline

Le metriche e le informazioni dettagliate consentono di migliorare continuamente la velocità effettiva e la stabilità delle pipeline. Sono stati aggiunti due nuovi report per fornire informazioni dettagliate sulle pipeline.

  1. Il report degli errori della pipeline mostra la frequenza di passaggio della compilazione e la tendenza degli errori. Inoltre, mostrerà anche la tendenza degli errori delle attività per fornire informazioni dettagliate su quale attività nella pipeline contribuisce al numero massimo di errori.

Screenshot che mostra la scheda Analisi che visualizza il badge della frequenza di passaggio della pipeline, il badge della frequenza di passaggio test e il badge della durata della pipeline.

Screenshot che mostra il report di errore della pipeline.

  1. Il report durata della pipeline mostra la tendenza del tempo impiegato per l'esecuzione di una pipeline. Mostra anche quali attività nella pipeline richiedono la maggior parte del tempo.

Miglioramento del widget Risultati query

Il widget dei risultati della query è uno dei widget più diffusi e per una buona ragione. Il widget visualizza i risultati di una query direttamente nel dashboard ed è utile in molte situazioni.

Con questo aggiornamento sono stati inclusi molti miglioramenti previsti:

  • È ora possibile selezionare tutte le colonne da visualizzare nel widget. Nessun limite di 5 colonne!
  • Il widget supporta tutte le dimensioni, da 1x1 a 10x10.
  • Quando si ridimensiona una colonna, la larghezza della colonna verrà salvata.
  • È possibile espandere il widget in visualizzazione a schermo intero. Quando espansa, verrà visualizzata tutte le colonne restituite dalla query.

Widget Lead and Cycle Time avanzati di filtro

Il tempo di lead e ciclo viene usato dai team per verificare il tempo necessario per il lavoro per il flusso attraverso le pipeline di sviluppo e, in definitiva, offrire valore ai clienti.

Fino a questo momento, i widget di tempo di lead e ciclo non supportavano criteri di filtro avanzati per porre domande come: "Quanto tempo richiede al team di chiudere gli elementi con priorità più alta?"

Con queste domande di aggiornamento come questa può essere risposta filtrando sul nuoto board.

Screenshot che mostra la finestra di dialogo Configurazione con la sezione Swimlane chiamata.

Sono stati inclusi anche i filtri degli elementi di lavoro per limitare gli elementi di lavoro visualizzati nel grafico.

Screenshot che mostra la finestra di dialogo Configurazione con la sezione Criteri campo chiamata.

Burndown sprint inline usando i punti della storia

Il tuo Sprint Burndown può ora bruciare da Storie. In questo modo viene visualizzato il feedback del Developer Community.

Nell'hub Sprint selezionare la scheda Analisi. Configurare quindi il report come indicato di seguito:

  1. Selezionare Backlog Storie
  2. Selezionare per il burndown sulla somma dei punti di storia

Screenshot che mostra il burndown sprint inline usando i punti della storia.

Widget Sprint Burndown con tutto ciò che si sta chiedendo

Il nuovo widget Sprint Burndown supporta la combustione in base ai punti story, al conteggio delle attività o alla somma di campi personalizzati. È anche possibile creare un burndown sprint per Funzionalità o Epics. Il widget visualizza un burndown medio, % completo e un aumento dell'ambito. È possibile configurare il team, consentendo di visualizzare i burndown sprint per più team nello stesso dashboard. Con tutte queste informazioni utili da visualizzare, è possibile ridimensionarla fino a 10x10 nel dashboard.

Sceenshot che mostra il nuovo widget Sprint Burndown.

Per provarlo, è possibile aggiungerlo dal catalogo dei widget oppure modificando la configurazione per il widget Sprint Burndown esistente e selezionando la casella Prova la nuova versione.

Nota

Il nuovo widget usa Analytics. Il burndown sprint legacy è stato mantenuto nel caso in cui non si abbia accesso ad Analytics.

Anteprima del burndown sprint inline

Lo Sprint Burndown è tornato! Qualche sprint fa, abbiamo rimosso il burndown sprint nel contesto dall'intestazione Sprint Burndown e Taskboard. In base al feedback, abbiamo migliorato e reintrodotto l'anteprima dello sprint burndown.

Screenshot che mostra l'anteprima inline sprint burndown.

Facendo clic sull'anteprima verrà visualizzata immediatamente una versione più ampia del grafico con un'opzione per visualizzare il report completo nella scheda Analisi. Tutte le modifiche apportate al report completo verranno riflesse nel grafico visualizzato nell'intestazione. È quindi possibile configurarlo per il burn-down in base a storie, punti storia o conteggio delle attività, anziché solo alla quantità di lavoro rimanente.

Creare un dashboard senza un team

È ora possibile creare un dashboard senza associarlo a un team. Quando si crea un dashboard, selezionare il tipo di dashboard del progetto .

Screenshot che mostra la finestra di dialogo Crea un dashboard con l'opzione Dashboard progetto selezionata ed evidenziata.

Un dashboard del progetto è simile a un dashboard del team, ad eccezione del fatto che non è associato a un team ed è possibile decidere chi può modificare/gestire il dashboard. Proprio come un dashboard del team, è visibile a tutti gli utenti del progetto.

Tutti i widget di Azure DevOps che richiedono un contesto del team sono stati aggiornati per consentire di selezionare un team nella configurazione. È possibile aggiungere questi widget ai dashboard del progetto e selezionare il team specifico desiderato.

Screenshot dell'elenco a discesa Team.

Nota

Per i widget personalizzati o di terze parti, un dashboard di progetto passerà il contesto del team predefinito a tali widget. Se si dispone di un widget personalizzato basato sul contesto del team, è necessario aggiornare la configurazione per consentire di selezionare un team.


Commenti e suggerimenti

Le opinioni dei nostri clienti sono molto importanti per noi. È possibile segnalare un problema o fornire un'idea e monitorarla tramite Developer Community e ottenere consigli su Stack Overflow.


Inizio pagina