Note sulla versione di Azure DevOps Server 2020

Developer Community Requisiti di | licenza dei requisiti | disistema DevOps | | Blog SHA-1 Hashs

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

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

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 di TFS si trova 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 (compilazione) che funziona in base alle impostazioni a livello di progetto.

Azure DevOps Server 2020 gestisce la conservazione della compilazione in modo diverso, 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 per Abilitare la convalida dei parametri degli argomenti delle attività della shell.

Nota

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

Installare le 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 della patch 4 sarà 3.225.0.

Configurare TFX

1. Seguire la procedura descritta nella documentazione relativa al caricamento delle attività nella raccolta di progetti per installare e accedere con tfx-cli.

Aggiornare le attività con TFX

File	Hash SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E2E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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, è necessario impostare una variabile AZP_75787_ENABLE_NEW_LOGIC = true nelle pipeline che usano le attività interessate.

• In versione classica:

  Definire la variabile nella scheda della variabile nella pipeline.

• Esempio YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Update 0.2 Patch 5 Release Date: 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 della 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 per cui l'identità "Proprietario analisi" 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: vulnerabilità di elevazione dei privilegi di Azure DevOps Server e 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 all'ambiente di produzione.

Nota

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

Installare le 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 il downgrade dell'agente. In Windows è possibile usare il comando seguente in un prompt dei comandi amministrativo, seguito da un riavvio. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Configurare TFX

1. Seguire la procedura descritta nella documentazione relativa al caricamento delle attività nella 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, è necessario impostare una variabile AZP_75787_ENABLE_NEW_LOGIC = true nelle pipeline che usano le attività interessate.

• In versione classica:

  Definire la variabile nella scheda della 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 dei 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 dei 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 relativo alla mancata visualizzazione delle identità di Active Directory appena aggiunte nei selettore identità della finestra di dialogo di sicurezza.
• Consente di risolvere un problema relativo al filtro Del gruppo richiesto dal membro del gruppo nelle impostazioni di webhook.
• Correzione dell'errore di compilazione del check-in controllato quando le impostazioni organizzazione per la pipeline avevano l'ambito di autorizzazione del processo configurato come Limitare l'ambito di autorizzazione del processo al progetto corrente per le pipeline non di rilascio.

Azure DevOps Server 2020.0.2 Data di rilascio: 17 maggio 2022

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

Nota

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

Questa versione include correzioni per quanto segue:

• Impossibile ignorare la coda di compilazione usando il pulsante "Esegui successivo". In precedenza, il pulsante "Esegui successivo" era 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.

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

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

• Email le notifiche non sono state inviate quando si usa il @mention controllo in un elemento di lavoro.
• Correzione TF400813 errore durante il cambio di account. Questo errore si è verificato durante l'aggiornamento da TFS 2018 a Azure DevOps Server 2020.0.1.
• Correzione del problema relativo al mancato caricamento della pagina di riepilogo della panoramica del progetto.
• 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 Version su 5.4.1 (Name = Version, Value = 5.4.1).
3. Eseguire il comando PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update update come specificato nel file leggimi. Può restituire un avviso simile a: Impossibile connettersi al server remoto. Non chiudere la finestra, perché l'aggiornamento esegue nuovi tentativi fino al completamento.

Nota

Se Azure DevOps Server e Elasticsearch sono installati in computer diversi, seguire questa procedura.

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 Version su 5.4.1 (Name = Version, Value = 5.4.1).
3. Copiare il contenuto della cartella denominata zip, che si trova nella C:\Program Files\{TFS Version Folder}\Search\zip cartella dei file remoti di Elasticsearch.
4. Eseguire Configure-TFSSearch.ps1 -Operation update nel computer del server Elasticsearch.

Hash SHA-256: B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

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

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

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

• In precedenza, Azure DevOps Server poteva creare connessioni solo a GitHub Enterprise Server. Con questa patch, gli amministratori del progetto possono creare connessioni tra Azure DevOps Server e repository in GitHub.com. È possibile trovare questa impostazione nella pagina Connessioni GitHub in Impostazioni progetto.
• Risolvere il problema con il widget Piano di test. Il report sull'esecuzione del test mostrava un utente non corretto nei risultati.
• Correzione del problema relativo al mancato caricamento della pagina di riepilogo della panoramica del progetto.
• Consente di risolvere il problema relativo al mancato invio dei messaggi di posta elettronica per confermare l'aggiornamento del prodotto.

Azure DevOps Server 2020.0.1 Patch 6 Data di rilascio: 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 relativo ai dati dei risultati dei test incoerenti.

Azure DevOps Server 2020.0.1 Patch 5 Data di rilascio: 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.
• È stata modificata la cronologia di esplorazione per visualizzare i file anziché il repository radice.
• Correzione del problema relativo ai processi di recapito tramite posta elettronica per alcuni tipi di elementi 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.

• Correzione del 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 a riferimenti che hanno aumentato le dimensioni della tbl_testCaseReferences tabella. Con questa patch sono stati rimossi riferimenti a test case non aggiornati per velocizzare il processo di importazione dei dati.

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

Installazione generale delle patch

Se si dispone di 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 è 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 del computer. Ad esempio: D:\tasks\AzureResourceGroupDeploymentV2.

2. Scaricare e installare Node.js 14.15.1 e npm (incluso nel download 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. Create un token di accesso personale con privilegi di accesso completo e copiarlo. Questo token di accesso personale verrà usato quando si esegue il comando tfx login .

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

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 del computer. Ad esempio:D:\tasks\AzureResourceManagerTemplateDeploymentV3.

2. Scaricare e installare Node.js 14.15.1 e npm (inclusi nel download di 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. Create un token di accesso personale con privilegi di accesso completo e copiarlo. Questo token di accesso personale verrà usato quando si esegue il comando tfx login .

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. Puoi aggiungere tutte e sei le reazioni se vuoi, o solo una o due. Per rimuovere la reazione, fare clic sulla reazione nella parte inferiore del commento e verrà rimossa. Di seguito è possibile vedere l'esperienza dell'aggiunta di una reazione, oltre a ciò che le reazioni sembrano su un commento.

Aggiungere report Azure Boards al dashboard

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

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

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

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

Aggiornamenti live di Taskboard

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

Supporto per i campi personalizzati nelle colonne rollup

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

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

   

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

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

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

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

Impostazioni di notifica degli elementi di lavoro personalizzate

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

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

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

Collegare elementi di lavoro alle distribuzioni

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

Importare elementi di lavoro da un file CSV

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

Aggiungere il campo padre alle schede dell'elemento di lavoro

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

Aggiungere il campo padre al backlog e alle query

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

Repos

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

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

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

Filtrare le notifiche di commento dalle richieste pull

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

Hook di servizio per i commenti delle richieste pull

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

Criteri per bloccare i file con modelli specificati

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

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 la compilazione, consultare la documentazione o il blog per la creazione di pipeline CI/CD a più fasi.

Gestire le variabili della pipeline nell'editor YAML

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

Approvare le versioni direttamente dall'hub Delle versioni

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

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

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

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

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

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

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

La risposta conterrà il codice YAML sottoposto a rendering.

Pianificazioni Cron in YAML

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

1. Configurazione come codice: è possibile tenere traccia delle pianificazioni insieme alla pipeline come parte del codice.
2. Espressivo: si ha maggiore potenza espressiva nella definizione di pianificazioni rispetto a quelle che è stato possibile usare con l'interfaccia utente. Ad esempio, è più semplice specificare una singola pianificazione che avvia un'esecuzione ogni ora.
3. Standard del settore: molti sviluppatori e amministratori hanno già familiarità con la sintassi cron.

schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

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

Aggiornamenti all'interfaccia utente delle connessioni al servizio

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

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

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

Nota

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

Ignorare le fasi in una pipeline YAML

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

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

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

Connessioni al servizio nuova interfaccia utente come esperienza predefinita

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

Altre informazioni sulle connessioni al servizio sono disponibili qui.

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

È stata aggiunta la possibilità di selezionare manualmente le versioni delle risorse della pipeline nella finestra di dialogo di creazione dell'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 e del gruppo di variabili della pipeline

Può essere difficile convertire 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 script per la configurazione e la gestione delle variabili e dei gruppi di variabili che a loro volta possono essere 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 di richiesta pull

Quando si crea una richiesta pull, può essere difficile verificare se le modifiche potrebbero interrompere l'esecuzione della pipeline nel ramo di destinazione. Tuttavia, con la possibilità di attivare un'esecuzione della pipeline o di accodare una compilazione per un ramo pr, è ora possibile convalidare e visualizzare le modifiche in corso eseguendola nella pipeline di destinazione. Per altre informazioni, vedere la documentazione del comando az pipelines run e az pipelines build queue .

Ignorare la prima esecuzione della pipeline

Quando si creano pipeline, a volte si vuole creare ed eseguire il commit di un file YAML e non attivare l'esecuzione della pipeline perché può causare un'esecuzione non riuscita a causa di diversi 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 automatizzata della pipeline durante la creazione di una pipeline includendo il parametro --skip-first-run. Per altre informazioni, vedere la documentazione del comando az pipeline create .

Miglioramento dei comandi dell'endpoint di servizio

I comandi dell'interfaccia della riga di comando dell'endpoint di servizio supportano solo azure rm e l'endpoint di servizio github configurati e di gestione. Tuttavia, con questa versione, i comandi degli 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 il supporto di 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 farvi riferimento 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 - Durata dell'esecuzione del processo prima dell'annullamento automatico
• cancelTimeoutInMinutes - Tempo di esecuzione sempre anche se le attività annullate prima di terminarle
• condition : eseguire il processo in modo condizionale
• variabili : è possibile aggiungere direttamente valori hardcoded o gruppi di variabili, gruppo di variabili supportato da un insieme di credenziali delle chiavi di Azure oppure 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; il valore predefinito è '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 per le pipeline YAML CD in cui le pipeline CI vengono definite risorse della pipeline. Nella visualizzazione esecuzione della pipeline CI verrà ora visualizzata una nuova scheda "Pipeline associate" in cui è possibile trovare tutte le esecuzioni della pipeline che usano la pipeline e gli artefatti da esso.

Supporto per i pacchetti GitHub nelle pipeline YAML

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

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

Nota

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

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

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

collegamento servizio Azure Kubernetes cluster nella visualizzazione risorse degli ambienti Kubernetes

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

Filtri delle cartelle di rilascio nelle sottoscrizioni di notifica

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

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 associa automaticamente l'esecuzione a tutti gli elementi di lavoro (che vengono dedotti tramite i commit in tale codice). Quando si apre l'elemento di lavoro, sarà possibile visualizzare le esecuzioni in cui è stato compilato il codice per tale elemento di lavoro. Per configurare questa operazione, usare il pannello delle impostazioni di una pipeline.

Annullare la fase in una pipeline YAML a più fasi

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

Fasi di ripetizione dei tentativi non riuscite

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

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

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

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

Approvazioni nelle pipeline YAML a più fasi

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

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

Aumento del limite e della frequenza di timeout dei gate

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

Nuovo modello di immagine di compilazione per Dockerfile

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

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

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

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

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

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

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

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

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

Miglioramenti alle approvazioni nelle pipeline YAML

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

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

Supporto dei test della struttura dei contenitori in Azure Pipelines

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

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

Immettere i dettagli del file di configurazione e dell'immagine

Testare i dati e il riepilogo

Decorator della pipeline per le pipeline di rilascio

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

Sono stati supportati 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: MainNamespace

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 degli argomenti nell'attività Docker Compose

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

Miglioramenti delle attività di rilascio di GitHub

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

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

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

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

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

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

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

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

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

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

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

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

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

Attività copia file di Azure supporta ora AzCopy V10

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

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

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

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

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

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

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

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

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

  Nota

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

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

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

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

  Questa funzionalità verrà attivata per impostazione predefinita per nuovi progetti e raccolte. Per le raccolte esistenti, è necessario abilitarlo in Impostazionipipeline di>impostazioni 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 è Compilazione coda. Con questo aggiornamento, è stata rimossa questa autorizzazione per il token di accesso. Se le pipeline richiedono 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 un luogo centralizzato 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 e predefinito.

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

Ecco un esempio completo, che illustra i passaggi in esecuzione sull'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 attività downstream raccoglierebbero il nuovo valore. Con questo aggiornamento, la sicurezza delle variabili della pipeline viene stretta per rendere di sola lettura le variabili di sistema e in fase di coda. Inoltre, è possibile creare una variabile YAML di sola lettura contrassegnandola come indicato di seguito.

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

Accesso basato sul ruolo per le connessioni al servizio

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

Come parte di questo lavoro, abbiamo introdotto i nuovi ruoli di lettore, utente, creatore e amministratore. È possibile impostare questi ruoli tramite la pagina connessioni del servizio nel progetto e queste vengono ereditate dalle singole connessioni. In ogni connessione al servizio è possibile attivare o disattivare l'ereditarietà e sostituire i 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 della connessione del servizio tra progetti. È ora possibile condividere le connessioni al servizio con i progetti in modo sicuro e sicuro.

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

Tracciabilità per le pipeline e le 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 tornare 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 pipeline di Azure o quando viene eseguito il push di un'immagine del contenitore in ACR.

  

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

  

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

• Gli artefatti disponibili per essere usati dall'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 dei risultati dei test in Azure Pipelines consente di pubblicare i risultati dei test quando vengono eseguiti test per offrire un'esperienza completa di report e analisi dei test. Fino a questo momento, è stato previsto un limite di 100 MB per gli allegati di test sia per i risultati di 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 disporre di tutti i dati disponibili per risolvere i problemi dei test non riusciti.

È possibile che l'attività VSTest o Pubblica i risultati dei test restituisca un errore 403 o 407 nei log. Se si usano build self-hosted o agenti di rilascio dietro un firewall che filtra le richieste in uscita, è 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. È possibile trovare informazioni sulla risoluzione dei problemi nella documentazione qui. ​

Nota

Questa operazione è necessaria solo se si usano agenti di Azure Pipelines self-hosted e si sta dietro 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 si usa una matrice per espandere processi o una variabile per identificare un pool, a volte sono state risolte informazioni sul pool non corrette nelle pagine dei log. Questi problemi sono stati risolti.

Trigger CI per nuovi rami

È stata una 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 in base a un ramo esistente. Verrà attivata immediatamente una nuova compilazione CI se il filtro 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. È stato configurato un filtro del percorso per la corrispondenza tra "app". In altre parole, non si vuole creare una nuova compilazione se è stata eseguita il push di una modifica nei documenti. È possibile creare un nuovo ramo in locale, apportare alcune modifiche alla documentazione e quindi eseguire il push di tale ramo nel server. È stato usato per attivare una nuova compilazione CI. Ciò è indesiderato perché non è stato chiesto esplicitamente di cercare le modifiche nella cartella docs. Tuttavia, a causa del modo in cui è stato gestito un nuovo evento di ramo, sembra che una modifica sia stata apportata anche alla cartella dell'app.

Ora, abbiamo un modo migliore per gestire l'CI per nuovi rami per risolvere questi problemi. Quando si pubblica un nuovo ramo, cercare in modo esplicito nuovi commit in tale ramo e verificare se corrispondono ai filtri del 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 all'altra. Il risultato (stato) di una fase precedente e i relativi processi sono disponibili anche.

Le variabili di output vengono comunque prodotte dai passaggi all'interno dei processi. Anziché 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 in una pipeline dipende da quella appena prima del file YAML. Pertanto, ogni fase può usare le variabili di output dalla 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 sulla fase 1.

Disabilitare gli aggiornamenti automatici degli agenti a livello di pool

Attualmente, gli agenti della pipeline verranno aggiornati automaticamente alla versione più recente quando necessario. Questo avviene in genere quando è presente una nuova funzionalità o 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 agli agenti di aggiornare. Questa funzionalità è principalmente di interesse per i clienti con pool self-hosted e requisiti di controllo delle modifiche molto rigorosi. Gli aggiornamenti automatici sono abilitati per impostazione predefinita e la maggior parte dei clienti non li disabilita.

Diagnostica agente

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

Hook di servizio per le pipeline YAML

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

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

Integrazione ottimizzata

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

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

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

Aggiungere una versione di GitHub come origine artefatti

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

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

Integrazione di Terraform con Azure Pipelines

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

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

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.

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

• Create 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à del gruppo di test insieme ai dettagli dei test case e dei punti di test come "posta elettronica" o "stampa in pdf".
• Aprire l'elemento di lavoro del gruppo di test: questa opzione consente di modificare il modulo dell'elemento di lavoro del gruppo 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 di test di accettazione utente (UAT) 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 raccogliere, aggiungere e gestire test case per un gruppo di test. Mentre la scheda Execute è 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 o equivalente. Tutto il resto deve essere esercitabile da un utente con livello di accesso "Basic".

Attività

La scheda Definisci consente di eseguire le attività seguenti:

• Aggiungi nuovo test case usando il modulo 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.
• Aggiungi nuovo test case usando la griglia: questa opzione consente di creare uno o più test case usando la visualizzazione griglia 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.
• Ordinare i test case trascinando/rilasciando: è possibile riordinare i test case trascinando/rilasciando uno o più test case all'interno di un determinato gruppo. L'ordine dei test case si applica solo ai test case manuali e non ai test automatizzati.
• Spostare test case da una suite a un'altra: usando il trascinamento della selezione, è possibile spostare i test case da un gruppo di test a un altro.
• Mostra griglia: è possibile usare la modalità griglia per visualizzare/modificare i test case insieme ai passaggi di test.
• Visualizzazione a 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 "test case title", "assigned to" 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 di 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 apri/modifica elemento di lavoro test case: questa opzione consente di modificare un test case usando il modulo dell'elemento di lavoro in cui si modificano i campi dell'elemento di lavoro, inclusi i passaggi di test.
• Modifica test case: questa opzione consente di modificare in blocco i campi dell'elemento di lavoro test case. Tuttavia, non è possibile usare questa opzione per modificare in blocco i passaggi di test.
• Modifica test case nella griglia: questa opzione consente di modificare in blocco i test case selezionati, inclusi i passaggi di test usando la visualizzazione griglia.
• Assegna configurazioni: questa opzione consente di eseguire l'override delle configurazioni a livello di gruppo con configurazioni a livello di test case.
• Rimuovi test case: questa opzione consente di rimuovere i test case dalla suite specificata. Tuttavia, non modifica l'elemento di lavoro del test case sottostante.
• Create una copia/clonazione dei test case: questa opzione consente di creare una copia/clonazione di test case selezionati. Vedere di seguito per altri dettagli.
• Visualizza elementi collegati: questa opzione consente di esaminare gli elementi collegati per un determinato test case. Vedere di seguito per altri dettagli.

Test case di copia/clonazione (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 il gruppo di test di destinazione in cui creare il test case di copia/clonato. Inoltre, è anche possibile specificare se si desidera includere collegamenti o 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 critico del prodotto Test Plans. Usando l'opzione "Visualizza elementi collegati", è possibile esaminare facilmente tutti i requisiti collegati a cui è collegato questo test case, tutti i gruppi di test/piani di test in cui è stato usato questo test case e tutti i bug che sono stati inseriti come parte dell'esecuzione del test.

4. Scheda Esegui

La scheda Definisci consente di raccogliere, aggiungere e gestire test case per un gruppo di test. Mentre la scheda Execute è 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 un gruppo 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, si ottengono 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 è quella visualizzata nella scheda Esecuzione.
Di conseguenza, i test case sono entità riutilizzabili. Includendoli in un piano di test o in un gruppo di test, vengono generati i punti di test. Eseguendo i punti di test, si determina la qualità del prodotto o del servizio sviluppato.

Uno dei principali vantaggi della nuova pagina è per gli utenti che eseguono principalmente test di esecuzione/rilevamento (devono avere solo il 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 o equivalente. Tutto il resto, inclusa la scheda "Esegui" deve essere esercitabile da un utente con livello di accesso 'Basic'.

Attività

La scheda Esegui consente di eseguire le attività seguenti:

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

Opzioni del menu di scelta rapida

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

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

Test Plans report Stato

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

Le tre sezioni del report includono quanto segue:

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

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.

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

• esperienza di feed Create
• 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.

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

Create 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