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.

Azure DevOps Server 2020 Update 0.2 Patch 6 Data di rilascio: 14 novembre 2023

È stata rilasciata una patch per Azure DevOps Server 2020 Update 0.2 che include correzioni per quanto segue.

• Estensione dell'elenco di caratteri consentiti delle attività di PowerShell per Abilitare la convalida dei parametri delle attività della shell.

Nota

Per implementare le correzioni per questa patch, è necessario seguire una serie di passaggi per aggiornare manualmente le attività.

Installare patch

Importante

Sono stati rilasciati aggiornamenti all'agente di Azure Pipelines con patch 4 rilasciati il 12 settembre 2023. Se gli aggiornamenti dell'agente non sono stati installati come descritto nelle note sulla versione per Patch 4, è consigliabile installare questi aggiornamenti prima di installare patch 6. La nuova versione dell'agente dopo l'installazione di Patch 4 sarà 3.225.0.

Configurare TFX

1. Seguire la procedura descritta nella documentazione di caricamento della raccolta di progetti per installare e accedere con tfx-cli.

Aggiornare le attività con TFX

File	Hash SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Scaricare ed estrarre Tasks20231103.zip.
2. Modificare la directory nei file estratti.
3. Eseguire i comandi seguenti per caricare le attività:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

Requisiti della pipeline

Per usare il nuovo comportamento, una variabile deve essere impostata AZP_75787_ENABLE_NEW_LOGIC = true nelle pipeline che usano le attività interessate.

• In versione classica:

  Definire la variabile nella scheda variabile nella pipeline.

• Esempio YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 0.2 Patch 5 Data di rilascio: 10 ottobre 2023

Importante

Sono stati rilasciati aggiornamenti all'agente di Azure Pipelines con patch 4 rilasciati il 12 settembre 2023. Se gli aggiornamenti dell'agente non sono stati installati come descritto nelle note sulla versione per Patch 4, è consigliabile installare questi aggiornamenti prima di installare Patch 5. La nuova versione dell'agente dopo l'installazione di Patch 4 sarà 3.225.0.

È stata rilasciata una patch per Azure DevOps Server 2020 Update 0.2 che include correzioni per quanto segue.

• Correzione di un bug in cui l'identità "Analysis Owner" viene visualizzata come Identità inattiva nei computer di aggiornamento delle patch.

Azure DevOps Server 2020 Update 0.2 Patch 4 Data di rilascio: 12 settembre 2023

È stata rilasciata una patch per Azure DevOps Server 2020 Update 0.2 che include correzioni per quanto segue.

• CVE-2023-33136: Azure DevOps Server vulnerabilità di esecuzione del codice remoto.
• CVE-2023-38155: Azure DevOps Server e l'elevazione dei privilegi di Team Foundation Server.

Importante

Distribuire la patch in un ambiente di test e assicurarsi che le pipeline dell'ambiente funzionino come previsto prima di applicare la correzione alla produzione.

Nota

Per implementare le correzioni per questa patch, è necessario seguire una serie di passaggi per aggiornare manualmente l'agente e le attività.

Installare patch

1. Scaricare e installare Azure DevOps Server 2020 Update 0.2 patch 4.

Aggiornare l'agente di Azure Pipelines

1. Scaricare l'agente da: - https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 Agent_20230825.zip
2. Usare i passaggi descritti nella documentazione degli agenti Windows self-hosted per distribuire l'agente.  

Nota

Il AZP_AGENT_DOWNGRADE_DISABLED deve essere impostato su "true" per impedire che l'agente venga sottoposto a downgrade. In Windows, il comando seguente può essere usato in un prompt dei comandi amministrativi, seguito da un riavvio. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Configurare TFX

1. Seguire la procedura descritta nella documentazione di caricamento della raccolta di progetti per installare e accedere con tfx-cli.

Aggiornare le attività con TFX

1. Scaricare ed estrarre Tasks_20230825.zip.
2. Modificare la directory nei file estratti.
3. Eseguire i comandi seguenti per caricare le attività:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

Requisiti della pipeline

Per usare il nuovo comportamento, una variabile deve essere impostata AZP_75787_ENABLE_NEW_LOGIC = true nelle pipeline che usano le attività interessate.

• In versione classica:

  Definire la variabile nella scheda variabile nella pipeline.

• Esempio YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 0.2 Patch 3 Data di rilascio: 8 agosto 2023

È stata rilasciata una patch per Azure DevOps Server 2020 Update 0.2 che include correzioni per quanto segue.

• Correzione di un bug che interferisce con il push di pacchetti durante l'aggiornamento da 2018 o versioni precedenti.

Azure DevOps Server 2020 Update 0.2 Patch 2 Data di rilascio: 13 giugno 2023

È stata rilasciata una patch per Azure DevOps Server 2020 Update 0.2 che include correzioni per quanto segue.

• Correzione di un bug che interferisce con il push di pacchetti durante l'aggiornamento da 2018 o versioni precedenti.

Azure DevOps Server 2020 Update 0.2 Patch 1 Data di rilascio: 18 ottobre 2022

È stata rilasciata una patch per Azure DevOps Server 2020 Update 0.2 che include correzioni per quanto segue.

• Risolvere il problema con le identità di Active Directory appena aggiunte che non vengono visualizzate nei selettore identità della finestra di dialogo di sicurezza.
• Risolvere un problema relativo al filtro Membro del gruppo nelle impostazioni dell'hook Web.
• Correzione dell'errore di compilazione del check-in gated quando le impostazioni dell'organizzazione per la pipeline avevano l'ambito di autorizzazione del processo configurato come Limite dell'ambito di autorizzazione del processo al progetto corrente per le pipeline non rilasciate.

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 aggiornare 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 TF400813 errore 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: B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

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 dispone di 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.

• CVE-2021-27067: divulgazione delle informazioni
• CVE-2021-28459: Elevazione dei privilegi

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

Installare

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

4. 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 .

5. 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

6. 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

Installare

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

4. 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 .

5. 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

6. Eseguire il comando seguente per caricare l'attività nel server. Usare il percorso del file .zip estratto dal passaggio 1.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2020.0.1 Patch 1 Data di rilascio: 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.

• Risolvere il problema segnalato in questo ticket di feedback Developer Community| Nuovo pulsante Test Case non funzionante
• Includere le correzioni rilasciate con Azure DevOps Server 2020 Patch 2.

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.

• Risolvere il problema segnalato in questo ticket di feedback Developer Community| Nuovo pulsante Test Case non funzionante

Azure DevOps Server 2020.0.1 Data di rilascio: 19 gennaio 2021

Azure DevOps Server 2020.0.1 è un rollup di correzioni di bug. È possibile installare direttamente Azure DevOps Server 2020.0.1 o eseguire l'aggiornamento 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 smettere di funzionare 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.
• Correzione dell'errore di nome di colonna non valido in Analytics durante l'aggiornamento a Azure DevOps Server 2020. Risolve il problema segnalato in questo ticket di feedback Developer Community.
• XSS archiviato quando vengono visualizzati i passaggi del test case nei risultati del test case.
• Errore del passaggio di aggiornamento durante la migrazione dei dati dei risultati 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 dell'esecuzione dei test non visualizzano i dettagli dei passaggi di test per i dati di test migrati tramite la migrazione di OpsHub
• Eccezione nell'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 Data: 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à di spoofing di Azure DevOps Server e Team Foundation Services

data di rilascio Azure DevOps Server 2020: 6 ottobre 2020

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

Nota

Azure DevOps 2020 Server presenta 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 finale di Azure DevOps 2020 e si installa nella stessa directory della versione precedente, l'assembly Microsoft.TeamFoundation.Git.dll non verrà installato. È possibile verificare di aver riscontrato il problema cercando Microsoft.TeamFoundation.Git.dll in <Install Dir>\Version Control Proxy\Web Services\bin, <Install Dir>\Application Tier\TFSJobAgent e <Install Dir>\Tools cartelle. Se il file non è presente, è possibile eseguire un ripristino per ripristinare i file mancanti.

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

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

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

Azure DevOps Server 2020 RC1 re-release Date: 10 luglio 2020

Microsoft ha ri-rilasciato 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 in 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:

• Pipeline in più fasi
• Distribuzione continua in YAML
• Tenere traccia dello stato di avanzamento degli elementi padre usando rollup nel backlog boards
• Aggiungere il filtro "Elemento di lavoro padre" alla scheda attività e al backlog dello sprint
• Nuova interfaccia utente Web per Azure Repos pagine di destinazione
• Amministrazione dei criteri dei rami tra repository
• Pagina Nuovo piano di test
• Modifica avanzata per le pagine wiki del codice
• Report relativi a errori e durata della pipeline

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

• Generale
• Boards
• Repos
• Pipeline
• Test Plans
• Elementi
• Wiki
• Reporting

---

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. Sono stati raccolti commenti e suggerimenti che hanno consentito di migliorare l'estensione e aggiungere altri comandi. 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 su 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 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 dello 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) in base all'elemento padre. Ad esempio, nella schermata seguente è stata filtrata la visualizzazione per mostrare solo le storie utente in cui l'elemento padre è "My big feature".

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

In passato, dalla scheda Kanban, se un elemento di lavoro è stato spostato da una colonna a un'altra in cui la modifica dello stato ha attivato le regole dei campi, la scheda visualizza semplicemente un messaggio di errore rosso che forza l'apertura dell'elemento di lavoro per comprendere la causa radice. Nello 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.

Ricaricamento attivo degli elementi di lavoro

In precedenza, durante l'aggiornamento di 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 modifichi entrambi campi diversi, verranno visualizzati gli aggiornamenti in tempo reale delle modifiche apportate all'elemento di lavoro.

Gestire i percorsi di iterazione e area dalla riga di comando

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

Opzione colonna padre elemento di lavoro come colonna

È ora possibile visualizzare l'elemento padre di ogni elemento di lavoro nel backlog del prodotto o nel backlog dello sprint. Per abilitare questa funzionalità, passare a Opzioni colonna nel backlog desiderato e quindi aggiungere la colonna Padre .

Modificare il processo usato da un progetto

Gli strumenti dovrebbero cambiare man mano che il team esegue questa operazione, è ora possibile passare da qualsiasi modello di processo predefinito a qualsiasi altro processo predefinito. Ad esempio, è possibile modificare il progetto da Agile a Scrum o Basic a Agile. La documentazione dettagliata è disponibile qui.

Nascondere campi personalizzati dal layout

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

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

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

I tre nuovi report interattivi sono: Burndown, Cumulative Flow Diagram (CFD) e Velocity. È possibile visualizzare i report nella nuova scheda di analisi.

Le metriche come il burn-down sprint, il flusso di lavoro e la velocità del team offrono visibilità sullo stato di avanzamento del team e consentono di rispondere a domande come:

• 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 è necessario 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 burn-down è disponibile nell'hub Sprint.

  

• È possibile accedere ai report CFD e Velocity dalla scheda Analisi in Boards e Backlog facendo clic sulla scheda pertinente.

  

Con i nuovi report si hanno più controllo e informazioni sul team. Ecco alcuni esempi:

• I report Sprint Burndown e Velocity possono essere impostati per usare il conteggio degli elementi di lavoro o la somma del lavoro rimanente.
• È possibile modificare l'intervallo di tempo del burndown dello sprint senza influire sulle date del progetto. Pertanto, se il team trascorre in genere il primo giorno di ogni pianificazione dello sprint, è ora possibile trovare una corrispondenza con il grafico per riflettere tale situazione.
• Il grafico Burndown ha ora una filigrana che mostra i fine settimana.
• Il report CFD consente di rimuovere le colonne della lavagna, ad esempio Progettazione, per concentrarsi maggiormente 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 Stories.

È ora possibile tenere traccia del grafico Velocità per tutti i livelli di backlog. Ad esempio, è ora possibile aggiungere sia funzionalità che epiche, mentre prima del grafico precedente sono supportati solo i requisiti. Di seguito è riportato un esempio di report sulla velocità per le ultime 6 iterazioni del backlog Funzionalità.

Personalizzare le colonne taskboard

Microsoft è lieta di annunciare che è stata aggiunta un'opzione che consente di 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.

Questa funzionalità è stata assegnata in ordine di priorità in base a un suggerimento del Developer Community.

Attiva/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. È ora possibile visualizzare o nascondere gli elementi figlio completati nel backlog.

Se l'interruttore è attivato, 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.

Tag più recenti visualizzati quando si contrassegna un elemento di lavoro

Quando si contrassegna un elemento di lavoro, l'opzione di completamento automatico ora visualizza fino a cinque dei tag usati più di recente. In questo modo sarà più semplice aggiungere le informazioni corrette agli elementi di lavoro.

Regole di sola lettura e obbligatorie per l'appartenenza ai gruppi

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

Personalizzare i valori dell'elenco a discesa di sistema

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

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 nella scheda, nel backlog o nello sprint aggiungendo il parametro ?workitem=[ID] all'URL.

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

Menzionare persone, elementi di lavoro e richieste pull nei campi di testo

Durante l'ascolto dei commenti e suggerimenti, abbiamo sentito che hai voluto menzionare persone, elementi di lavoro e richieste pull nell'area di descrizione degli elementi di lavoro (e altri campi HTML) sull'elemento di lavoro e non solo nei commenti. In alcuni casi si collabora con un utente su un elemento di lavoro o si vuole evidenziare una richiesta pull nella descrizione dell'elemento di lavoro, ma non è stato possibile aggiungere tali informazioni. È ora possibile menzionare persone, elementi di lavoro e richieste pull in tutti i campi di testo lunghi nell'elemento di lavoro.

Un esempio è disponibile qui.

• Per usare menzioni di persone, digitare il @ segno e il nome della persona che si desidera menzionare. @mentions nei campi dell'elemento di lavoro genererà notifiche tramite posta elettronica come le operazioni che esegue per i commenti.
• Per usare le menzioni degli elementi di lavoro, digitare il # segno seguito dall'ID o dal titolo dell'elemento di lavoro. #mentions creerà un collegamento tra i due elementi di lavoro.
• Per usare le menzioni pull, aggiungere un valore ! seguito dall'ID o dal nome della richiesta pull.

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.

È possibile aggiungere reazioni a qualsiasi commento e ci sono due modi per aggiungere le tue reazioni: l'icona sorridente nell'angolo superiore destro di qualsiasi commento, nonché nella parte inferiore di un commento accanto a eventuali reazioni esistenti. È possibile aggiungere tutte e sei le reazioni se si preferisce, o solo una o due. Per rimuovere la tua reazione, clicca sulla reazione nella parte inferiore del commento e verrà rimossa. Di seguito è possibile vedere l'esperienza di aggiunta di una reazione, nonché l'aspetto delle reazioni su un commento.

Aggiungere Azure Boards report 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 Boards 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.

Tenere traccia dello stato di avanzamento degli elementi padre usando rollup nel backlog 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. È possibile aggiungere una o più colonne di rollup a un backlog di prodotto o portfolio.

Di seguito, ad esempio, viene mostrato Stato per elementi di lavoro che visualizza le barre di stato per gli elementi di lavoro ascendenti in base alla percentuale di elementi discendenti chiusi. Gli elementi discendenti per Epics includono tutte le funzionalità figlio e i relativi elementi di lavoro figlio o figlio. Gli elementi discendenti per Funzionalità includono tutte le storie utente figlio e i relativi elementi di lavoro figlio.

Aggiornamenti live di Taskboard

L'elenco attività viene ora aggiornato automaticamente quando si verificano modifiche. Man mano che altri membri del team spostano o riordinano le schede nella scheda attività, la scheda verrà aggiornata 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 il 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 il rollup in campi numerici che non fanno parte del modello di processo predefinito, è possibile configurare il proprio come segue:

1. Nel backlog fare clic su "Opzioni colonna". Nel pannello fare quindi clic su "Aggiungi colonna rollup" e configurare l'aggiornamento cumulativo personalizzato.

   

2. Selezionare l'indicatore di stato e il totale.
3. Selezionare un tipo di elemento di lavoro o un livello backlog (in genere i backlog aggregano diversi tipi di elementi di lavoro).
4. Selezionare il tipo di aggregazione. Conteggio degli elementi di lavoro o Sum. Per Sum è necessario selezionare il campo da riepilogare.
5. Il pulsante OK consente di tornare al pannello delle opzioni della colonna in cui è possibile riordinare 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 aggiungerne un'altra come desiderato.

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

È stata aggiunta una nuova regola al motore regole ereditato per consentire di nascondere i campi in un modulo dell'elemento di lavoro. Questa regola nasconde i campi in base all'appartenenza al gruppo utenti. Ad esempio, se l'utente appartiene al gruppo "proprietario del prodotto", è possibile nascondere un campo specifico dello sviluppatore. Per altri dettagli, 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 tenere traccia dei progetti e assicura che tutte le parti giuste siano coinvolte. Tuttavia, i diversi stakeholder hanno diversi livelli di investimento in diversi sforzi e riteniamo che dovrebbe riflettersi nella vostra capacità di seguire lo stato di un elemento di lavoro.

In precedenza, se si desidera seguire un elemento di lavoro e ricevere notifiche su tutte le modifiche apportate, si riceveranno notifiche tramite posta elettronica per qualsiasi e tutte le modifiche apportate all'elemento di lavoro. Dopo aver considerato i commenti e i suggerimenti, microsoft sta rendendo più flessibile l'esecuzione di un elemento di lavoro per tutti gli stakeholder. Verrà ora visualizzato un nuovo pulsante impostazioni accanto al pulsante Segui nell'angolo superiore destro dell'elemento di lavoro. Verrà visualizzata una finestra popup che consentirà di configurare le opzioni seguenti.

In Impostazioni di notifica è possibile scegliere tra tre opzioni di notifica. In primo luogo, è possibile annullare completamente la sottoscrizione. In secondo luogo, è possibile essere completamente sottoscritti, in cui si ricevono notifiche per tutte le modifiche apportate agli elementi di lavoro. Infine, è possibile scegliere di ricevere una notifica per alcuni degli eventi di modifica principali e cruciali degli elementi di lavoro. È possibile selezionare solo una o tutte e tre le opzioni. In questo modo i membri del team seguiranno gli elementi di lavoro a un livello superiore e non verranno distratti da ogni singola modifica apportata. Con questa funzionalità, elimineremo i messaggi di posta elettronica non necessari e ti permetterà di concentrarsi sulle attività cruciali a portata di mano.

Collegare elementi di lavoro alle distribuzioni

Microsoft è lieta 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.

Importare elementi di lavoro da un file CSV

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

Aggiungere un campo padre alle schede degli elementi di lavoro

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

Aggiungere un 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 .

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 pull request (PR). In questo modo si garantisce di avere testato adeguatamente le modifiche tramite test automatizzati. Lo stato della copertura verrà visualizzato come commento nella panoramica della richiesta pull. È possibile visualizzare i dettagli delle informazioni di copertura per ogni riga di codice modificata nella visualizzazione differenze file.

Inoltre, i proprietari dei repository possono ora impostare criteri di code coverage e impedire l'unione di modifiche di grandi dimensioni e non sottoposte a test in un ramo. È possibile definire le soglie di copertura desiderate in un azurepipelines-coverage.yml file di impostazioni archiviato nella radice del repository e dei criteri di copertura usando i criteri di configurazione esistenti di un ramo per funzionalità aggiuntive dei servizi in Azure Repos.

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 in alto a destra e passando a Impostazioni utente.

Hook del servizio per i commenti delle richieste pull

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

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 che corrispondono al modello specificato.

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.

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 .

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.

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.

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.

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

Dispositivi mobili

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.

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:

Esperienza per dispositivi mobili:

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.

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.

Miglioramento dell'azione pr

Quando si hanno molte richieste pull da esaminare, comprendere dove eseguire l'azione prima può essere difficile. Per migliorare l'azione delle richieste pull, è ora possibile creare più query personalizzate nella pagina elenco richieste pull con diverse nuove opzioni da filtrare, ad esempio lo stato bozza. Queste query creeranno sezioni separate e collapible nella pagina della richiesta pull oltre a "Create by me" e "Assigned to me". È anche possibile rifiutare di esaminare una richiesta pull aggiunta tramite il menu Voto o il menu di scelta rapida nella pagina elenco richieste pull. Nelle sezioni personalizzate verranno ora visualizzate schede separate per le richieste pull fornite o rifiutate per 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 a più fasi

Si è lavorato su 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 mettono insieme pipeline di compilazione classiche e pipeline YAML a più fasi in un'unica esperienza. È compatibile con 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 tutto il modo indietro nei log mentre una pipeline è ancora in corso
• Integrità per ramo di una pipeline.

Distribuzione continua in YAML

Siamo lieti di fornire funzionalità YAML di Azure Pipelines. Ora offriamo un'esperienza YAML unificata in modo da poter configurare ognuna delle pipeline in modo da eseguire insieme CI, CD o CI e CD. Le funzionalità di YAML CD introducono diverse nuove funzionalità avanzate disponibili per tutte le raccolte usando pipeline YAML a più fasi. Tra le caratteristiche principali:

• Pipeline YAML a più fasi (per CI e CD)
• Approvazioni e controlli sulle risorse
• Ambienti e strategie di distribuzione
• Risorse di Kubernetes e macchina virtuale nell'ambiente
• Esaminare le app per la collaborazione
• Esperienza utente aggiornata per le connessioni al servizio
• Risorse nelle pipeline YAML

Se si è pronti per iniziare a creare, 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 le variabili nelle pipeline YAML.

Approvare le versioni direttamente dall'hub release

L'azione sulle approvazioni in sospeso è stata semplificata. Prima, è stato possibile approvare una versione dalla pagina dei dettagli della versione. È ora possibile approvare le versioni direttamente dall'hub Release.

Miglioramenti apportati all'introduzione alle pipeline

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 altro nome file o percorso prima di salvare la pipeline.

Infine, si avrà più controllo quando si controlla 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 si esegue la modalità per le pipeline YAML. È ora possibile provare una pipeline YAML senza eseguirne il commit in un repository o eseguirlo. Dato 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 rendering DI YAML.

Pianificazioni di 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: è possibile definire pianificazioni più espressive 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 facile 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.

Aggiornamenti all'interfaccia utente delle connessioni al servizio

Si è lavorato su 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. È stata introdotta 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 fornito il loro prezioso feedback a noi.

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

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

Nota

Si prevede di introdurre la condivisione tra progetti di connessioni al servizio come nuova funzionalità. Per altre informazioni sull'esperienza di condivisione e sui ruoli di sicurezza , vedere qui.

Ignorare le fasi in una pipeline YAML

Quando si avvia un'esecuzione manuale, a volte si vuole ignorare alcune fasi nella pipeline. Ad esempio, se non si vuole distribuire in produzione o se si vuole ignorare la distribuzione in alcuni ambienti 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 è possibile ignorare una o più fasi. È necessario prestare attenzione quando si ignorano le fasi. Ad esempio, se la prima fase produce determinati artefatti necessari per le fasi successive, non è consigliabile ignorare la prima fase. Il pannello di esecuzione presenta un avviso generico ogni volta che si ignorano le fasi con dipendenze downstream. È lasciato a voi come stabilire se queste dipendenze sono dipendenze di artefatto vere o se sono presenti solo per la sequenza delle distribuzioni.

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

Connessioni al servizio nuova interfaccia utente come esperienza predefinita

È disponibile una nuova interfaccia utente delle 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.

Altre informazioni sulle connessioni al servizio sono disponibili qui.

Selezione della versione della risorsa della 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.

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 per creare 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 di 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.

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 pacchetti NuGet 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. Attualmente il supporto è disponibile solo per l'utilizzo di pacchetti da GitHub, ma in futuro si prevede di estendere il supporto per l'uso 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

Attualmente 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 rimossa questa limitazione, verrà fornito il supporto per altri tipi di autenticazione.

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

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

collegamento servizio Azure Kubernetes cluster nella visualizzazione risorse degli ambienti Kubernetes

È stato aggiunto un collegamento alla visualizzazione 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 in servizio Azure Kubernetes cluster.

Filtri delle cartelle di rilascio nelle sottoscrizioni di notifica

Le cartelle consentono di organizzare le pipeline per facilitare l'individuazione 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, era necessario configurare più sottoscrizioni o eseguire query complesse nelle sottoscrizioni per ottenere messaggi di posta elettronica mirati. Con questo aggiornamento, è ora possibile aggiungere una clausola della cartella di versione alla distribuzione completata e approvare gli eventi in sospeso e semplificare le sottoscrizioni.

Collegare elementi di lavoro con pipeline YAML a più fasi

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 assocerà 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 un'esecuzione di 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. Ciò è utile se si sa che la fase avrà esito negativo o se si dispone di un'altra esecuzione che si vuole avviare.

Ripetizione delle fasi non riuscite

Una delle funzionalità più richieste nelle pipeline in più fasi è la possibilità di ripetere una fase non riuscita senza dover iniziare dall'inizio. Con questo aggiornamento, viene aggiunta una parte importante di questa funzionalità.

È ora possibile ripetere una fase della pipeline quando l'esecuzione ha esito negativo. Tutti i processi non riusciti nel primo tentativo e quelli che dipendono transitivamente da tali processi non riusciti vengono tutti tentati di nuovo.

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 superano, è possibile risparmiare tempo senza eseguire di nuovo i processi superati. Come altro esempio, è possibile che una fase di distribuzione non sia riuscita a causa di una connessione di rete non riuscita. La ripetizione di questa fase consente di risparmiare tempo senza dover 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 colmare queste lacune negli aggiornamenti futuri.

Approvazioni nelle pipeline YAML in 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 di distribuzione in qualsiasi pipeline. Con la separazione completa dei ruoli tra i proprietari dell'infrastruttura (ambiente) e dell'applicazione (pipeline), si garantisce la disconnettezione manuale per la distribuzione in una particolare pipeline e si ottiene il controllo centrale nell'applicazione degli stessi controlli in tutte le distribuzioni all'ambiente.

Le esecuzioni della pipeline distribuite nello sviluppo verranno arrestate per l'approvazione all'inizio della fase.

Aumento del limite e della frequenza di timeout di gate

In precedenza, il limite di timeout di controllo nelle pipeline di versione era di tre giorni. Con questo aggiornamento, il limite di timeout è stato aumentato a 15 giorni per consentire i controlli 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 creazione di una nuova pipeline, è consigliabile 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 dover eseguire il push in un registro contenitori.

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 le app Web, le app per le funzioni o qualsiasi altro servizio app in contenitori.

Servizio app di Azure ora supporta lo scambio con anteprima

Servizio app di Azure supporta ora lo scambio con anteprima nei relativi 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 anche che lo slot di destinazione/produzione non subisca tempi di inattività.

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

• Avvia scambio con anteprima : avvia uno scambio con un'anteprima (scambio in più fasi) e applica la configurazione dello 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.

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 versione. Ora sono stati aggiunti anche a livello di fase.

Miglioramenti alle approvazioni nelle pipeline YAML

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

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

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 il 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 dei file e test dei metadati. È possibile usare i risultati nella pipeline per prendere decisioni go/no go. 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

Dati di test e riepilogo

Elementi Decorator della pipeline per le pipeline di versione

Gli elementi decorator 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 elementi Decorator per le compilazioni e le pipeline YAML, con i clienti che li usano per controllare centralmente i passaggi nei processi. È ora in corso l'estensione del supporto anche per le pipeline di rilascio. È possibile creare estensioni per aggiungere passaggi destinati al nuovo punto di contributo e verranno aggiunti a tutti i processi dell'agente nelle pipeline di versione.

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

In precedenza, le distribuzioni sono supportate solo a livello di gruppo di risorse. Con questo aggiornamento è stato aggiunto il supporto per distribuire modelli di Resource Manager sia ai livelli della sottoscrizione che dei gruppi di gestione. Ciò consente di distribuire insieme un set di risorse, ma di inserirle 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 in più fasi

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

Di seguito è riportato 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/*  

È anche 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 altri dettagli, vedere la documentazione relativa al download degli artefatti qui.

Orchestrare la strategia di distribuzione canary nell'ambiente per Kubernetes

Uno dei vantaggi principali del recapito continuo degli aggiornamenti delle applicazioni è la possibilità di eseguire rapidamente il push degli aggiornamenti nell'ambiente di produzione per microservizi specifici. In questo modo è possibile rispondere rapidamente ai cambiamenti dei requisiti aziendali. L'ambiente è stato introdotto come concetto di prima classe che abilita l'orchestrazione delle strategie di distribuzione e facilita le versioni senza tempi di inattività. 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 a più fasi, è ora possibile ridurre il rischio implementando lentamente la modifica in un piccolo subset. Man mano che si ottiene maggiore fiducia nella nuova versione, è possibile iniziare a implementarlo in più server nell'infrastruttura e indirizzare più utenti ad 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 distribuirà prima le modifiche con il 10% dei pod seguiti dal 20% durante il monitoraggio dell'integrità durante postRouteTraffic. Se tutto va bene, verrà promosso al 100%.

Microsoft sta cercando un feedback tempestivo sul supporto per le risorse delle macchine virtuali negli ambienti e sull'esecuzione di una strategia di distribuzione in sequenza tra più computer. Contattaci per registrarsi.

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 per la risorsa e tutte le pipeline che usano la risorsa sospendono le approvazioni prima dell'inizio della fase che usa la risorsa. È comune che i proprietari di applicazioni basati su SOX limitino il richiedente della distribuzione ad approvare le proprie distribuzioni.

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

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 viene pubblicata una nuova immagine, è possibile usare la risorsa contenitore del Registro Azure Container.

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 metadati 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 controlli degli artefatti nei criteri nelle pipeline

Il controllo valuta artefatto è stato migliorato per semplificare l'aggiunta di criteri da un elenco di definizioni dei criteri predefinite. La definizione dei criteri verrà generata automaticamente e aggiunta alla configurazione del controllo che può essere aggiornata, se necessario.

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 i 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-processo

Evitare il rollback delle modifiche critiche

Nelle pipeline di versione classica è comune basarsi sulle distribuzioni pianificate per gli aggiornamenti regolari. Tuttavia, quando si dispone di 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é il rollback della distribuzione manuale verrebbe eseguito quando le distribuzioni sono riprese in base alla pianificazione. Molti di voi hanno segnalato questo problema e ora è stato risolto. Con la correzione, tutte le distribuzioni pianificate meno recenti nell'ambiente verrebbero annullate quando si avvia manualmente una distribuzione. Questa opzione è applicabile solo quando l'opzione di accodamento è selezionata come "Deploy latest and cancel others".

Autorizzazione semplificata delle risorse nelle pipeline YAML

Una risorsa è qualsiasi risorsa usata da una pipeline esterna alla pipeline. Le risorse devono essere autorizzate prima di poterle usare. In precedenza, quando si usano risorse non autorizzate in una pipeline YAML, si è verificato un errore di autorizzazione della risorsa. È stato necessario autorizzare le risorse dalla pagina di riepilogo dell'esecuzione non riuscita. Inoltre, la pipeline non è riuscita se usava una variabile che fa riferimento a una risorsa non autorizzata.

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

Valutare il controllo degli artefatti

È ora possibile definire un set di criteri e aggiungere la valutazione dei criteri come controllo in 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. I criteri specificati vengono valutati in base ai metadati disponibili per l'immagine da distribuire. Il controllo viene superato quando il criterio ha esito positivo e contrassegna la fase come non riuscita se il controllo ha esito negativo.

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

In precedenza, le connessioni al servizio non sono stati filtrate nell'attività di distribuzione del modello di Resource Manager. Ciò può causare l'esito negativo della distribuzione se si seleziona una connessione al 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 al servizio con ambito inferiore in base all'ambito di distribuzione scelto.

ReviewApp in Environment

ReviewApp distribuisce ogni richiesta pull dal repository Git a una risorsa ambiente dinamica. I revisori possono visualizzare l'aspetto di tali modifiche e lavorare con altri servizi dipendenti prima di essere uniti nel ramo principale e distribuiti nell'ambiente di produzione. In questo modo sarà più semplice creare e gestire le risorse di reviewApp e trarre vantaggio da tutte le funzionalità di tracciabilità e diagnosi delle funzionalità dell'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 YAML di esempio relativo all'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 degli artefatti in un ambiente usando il controllo dell'artefatto di valutazione.

Distribuzioni di macchine virtuali con ambienti

Una delle funzionalità più richieste negli ambienti è costituita dalle distribuzioni di macchine virtuali. Con questo aggiornamento si abilita la risorsa macchina virtuale in ambienti. È ora possibile orchestrare le distribuzioni tra più computer ed eseguire aggiornamenti in sequenza usando le pipeline YAML. È anche possibile installare l'agente in ognuno dei server di destinazione direttamente e distribuire in sequenza tali server. Inoltre, è possibile usare il catalogo attività completo nei computer di destinazione.

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.

Di seguito, ad esempio, gli aggiornamenti della distribuzione in sequenza fino a cinque destinazioni in ogni iterazione. maxParallel determinerà il numero di destinazioni che possono essere distribuite in parallelo. La selezione rappresenta il numero di destinazioni che devono rimanere disponibili in qualsiasi momento, escludendo le destinazioni in cui viene distribuita. 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 a un 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

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.

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.

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. 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.

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.

Input di argomenti nell'attività Docker Compose

È stato introdotto un nuovo campo nell'attività Docker Compose per consentire di aggiungere argomenti come --no-cache. L'argomento verrà passato dall'attività durante l'esecuzione di comandi, ad esempio la compilazione.

Miglioramenti delle attività di rilascio di GitHub

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

Sono state anche aggiunte funzionalità per personalizzare la creazione e la formattazione del log delle modifiche. Nella nuova sezione per la configurazione del log delle modifiche è 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 non definitive), l'ultima versione non bozza o qualsiasi versione precedente corrispondente al tag di versione specificato. Inoltre, l'attività fornisce il campo del tipo di log delle modifiche per formattare il log delle modifiche. In base alla selezione, il log delle modifiche visualizzerà un elenco di commit o un elenco di problemi/richieste pull categorizzate in base alle etichette.

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

Open Policy Agent è un motore di criteri per utilizzo generico open source che consente l'imposizione unificata dei criteri con riconoscimento del contesto. È stata aggiunta l'attività di installazione 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à.

Distribuzioni canary basate su Service Mesh Interface nell'attività KubernetesManifest

In precedenza, quando è stata specificata la strategia canary nell'attività KubernetesManifest, l'attività creava carichi di lavoro di base e canary le cui repliche erano uguali a una percentuale delle repliche usate per carichi di lavoro stabili. Ciò non equivaleva 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 Interface all'attività KubernetesManifest.

L'astrazione dell'interfaccia di Service Mesh consente la configurazione plug-and-play con provider di mesh di servizi, ad esempio Linkerd e Istio. Ora l'attività KubernetesManifest elimina il duro lavoro di mapping degli oggetti TrafficSplit di SMI ai servizi stable, 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 poiché la divisione percentuale del traffico viene controllata sulle richieste nel piano mesh di 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'

L'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.The Azure file copy task can be used in a build or release pipeline to copy files to Microsoft storage BLOBs or virtual machines (VM). 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 della 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 di piano dopo la copia
• Riprendere la copia in caso di errore del processo

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

• Simboli con caratteri jolly nel nome/percorso del file dell'origine
• Inferenza del tipo di contenuto in base all'estensione di file quando non vengono forniti argomenti
• Definizione del livello di dettaglio 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 il callback in Azure DevOps. Ad esempio, si usa il token di accesso per ottenere il codice sorgente, caricare log, risultati dei test, artefatti o effettuare chiamate REST in Azure DevOps. Viene generato un nuovo token di accesso 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 ad ora, 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 si dispone di tale controllo per le pipeline YAML o versione classica. Con questo aggiornamento si introduce un'impostazione di raccolta per forzare ogni processo a ottenere un token con ambito progetto indipendentemente da ciò che è configurato nella pipeline. È stata aggiunta anche l'impostazione a livello di progetto. A questo momento, ogni nuovo progetto e raccolta che si crea 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 all'account del servizio di compilazione progetto l'accesso alla risorsa desiderata. È consigliabile attivare queste impostazioni di sicurezza.

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

  Basandosi sul 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, sarebbe possibile visualizzare solo i repository usati nella pipeline. In precedenza, il token di accesso è valido per qualsiasi repository Azure Repos nel progetto o potenzialmente per l'intera raccolta.

  Questa funzionalità sarà attivata per impostazione predefinita per i 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.

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 raccoglierebbero 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.

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.

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.

  

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

  

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

• Elementi disponibili per l'esecuzione.

  

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

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à. ​

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 non è consigliabile disabilitarli per la maggior parte dei clienti.

Diagnostica dell'agente

È stata aggiunta la diagnostica per molti problemi comuni correlati 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 del servizio per le pipeline YAML

L'integrazione dei servizi con le pipeline YAML è stata semplificata. Usando gli eventi degli hook del servizio per le pipeline YAML, è ora possibile guidare le 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 al termine di una fase o inviare una notifica push ai dispositivi mobili del team in caso di errore di una fase.

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.

Integrazione ottimizzata

Optimizely è una potente piattaforma di test A/B e contrassegno delle funzionalità per i team del prodotto. L'integrazione di Azure Pipelines con la piattaforma di sperimentazione Optimizely consente ai team del prodotto di testare, apprendere e distribuire a un ritmo accelerato, ottenendo al tempo di tutti i vantaggi di DevOps da Azure Pipelines.

L'estensione Optimizely per Azure DevOps aggiunge i passaggi di implementazione del flag di sperimentazione e del flag di funzionalità alle pipeline di compilazione e versione, in modo da poter eseguire continuamente iterazioni, implementazioni delle funzionalità e rollback usando Azure Pipelines.

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

Aggiungere una versione di GitHub come origine artefatto

È ora possibile collegare le versioni di GitHub come origine artefatto nelle pipeline di versione di Azure DevOps. In questo modo si utilizzerà la versione di GitHub come parte delle distribuzioni.

Quando si fa clic su Aggiungi un artefatto nella definizione della pipeline di versione, 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 del rilascio. Dopo aver collegato una versione di GitHub, viene scaricato e reso disponibile automaticamente nei processi di rilascio.

Integrazione di Terraform con Azure Pipelines

Terraform è uno strumento open source per lo sviluppo, la modifica e il controllo delle versioni dell'infrastruttura in modo sicuro ed efficiente. Terraform codifica le API in 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 infrastruttura: Azure, Amazon Web Services (AWS) e Google Cloud Platform (GCP).

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

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.

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.

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 un report di bug viene risolto o chiuso, 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.

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.

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.

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.

Aiutami a comprendere la nuova pagina

La nuova pagina Test Plans ha un totale di 6 sezioni di cui sono nuove le prime 4, mentre le sezioni Grafici & Estendibilità 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

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à)

È 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

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

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

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à)

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à)

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

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 univoca di test case, gruppo 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:

• Punti di test di contrassegno bulk: questa opzione consente di contrassegnare rapidamente il risultato dei punti di test, superati, non riusciti, bloccati o non applicabili, senza dover eseguire il test case tramite il testrunner. Il risultato può essere contrassegnato per uno o più punti di test in un'unica operazione.
• Eseguire i punti di test: questa opzione consente di eseguire singolarmente i test case eseguendo singolarmente ogni passaggio di test e contrassegnandoli con un test runner. A seconda dell'applicazione in fase di test, è possibile usare "Runner Web" per testare un'applicazione Web o "runner desktop" per testare 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 colonna". L'elenco delle colonne disponibili per la selezione è associato a punti di test, ad esempio Run by, Assigned Tester, Configuration e così via.
• Visualizzazione schermo intero: è possibile visualizzare il contenuto dell'intera scheda Esegui in modalità schermo intero usando questa opzione.
• Filtro: tramite la barra dei filtri è possibile filtrare l'elenco dei punti di test usando i campi "titolo del test case", "assegnato a", "state", "test outcome", "Tester" e "Configuration". È anche possibile ordinare l'elenco facendo clic sulle intestazioni di colonna.

Opzioni del menu di scelta rapida

Il menu di scelta rapida nel nodo Punto di test nella scheda Esegui offre le opzioni seguenti:

• Contrassegnare il risultato del test: uguale a quello precedente, consente di contrassegnare rapidamente il risultato dei punti di test, superati, non riusciti, bloccati o non applicabili.
• Eseguire i punti di test: uguale a quello precedente, consente di eseguire i test case tramite il testrunner.
• Reimpostare il test su attivo: questa opzione consente di reimpostare il risultato del test in attivo, ignorando così l'ultimo risultato del punto di test.
• 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.
• Assegna tester: questa opzione consente di assegnare i punti di test ai tester per l'esecuzione del test.
• Visualizza il 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 file.
• Visualizzare la cronologia di esecuzione: questa opzione consente di visualizzare l'intera cronologia di esecuzione per il punto di test selezionato. Apre una nuova pagina in cui è possibile modificare i filtri per visualizzare la cronologia di esecuzione del punto di test selezionato, ma anche per l'intero test case.

report Test Plans stato

Questo report out-of-box 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.

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 un'analisi importante per ogni suite di test.

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).

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).

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:

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.

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 usate più elevate 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, durante la modifica di una tabella wiki codici, si veniva reindirizzati 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 affiancato 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 nel wiki del progetto. È comunque possibile scegliere di modificare i repository selezionando l'opzione Modifica in Repository nel menu di scelta rapida.

Creare e incorporare elementi di lavoro da una pagina wiki

Durante l'ascolto dei commenti e suggerimenti, abbiamo sentito che si usa 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 a modifica e quindi trovare l'elemento di lavoro per incorporarlo. Riduce anche il cambio di contesto perché non si esce dall'ambito wiki.

Per altre informazioni sulla creazione e l'incorporamento di un elemento di lavoro dal 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 hanno risposto a una sfida poiché le conversazioni dovevano verificarsi su 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 assegnata in ordine di priorità in base a questo ticket di suggerimento. Per altre informazioni sui commenti, vedere la documentazione qui.

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

Fino ad ora, l'albero wiki mostra tutte le cartelle e i file che iniziano con un punto (.) nell'albero wiki. Negli scenari wiki di codice, queste cartelle come .vscode, che devono essere nascoste, vengono visualizzate nell'albero wiki. Ora, tutti i file e le cartelle che iniziano con un punto rimarranno nascosti nell'albero wiki, riducendo così il disordine non necessario.

Questa funzionalità è stata assegnata in ordine di priorità in base a questo ticket di suggerimento.

URL delle pagine Wiki brevi e leggibili

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

La nuova struttura degli URL sarà simile alla 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.

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, ad esempio le pagine più visualizzate.

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

Nota

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

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.

2. 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, è possibile rispondere filtrando sul nuoto board.

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

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

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.

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.

Facendo clic sull'anteprima verrà visualizzata immediatamente una versione più grande 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 configurarla in base a storie, punti di storia o conteggio delle attività, anziché solo la 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 .

Un dashboard di 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 relativa configurazione. È possibile aggiungere questi widget ai dashboard di progetto e selezionare il team specifico desiderato.

Nota

Per 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 tenere traccia di esso attraverso Developer Community e ottenere consigli su Stack Overflow.

---

Inizio pagina