Note sulla versione di Azure DevOps Server 2019 Update 1

community degli sviluppatori | requisiti di sistema | condizioni di licenza | blog di DevOps | hash SHA-1

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 Azure DevOps Server Requirements. Per scaricare i prodotti Azure DevOps, visitare la pagina di download di Azure DevOps Server .

L'aggiornamento diretto ad 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 ad Azure DevOps Server 2019. Per altre informazioni, vedere Installare e configurare Azure DevOps in locale.

Eseguire l'aggiornamento sicuro da Azure DevOps Server 2019 ad Azure DevOps Server 2020

Azure DevOps Server 2020 introduce un nuovo modello di conservazione delle esecuzioni delle pipeline basato su impostazioni a livello di progetto.

Azure DevOps Server 2020 gestisce la conservazione dei build in modo diverso, in base alle politiche 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 ulteriori informazioni su come eseguire l'aggiornamento sicuro da Azure DevOps Server 2019 ad Azure DevOps Server 2020, vedere il post del nostro blog .

Data di rilascio di Azure DevOps Server 2019 Update 1.2 Patch 11: 8 aprile 2025

È stata rilasciata la patch 11 per Azure DevOps Server 2019 Update 1.2 che include quanto segue:

• In precedenza, l'agente Di Azure DevOps usava la rete CDN Edgio con l'endpoint vstsagentpackage.azureedge.net. Nell'ambito del ritiro di Edgio, il *.azureedge.net dominio viene rimosso. Per garantire la disponibilità continua, è stata eseguita la migrazione a una rete CDN supportata da Akamai con un nuovo endpoint download.agent.dev.azure.com. Questa patch include le modifiche necessarie per recuperare i file binari dell'agente dal nuovo endpoint della rete CDN, eseguendo così la migrazione dall'endpoint della rete CDN precedente.

Data di rilascio di Azure DevOps Server 2019 Update 1.2 Patch 10: 11 marzo 2025

È stata rilasciata patch 10 per Azure DevOps Server 2019 Update 1.2 che include quanto segue:

• Aggiornare le attività a causa della deprecazione della rete CDN Edgio. Visita il post del blog Switching CDN providers (Passaggio dei provider di rete CDN) per ulteriori dettagli.

Data di rilascio di Azure DevOps Server 2019 Update 1.2 Patch 9: 28 maggio 2024

È stata rilasciata patch 9 per Azure DevOps Server 2019 Update 1.2 che include quanto segue:

• Semplificare la distribuzione degli aggiornamenti dell'agente e delle attività dalle patch precedenti (Patch 5 e 6).

Installare le patch

Requisiti della pipeline

Per applicare il nuovo comportamento per convalidare gli argomenti della riga di comando, è necessario impostare una variabile AZP_75787_ENABLE_NEW_LOGIC = true nelle pipeline che usano le attività interessate. Per altre informazioni sul comportamento abilitato, vedere qui:

• In versione classica:

  Definire la variabile nella scheda variabile della pipeline.

• Esempio YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Data di rilascio di Azure DevOps Server 2019 Update 1.2 Patch 8: 12 marzo 2024

È stata rilasciata patch 8 per Azure DevOps Server 2019 Update 1.2 che include correzioni per quanto segue:

• È stato risolto un problema a causa del quale il server proxy smetteva di funzionare dopo l'installazione della patch 7.

Data di rilascio di Azure DevOps Server 2019 Update 1.2 Patch 7: 13 febbraio 2024

È stata rilasciata patch 7 per Azure DevOps Server 2019 Update 1.2 che include correzioni per quanto segue:

• Correzione di un bug per cui lo spazio su disco usato dalla cartella della cache proxy è stato calcolato in modo non corretto e la cartella non è stata pulita correttamente.
• CVE-2024-20667: vulnerabilità di esecuzione remota del codice di Azure DevOps Server.

Data di rilascio di Azure DevOps Server 2019 Update 1.2 Patch 6: 14 novembre 2023

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

• Esteso l'elenco di caratteri consentiti per le attività di PowerShell per Abilitare la convalida dei parametri degli argomenti delle attività della shell.

Installare le patch

Configurare TFX

1. Seguire i passaggi descritti nella documentazione caricare le attività nella documentazione della raccolta di progetti per installare e accedere con tfx-cli.

Aggiornare le attività con TFX

1. Scarica ed estrai Tasks20231103.zip.
2. Accedi alla directory dei 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.

• Nella versione classica:

  Definire la variabile nella scheda variabile della pipeline.

• Esempio YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Data di rilascio di Azure DevOps Server 2019 Update 1.2 Patch 5: 12 settembre 2023

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

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

Installare le patch

1. Scaricare e installare Azure DevOps Server 2019 Update 1.2 patch 5.

Aggiornare l'agente di Azure Pipelines

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

Configurare TFX

1. Seguire i passaggi indicati nella documentazione della raccolta di progetti per il caricamento delle attività per installare e effettuare l'accesso con tfx-cli.

Aggiornare le attività con TFX

1. Scarica ed estrai Tasks_20230825.zip.
2. Accedi alla directory dei 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.

• Nella versione classica:

  Definire la variabile nella scheda variabile della pipeline.

• Esempio YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Data di rilascio di Azure DevOps Server 2019 Update 1.2 Patch 4: 8 agosto 2023

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

• CVE-2023-36869: vulnerabilità di spoofing del server Azure DevOps.
• Aggiornare il servizio SSH per supportare SHA2-256 e SHA2-512. Se hai file di configurazione SSH hardcoded per usare RSA, dovresti aggiornare a SHA2 o rimuovere la voce.
• Correzione del bug del ciclo infinito in CronScheduleJobExtension.

Data di rilascio di Azure DevOps Server 2019 Update 1.2 Patch 3: 13 giugno 2023

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

• Correzione di un bug che interferisce con il push dei pacchetti durante l'aggiornamento dalla versione 2018 o precedente.

Data di rilascio di Azure DevOps Server 2019 Update 1.2 Patch 2: 13 dicembre 2022

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

• Risolti i problemi nel processo di analisi della sincronizzazione del parallelismo degli account.

Data di rilascio di Azure DevOps Server 2019 Update 1.2 Patch 1: 12 luglio 2022

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

• Nelle API delle esecuzioni di test, il token di continuazione restituito era maggiore del valore "maxLastUpdatedDate" specificato.
• Durante la modifica di una pipeline classica, la scheda di conservazione era vuota dopo l'eliminazione delle modifiche in una scheda diversa.

Data di rilascio dell'aggiornamento 1.2 di Azure DevOps Server 2019: 17 maggio 2022

Azure DevOps Server 2019 Update 1.2 è un aggiornamento cumulativo delle correzioni di bug. È possibile installare direttamente Azure DevOps Server 2019 Update 1.2 o eseguire l'aggiornamento da Azure DevOps Server 2019 o Team Foundation Server 2013 o versione successiva.

Questa versione include correzioni per quanto segue:

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

Data di rilascio di Azure DevOps Server 2019 Update 1.1 Patch 13: 26 gennaio 2022

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

• Le notifiche tramite posta elettronica non sono state inviate quando si usa il controllo @mention in un elemento di lavoro.
• L'indirizzo di posta elettronica preferito non è stato aggiornato nel profilo utente. Ciò ha comportato l'invio di messaggi di posta elettronica all'indirizzo di posta elettronica precedente.
• È stata risolta la vulnerabilità di Elasticsearch rimuovendo la classe jndilookup dai file binari log4j.

Passaggi di installazione

1. Aggiornare il server con Patch 13.
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 aggiornamento PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update come specificato nel file leggimi. Potrebbe essere restituito un avviso simile al seguente: Impossibile connettersi al server remoto. Non chiudere la finestra, perché l'aggiornamento esegue nuovi tentativi finché non viene completato.

1. Aggiornare il server con Patch 13.
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 in C:\Program Files\{TFS Version Folder}\Search\zip, nella cartella del file remoto destinata a Elasticsearch.
4. Esegui Configure-TFSSearch.ps1 -Operation update sul server Elasticsearch.

Hash SHA-256: DB762E391F9DF8E71E58D6FAA169CA44DFBE996AE6567B55F772CBA9E3DA2AB3

Data di rilascio di Azure DevOps Server 2019 Update 1.1 Patch 12: 15 settembre 2021

patch 12 per Azure DevOps Server 2019 Update 1.1 include correzioni per quanto segue.

• Correzione della macro dell'elemento di lavoro per le query con «Contiene parole». In precedenza, le query restituivano risultati non corretti per i valori che contengono un'interruzione di riga.
• 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 la valutazione delle regole NOTSAMEAS quando sono state definite più regole NOTSAMEAS per un campo.

Data di rilascio di Azure DevOps Server 2019 Update 1.1 Patch 11: 14 settembre 2021

patch 11 per Azure DevOps Server 2019 Update 1.1 include correzioni per quanto segue.

• Risolvere il problema segnalato in questo ticket di feedback della community degli sviluppatori .

Data di rilascio di Azure DevOps Server 2019 Update 1.1 Patch 10: 10 agosto 2021

patch 10 per Azure DevOps Server 2019 Update 1.1 include correzioni per quanto segue.

• Correzione del problema relativo ai processi di recapito tramite posta elettronica per alcuni tipi di elementi di lavoro.

Data di rilascio di Azure DevOps Server 2019 Update 1.1 Patch 9: 15 giugno 2021

patch 9 per Azure DevOps Server 2019 Update 1.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 ai riferimenti che hanno aumentato le dimensioni della tabella tbl_testCaseReferences. Con questa patch sono stati rimossi riferimenti a test case non aggiornati per velocizzare il processo di importazione dei dati.

Data di rilascio di Azure DevOps Server 2019 Update 1.1 Patch 8: 13 aprile 2021

È stata rilasciata una patch per Azure DevOps Server 2019 Update 1.1 che corregge quanto segue.

• CVE-2021-27067: divulgazione di informazioni
• Risolvi il problema segnalato in questo ticket di feedback della Developer Community | Impossibile registrare i dettagli dell'iterazione dei risultati del test su Azure DevOps Server 2019

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

Installazione generale delle patch

Se si ha Azure DevOps Server 2019 Update 1.1, è necessario installare Azure DevOps Server 2019 Update 1.1 Patch 8.

Verifica dell'installazione

• opzione 1: eseguire devops2019.1.1patch8.exe CheckInstall, devops2019.1.1patch8.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 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll. Azure DevOps Server 2019 viene installato per c:\Program Files\Azure DevOps Server 2019 per impostazione predefinita. Dopo aver installato Azure DevOps Server 2019.1.1 Patch 8, la versione sarà 17.153.31129.2.

Installazione del task AzureResourceGroupDeploymentV2

Installare

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

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

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

npm install -g tfx-cli

4. Creare un token di accesso personale con privilegi di accesso completo e copiarlo. Questo token di accesso personale verrà utilizzato 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>*

Data di rilascio di Azure DevOps Server 2019 Update 1.1 Patch 7: 12 gennaio 2021

È stata rilasciata una patch per Azure DevOps Server 2019 Update 1.1 che corregge quanto segue. Per altre informazioni, vedere il post di blog .

• I dettagli dell'esecuzione dei test non visualizzano i dettagli del passaggio 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 ad Azure DevOps Server 2020
• Risolvere l'eccezione del fornitore di dati

Data di rilascio di Azure DevOps Server 2019 Update 1.1 Patch 6: 8 dicembre 2020

È stata rilasciata una patch per Azure DevOps Server 2019 Update 1.1 che corregge quanto segue. Per altre informazioni, vedere il post di blog .

• CVE-2020-1325: vulnerabilità di spoofing del server Azure DevOps
• CVE-2020-17135: vulnerabilità di spoofing del server Azure DevOps
• CVE-2020-17145: Vulnerabilità di spoofing di Azure DevOps Server e Team Foundation Services
• Correzione del problema con TFVC che non elabora tutti i risultati.

Installazione generale delle patch

Se si ha Azure DevOps Server 2019 Update 1.1, è necessario installare Azure DevOps Server 2019 Update 1.1 Patch 6.

Verifica dell'installazione

• opzione 1: eseguire devops2019.1.1patch6.exe CheckInstall, devops2019.1.1patch6.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 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll. Azure DevOps Server 2019 viene installato per c:\Program Files\Azure DevOps Server 2019 per impostazione predefinita. Dopo aver installato Azure DevOps Server 2019.1.1 Patch 6, la versione sarà 17.153.30723.5.

Installazione del task AzurePowerShellV4

Prerequisiti

1. Installare il modulo Az di Azure PowerShell nella macchina dell'agente privato.

2. Creare una pipeline con l'attività AzurePowerShellV4. Nell'attività vedrai solo un errore su Errore Standard.

Installare

1. Estrarre il pacchetto di AzurePowerShellV4.zip in una cartella denominata AzurePowerShellV4.

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. Creare un token di accesso personale con privilegi di accesso completo e copiarlo. Questo token di accesso personale verrà utilizzato 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. Il percorso del pacchetto estratto verrà D:\tasks\AzurePowerShellv4.

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

Data di rilascio di Azure DevOps Server 2019 Update 1.1 Patch 5: 8 settembre 2020

È stata rilasciata una patch per Azure DevOps Server 2019 Update 1.1 che corregge quanto segue. Per altre informazioni, vedere il post di blog .

• DTS 1713492 : comportamento imprevisto durante l'aggiunta di gruppi di Active Directory alle autorizzazioni di sicurezza.

Data di rilascio di Azure DevOps Server 2019 Update 1.1 Patch 4: 14 luglio 2020

È stata rilasciata una patch per Azure DevOps Server 2019 Update 1.1 che corregge quanto segue. Per altre informazioni, vedere il post di blog .

• CVE-2020-1326: vulnerabilità di scripting tra siti
• La pipeline di compilazione mostra una connessione non corretta per gli utenti non autorizzati quando si seleziona Altra origine Git.
• Correzione dell'errore quando si modifica l'attivazione/disattivazione dell'ereditarietà nella definizione di compilazione XAML.

Data di rilascio di Azure DevOps Server 2019 Update 1.1 Patch 3: 9 giugno 2020

È stata rilasciata una patch per Azure DevOps Server 2019 Update 1.1 che corregge quanto segue. Per altre informazioni, vedere il post di blog .

• CVE-2020-1327: assicurarsi che il server Azure DevOps sanifica gli input utente.

Data di rilascio di Azure DevOps Server 2019 Update 1.1 Patch 2: 14 aprile 2020

È stata rilasciata una patch per Azure DevOps Server 2019 Update 1.1 che corregge quanto segue. Per altre informazioni, vedere il post di blog .

• Gli commit SVN non attivano la pipeline

• Aggiunta del supporto per SHA-2 nell'SSH su Azure DevOps

Data di rilascio di Azure DevOps Server 2019 Update 1.1 Patch 1: 10 marzo 2020

È stata rilasciata una patch di sicurezza per Azure DevOps Server 2019 Update 1.1 che corregge i bug seguenti. Per altre informazioni, vedere il post di blog .

• CVE-2020-0700: vulnerabilità di scripting tra siti

• CVE-2020-0758: vulnerabilità di elevazione dei privilegi

• CVE 2020-0815: vulnerabilità di elevazione dei privilegi

Data di rilascio di Azure DevOps Server 2019 Update 1.1 RTW: 10 dicembre 2019

azure DevOps Server 2019 Update 1.1 è un rollup delle correzioni di bug e degli aggiornamenti della sicurezza. Include tutte le correzioni nelle patch di Azure DevOps Server 2019 Update 1 rilasciate in precedenza. È possibile installare direttamente Azure DevOps Server 2019 Update 1.1 o eseguire l'aggiornamento da Azure DevOps Server 2019 o Team Foundation Server 2012 o versione successiva.

Questa versione include correzioni per i bug seguenti:

Azure Boards (Pannelli di Azure)

• Quando si crea un nuovo elemento di lavoro dal backlog del prodotto, il campo Titolo non viene inizializzato con il valore predefinito nel modello di processo.
• Lentezza e timeout nell'uso di Azure Boards.
• Il valore Revised By non è corretto nei collegamenti degli elementi di lavoro.

Azure Pipelines

• Nelle notifiche di Pipeline, campi come Durata possono essere nulli in alcune impostazioni locali.
• Il percorso del template potrebbe non puntare a un file JSON valido in una pipeline che include una Distribuzione del Gruppo di Risorse di Azure.
• La pagina delle impostazioni di conservazione a livello di raccolta viene visualizzata nelle pagine delle impostazioni del progetto.

Piani di test di Azure

• La modifica dei campi in Piani di test è lenta.
• Nel caso di test, quando si apre da Boards (anziché dai piani di test), non vengono visualizzati i dettagli del passaggio condiviso.

Generale

• Raccolte non vengono ordinate in ordine alfabetico.

Amministrazione

• utilizzo elevato della memoria.
• I server con configurazioni di bilanciamento del carico dovevano aggiungere in modo esplicito l'origine pubblica alla voce del Registro di sistema AllowedOrigins.
• I clienti che eseguono l'installazione su SQL Azure non visualizzano la finestra di dialogo Versione di valutazione completa.
• L'installazione delle estensioni restituisce l'errore "Messaggio di errore Contributo mancante (ms.vss-dashboards-web.widget-sdk-version-2)".
• Quando si configura La ricerca elastica, si verifica un errore: "L'utente non è autorizzato".
• Errori di indicizzazione e interrogazioni in Elasticsearch durante l'aggiornamento da TFS 2018 Update 2 o versione successiva.
• Il passaggio "Create Warehouse" ha esito negativo durante la configurazione di Azure DevOps Server.

Questa versione include l'aggiornamento seguente:

• Supporto per SQL Server 2019.

Data di rilascio di Azure DevOps Server 2019 Update 1 Patch 1: 10 settembre 2019

È stata rilasciata una patch di sicurezza per Azure DevOps Server 2019 Update 1 che corregge il bug seguente. Per altre informazioni, vedere il post di blog .

• CVE-2019-1306: vulnerabilità di esecuzione remota del codice in Wiki

Data di rilascio dell'aggiornamento 1 di Azure DevOps Server 2019: 20 agosto 2019

Data di rilascio RC2: 23 luglio 2019

RC2 include diverse correzioni di bug a partire da RC1 ed è la versione preliminare pianificata finale.

Data di rilascio RC1: 2 luglio 2019

Riepilogo delle novità di Azure DevOps Server 2019 Update 1

Azure DevOps Server 2019 Update 1 introduce molte nuove funzionalità. Alcuni dei punti salienti includono:

• nuovo processo di base
• Query per il lavoro relativo all'inizio del giorno, della settimana, del mese o dell'anno
• Accettare e gestire i problemi in GitHub durante la pianificazione in Azure Boards
• Rieseguire il build scaduto per il completamento automatico delle richieste pull
• Nuovi tipi di merge per completare le richieste pull
• Attivare le pipeline YAML con tag
• Assistente per attività per la modifica di file YAML
• editor Web con IntelliSense per le pipeline YAML
• Gestire le versioni di GitHub usando le pipeline
• Test trend dei risultati (Avanzato) widget
• Informazioni sulla provenienza delle confezioni
• supporto per i pacchetti Python
• Origini Upstream per Maven
• Incorporare i risultati delle query di Azure Boards in Wiki
• Permalinks per le pagine Wiki
• Notifiche nelle pagine wiki
• L'estensione Analytics non è più necessaria per l'uso di Analytics

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

• generale
• Schede
• Repos
• pipeline
• Piani di Test
• artefatti
• wiki
• Rendicontazione

Generale

Tema scuro

Il tema scuro è stata una funzionalità diffusa in Azure DevOps Services ed è ora disponibile in Azure DevOps Server. È possibile attivare il tema scuro selezionando Tema dal menu sotto l'avatar in alto a destra di ogni pagina.

Bacheche

Nuovo processo di base

In passato, Agile è stato il processo predefinito per i nuovi progetti, offrendo un set affidabile e flessibile di tipi di elementi di lavoro e stati per soddisfare un'ampia gamma di metodi di recapito del progetto. Per alcuni team, che hanno familiarità con altri strumenti o che stanno crescendo e vogliono adottare un set di strumenti più potente, vogliono iniziare rapidamente a usare la terminologia con cui hanno più familiarità.

Il nuovo processo Basic fornisce tre tipi di elemento di lavoro (Epiche, Problemi e Attività) per pianificare e tenere traccia del lavoro. È consigliabile usare Problemi per tenere traccia di elementi come storie utente, bug e funzionalità durante l'uso di Epics per raggruppare i problemi in unità di lavoro più grandi. Spostare man mano gli elementi lungo un flusso di lavoro semplice: Da fare, In corso e Fatto.

Consulta la documentazione per i problemi e le attività per aiutarti a iniziare con il tuo nuovo progetto.

Ordine dei valori di stato nel modulo dell'elemento di lavoro

In precedenza, il valore di stato nel modulo dell'elemento di lavoro era ordinato alfabeticamente. Con questo aggiornamento è stato modificato il modo in cui i valori di stato vengono ordinati in modo che corrispondano all'ordine del flusso di lavoro nelle impostazioni del processo. È anche possibile modificare l'ordine degli stati in ogni categoria nelle impostazioni di personalizzazione dello stato.

L'abilitazione delle funzionalità non è più disponibile

I clienti dovranno aggiornare manualmente il codice XML per ogni progetto per abilitare le nuove funzionalità dopo l'aggiornamento della raccolta.

Per informazioni su come abilitare funzionalità specifiche, vedere la documentazione .

Organizzare i materiali di riferimento con allegati di elementi di lavoro più ricchi

Il collegamento di file agli elementi di lavoro consente all'utente e al team di centralizzare i materiali di riferimento in modo che siano sempre vicini quando sono necessari. È ora più facile aggiungere un nuovo allegato semplicemente trascinando e rilasciando il file in qualsiasi punto del modulo dell'elemento di lavoro. È possibile continuare a visualizzare gli allegati come elenco o passare a una visualizzazione griglia per visualizzare un'anteprima di anteprima. Fare doppio clic sul file per aprire un'anteprima e scorrere rapidamente le informazioni necessarie.

Condividi la scheda del team utilizzando un badge

Il file README del repository è spesso la casa a cui il team del progetto si rivolge per informazioni su come contribuire e usare la soluzione. Ora, come puoi fare con uno stato di compilazione o distribuzione in Azure Pipelines, puoi aggiungere al README un badge per la board del tuo team in Azure Boards. È possibile configurare il badge in modo da visualizzare solo la in corso colonne o tutte le colonne e persino rendere il badge visibile pubblicamente se il progetto è open source.

Se il file README è basato su Markdown, è sufficiente copiare l'esempio Markdown dalla pagina delle impostazioni delle notifiche di stato e incollarlo nel file.

Query per il lavoro relativo all'inizio della giornata, della settimana, del mese o dell'anno

Sebbene i team si concentrino spesso sul lavoro nel contesto di ciò che sta per arrivare o basate sulle iterazioni degli sprint, è spesso interessante esaminare il lavoro attraverso l'obiettivo del calendario per riportare tutto il lavoro che si è svolto lo scorso mese o nel primo trimestre dell'anno. È ora possibile usare il nuovo set di macro @StartOf seguente insieme a qualsiasi campo basato su data per eseguire query in base all'inizio del giorno, della settimana, del mese o dell'anno:

• @StartOfYear
• @StartOfMonth
• @StartOfWeek
• @StartOfDay

Ognuna di queste macro accetta anche una nuova stringa di modifica che consente di spostare i dati in base a unità di data diverse. Ad esempio, è possibile scrivere una query per trovare tutti gli elementi di lavoro completati nel primo trimestre di quest'anno eseguendo una query su State Change Date >= @StartOfYear e State Change Date <= @StartOfYear("+3M"). Per altre informazioni, vedere la documentazione relativa alle macro di query .

Modificare ed eliminare commenti di discussione

Siamo lieti di annunciare la disponibilità di una funzionalità altamente votata della Developer Community, ovvero la modifica e l'eliminazione dei commenti nella discussione dell'elemento di lavoro in Azure Boards. Per modificare il commento, basta passare il puntatore del mouse su qualsiasi commento di cui si è proprietari e verranno visualizzati due nuovi pulsanti. Se si fa clic sull'icona a forma di matita, si accede alla modalità di modifica e si può semplicemente apportare le modifiche e premere il pulsante "Aggiorna" per salvare le modifiche.

Quando si fa clic sul menu di overflow, verrà visualizzata l'opzione per eliminare il commento. Dopo aver fatto clic su questa opzione, verrà richiesto di confermare che si desidera eliminare il commento e il commento verrà eliminato.

Si avrà una traccia completa di tutti i commenti modificati ed eliminati nella scheda Cronologia del modulo dell'elemento di lavoro. Si noterà anche che l'interfaccia utente dell'esperienza di discussione è stata aggiornata per renderla più moderna e interattiva. Sono state aggiunte bolle intorno ai commenti per rendere più chiaro dove iniziano e terminano i singoli commenti.

Esportare i risultati delle query in un file CSV

È ora possibile esportare i risultati delle query direttamente in un file di formato CSV dal Web.

Passare agli elementi di lavoro di Azure Boards direttamente dalle menzioni in qualsiasi commento di GitHub

Ora quando si menziona un elemento di lavoro all'interno del commento di un problema, di una richiesta pull o di un commit in GitHub usando la sintassi di AB#{work item ID}, tali menzioni diventeranno collegamenti ipertestuali su cui è possibile fare clic per passare direttamente all'elemento di lavoro indicato.

Questo non crea un collegamento formale che includisce l'elemento di lavoro in Azure Boards per ogni conversazione correlata, ma offre al team un modo per fornire altre informazioni sugli elementi di lavoro durante la discussione del codice o di un problema segnalato dal cliente. Consultare la documentazione sull'integrazione di Azure Boards con GitHub per ulteriori informazioni .

Accettare e gestire le segnalazioni in GitHub mentre si pianifica in Azure Boards.

È ora possibile collegare elementi di lavoro in Azure Boards con problemi correlati in GitHub. Con questo nuovo tipo di collegamento, sono ora possibili diversi altri scenari. Se il team vuole continuare ad accettare segnalazioni di bug dagli utenti, ad esempio come problemi all'interno di GitHub, ma correlare e organizzare il lavoro del team nel complesso in Azure Boards, è ora possibile.

La stessa sintassi di menzione usata dal team per i commit e le richieste pull si applica ancora e naturalmente è possibile collegare manualmente in Azure Boards con l'URL del problema. Per altre informazioni, vedere la documentazione GitHub & Azure Boards.

Visualizzare rapidamente l'attività GitHub collegata dalla scheda Kanban

Quando si esamina la bacheca Kanban o come team, spesso si hanno domande come "ha ancora iniziato lo sviluppo di questo elemento?" o "è ancora questo elemento in fase di revisione?" Con le nuove annotazioni di GitHub nella scheda Kanban, è ora possibile ottenere un rapido senso della posizione di un elemento e passare direttamente al commit di GitHub, alla richiesta pull o al problema per altri dettagli. Per altre informazioni su questa e sulle altre annotazioni per attività e test, vedere la documentazione Personalizzare le schede.

Repos

Bozza di richieste pull

Per evitare che i pull request vengano completati prima che siano pronti e per semplificare la creazione di lavoro in corso che potrebbe non coinvolgere tutti, ora supportiamo i pull request in bozza.

È possibile creare richieste pull in bozza selezionando Crea come bozza dal menu a discesa Crea durante la creazione di una richiesta pull.

Dopo aver creato una bozza di richiesta pull, verrà visualizzato un badge che ne indica lo stato accanto al titolo.

Le richieste di pull in bozza non comprendono revisori né eseguono compilazioni per impostazione predefinita, ma permettono di aggiungere revisori manualmente e eseguire compilazioni. Per trasformare la pull request in una normale pull request, è sufficiente fare clic sul pulsante Pubblica dalla pagina dei dettagli della pull request.

Rieseguire il build scaduto per le pull request a completamento automatico

Azure Repos ora accoderà automaticamente i build scaduti attivati da un criterio per le pull request. Questo vale per le pull request che hanno superato tutti gli altri criteri e sono pronte per il completamento automatico.

In precedenza, quando le pull request avevano criteri come i revisori richiesti, il processo di approvazione poteva richiedere troppo tempo e una build associata poteva scadere prima che un revisore approvasse la pull request. Se la richiesta pull fosse impostata per il completamento automatico, rimarrebbe bloccata fino a quando un utente non accodasse manualmente il build scaduto. Con questa modifica, la build verrà accodata automaticamente, consentendo il completamento automatico della pull request dopo una build riuscita.

Visualizzare solo il file sinistro o destro in una richiesta pull

Attualmente, quando si visualizzano le modifiche dei file in una pull request, è possibile usare la modalità diff side-by-side o diff inline. Abbiamo ricevuto feedback che molti di voi vogliono solo visualizzare il file originale o il file modificato, senza confrontarli, quindi abbiamo aggiunto una nuova opzione che consentirà di visualizzare singolarmente il file sinistro o il file destro.

Nuovi tipi di merge per il completamento delle richieste pull

Sono ora disponibili altre opzioni quando si uniscono le modifiche da una richiesta pull al ramo di destinazione. È stato aggiunto il supporto per due delle funzionalità più richieste nella community degli sviluppatori: Fast-Forward unione di e Semi-Linear unione di (denominata anche "Rebase e Merge").

Ora vedrai queste nuove opzioni disponibili nella finestra di dialogo Completa richiesta di pull:

La pagina di amministrazione dei criteri aggiornata consente agli amministratori di controllare quali strategie di merge sono consentite in un ramo o una cartella di rami.

Ci sono alcune situazioni in cui non è possibile eseguire il rebasing durante il completamento della richiesta pull:

• Se un criterio nel ramo di destinazione impedisce l'uso di strategie di ribase, sarà necessaria l'autorizzazione per eseguire l'override delle politiche del ramo.
• Se il ramo di origine della richiesta pull ha delle politiche, non sarà possibile eseguire il rebase. Il rebase modificherà il ramo di origine senza passare attraverso il processo di approvazione delle politiche.
• Se hai usato l'estensione Merge Conflict per risolvere i conflitti di merge. Le risoluzioni dei conflitti applicate a un'unione a tre vie raramente hanno esito positivo (o anche valido) durante il rebase di tutti i commit in una pull request uno alla volta.

In tutti questi casi, è comunque possibile ribasare il ramo in locale ed eseguire il push sul server oppure unire le modifiche durante il completamento del pull request.

Filtrare per ramo di destinazione nelle pull request

Le richieste pull consentono al team di esaminare il codice e fornire commenti e suggerimenti sulle modifiche prima di unirle nel ramo principale. Sono diventati una parte importante dei flussi di lavoro di molti team perché è possibile esaminare le modifiche proposte, lasciare commenti e votare per approvare o rifiutare le modifiche al codice.

Per facilitare la ricerca delle pull request, abbiamo aggiunto un'opzione di filtro per consentirti di cercare le pull request usando il ramo di destinazione.

È anche possibile usare il filtro dei rami di destinazione per personalizzare la visualizzazione delle richieste pull nella scheda Mine.

Consenti alle estensioni di aggiungere evidenziazione della sintassi e completamento automatico

Attualmente viene pubblicata l'evidenziazione della sintassi per un subset di lingue supportate dall'editor Monaco. Tuttavia, molti di voi vogliono creare un'evidenziazione della sintassi personalizzata per i linguaggi non supportati.

Con questo aggiornamento è stato aggiunto un punto di estendibilità che consente alle estensioni di aggiungere l'evidenziazione della sintassi e il completamento automatico a Esplora file e alle visualizzazioni richieste pull.

È possibile trovare un esempio di estensione che illustra questa funzionalità qui.

È stato inoltre aggiunto il supporto per l'evidenziazione della sintassi del linguaggio Kusto.

Punto di estensione per la creazione del repository

Abbiamo aggiunto un punto di estensione per permetterti di aggiungere nuovi elementi al selettore di repository. Questo punto di estensione consente di aggiungere azioni personalizzate (reindirizzamenti, popup e così via) al menu di selezione repository, abilitando flussi come scenari di creazione di repository alternativi.

Supporto migliorato per la codifica

In precedenza, la modifica e il salvataggio dei file sul Web salvavano solo come codifica UTF-8 e non ti è stato chiesto quando la codifica del file è cambiata. Verrà ora visualizzato un avviso quando si tenta di salvare un file che non è codificato tramite il Web (che supporta solo la codifica UTF). È stato inoltre aggiunto il supporto per la codifica UTF-16 e UTF-32 tramite l'endpoint push Web. Ciò significa che il tipo di codifica verrà mantenuto in modo che non sia necessario riscriverli come UTF-8.

Lo screenshot seguente mostra ed esempio della finestra di dialogo che verrà visualizzata quando si introducono modifiche di codifica da un push Web.

Supporto per il comando 'go get' in Azure Repos

Go è un linguaggio di programmazione open source, noto anche come Golang. In Go è possibile usare il comando get per scaricare e installare pacchetti e dipendenze. Con questo aggiornamento è stato aggiunto il supporto per go get all'interno di un repository Azure DevOps. Con go getsarà possibile scaricare i pacchetti con le relative dipendenze denominate dai percorsi di importazione. È possibile usare la parola chiave import per specificare il percorso di importazione.

Pipeline

Editor Web con IntelliSense per le pipeline YAML

Se si usa YAML per definire le pipeline, è ora possibile sfruttare le nuove funzionalità dell'editor introdotte con questa versione. Sia che si stia creando una nuova pipeline YAML o modificando una pipeline YAML esistente, sarà possibile modificare il file YAML all'interno dell'editor Web della pipeline. Usare CTRL+SPAZIO per il supporto di IntelliSense durante la modifica del file YAML. Verranno visualizzati gli errori di sintassi evidenziati e si otterrà anche assistenza per la correzione di tali errori.

Assistente per la modifica di file YAML

Continuiamo a ricevere un sacco di commenti e suggerimenti che chiedono di semplificare la modifica dei file YAML per le pipeline, quindi stiamo aggiungendo un assistente attività all'editor YAML. Con questo, si avrà la stessa esperienza familiare per l'aggiunta di una nuova attività a un file YAML come nell'editor classico. Questo nuovo assistente supporta la maggior parte dei tipi di input di attività comuni, ad esempio elenchi di selezione e connessioni al servizio. Per usare il nuovo assistente attività, selezionare Modifica in una pipeline basata su YAML e quindi selezionare l'Assistente attività .

Attivare le pipeline YAML con i tag

Le pipeline YAML possono essere attivate quando i tag vengono aggiunti a un commit. Ciò è utile per i team i cui flussi di lavoro includono tag. Ad esempio, è possibile avviare un processo quando un commit viene contrassegnato come "ultima versione conosciuta come buona".

È possibile specificare i tag da includere ed escludere. Per esempio:

trigger:
  tags:
    include:
    - releases/*
    exclude:
    - releases/old*

Dichiarare le risorse del contenitore in linea

In precedenza, era necessario dichiarare le risorse del contenitore nelle pipeline YAML e poi riferirsi a esse per nome. È ora disponibile una sintassi inline per i casi in cui non si farà riferimento più volte al contenitore.

jobs:
- job: my-container-job
  container:
    image: microsoft/dotnet:latest

Impostazione dell'annullamento automatico di una pipeline esistente quando viene aggiornata una richiesta pull

Per impostazione predefinita, le pipeline attivate dalle richieste pull verranno annullate se viene eseguito il push di un nuovo commit nella stessa richiesta pull. Ciò è consigliabile nella maggior parte dei casi perché in genere non si vuole continuare a eseguire una pipeline nel codice non aggiornato. Se non si vuole questo comportamento, è possibile aggiungere autoCancel: false al trigger della PR.

pr:
  branches:
    include:
    - main
    - releases/*
  autoCancel: false

Scegliere la directory del codice controllato nelle pipeline YAML

In precedenza, abbiamo estratto i repository nella directory s dentro $(Agent.BuildDirectory). È ora possibile scegliere la directory in cui verrà estratto il repository Git per l'uso con le pipeline YAML.

Usare la parola chiave path su checkout e si avrà il controllo della struttura di cartelle. Di seguito è riportato un esempio del codice YAML che è possibile usare per specificare una directory.

steps:
- checkout: self
  path: my-great-repo

In questo esempio, il codice verrà estratto nella directory my-great-repo nell'area di lavoro dell'agente. Se non si specifica un percorso, il repository continuerà a essere estratto in una directory chiamata s.

Nuove attività del servizio app di Azure ottimizzate per YAML

Sono ora supportate quattro nuove attività che offrono un modo semplice e potente per distribuire Servizi app di Azure tenendo presenti gli sviluppatori moderni. Queste attività hanno una sintassi YAML ottimizzata, semplificando e intuitivamente la creazione di distribuzioni in AppServices di Azure, tra cui App Web, FunctionApps, WebApps per contenitori e FunctionApp per contenitori in piattaforme Windows e Linux.

È supportata anche una nuova attività di utilità per la trasformazione dei file e la sostituzione delle variabili per i formati XML e JSON.

Modifiche alle autorizzazioni predefinite per i nuovi progetti

Fino ad adesso, i collaboratori del progetto non potevano creare pipeline a meno che non venisse loro concessa esplicitamente l'autorizzazione "Crea build definition". Per i nuovi progetti, i membri del team possono creare e aggiornare facilmente le pipeline. Questa modifica ridurrà gli ostacoli per i nuovi clienti che si integrano in Azure Pipelines. È sempre possibile aggiornare le autorizzazioni predefinite per il gruppo Collaboratori e limitare l'accesso.

Gestire le versioni di GitHub usando le pipeline

Le versioni di GitHub sono un ottimo modo per creare pacchetti e fornire software agli utenti. Microsoft è lieta di annunciare che è ora possibile automatizzarla usando l'attività Di rilascio di GitHub in Azure Pipelines. Usando l'attività è possibile creare una nuova versione, modificare le versioni bozza/pubblicate esistenti o eliminare quelle meno recenti. Supporta funzionalità come il caricamento di più asset, il contrassegno di una versione come versione non definitive, il salvataggio di una versione come bozza e molti altri ancora. Questa attività ti aiuta anche a creare note di rilascio. Può anche calcolare automaticamente le modifiche (commit e problemi associati) apportate in questa versione e aggiungerle alle note sulla versione in un formato descrittivo.

Ecco il semplice YAML per l'attività:

task: GithubRelease@0 
displayName: 'Create GitHub Release'      
inputs:
  githubConnection: zenithworks
  repositoryName: zenithworks/pipelines-java
  assets: $(build.artifactstagingdirectory)/*.jar

Una versione di GitHub di esempio creata usando questa attività:

Collegamenti a righe specifiche in un log di compilazione

È ora possibile condividere un collegamento a righe specifiche nel log di compilazione. Ciò consente di collaborare con altri membri del team nella diagnosi degli errori di compilazione. È sufficiente selezionare le righe di un log dalla visualizzazione dei risultati per ottenere un'icona di collegamento.

Miglioramenti dell'autorizzazione delle risorse

È necessario garantire la sicurezza per le risorse protette , ad esempio connessioni al servizio, gruppi di variabili, pool di agenti, file protetti, quando si fa riferimento a un file YAML. Allo stesso tempo, volevamo semplificare la configurazione e l'uso di pipeline che usano questi tipi di risorse per scenari non di produzione. In precedenza, è stata aggiunta un'impostazione per contrassegnare una risorsa come "autorizzata per l'uso in tutte le pipeline".

Con questo aggiornamento, è più semplice risolvere un problema di autorizzazione delle risorse anche se non è stata contrassegnata una risorsa come tale. Nella nuova esperienza, quando una compilazione ha esito negativo a causa di un errore di autorizzazione della risorsa, verrà visualizzata un'opzione per autorizzare in modo esplicito l'uso di tali risorse nella pipeline e quindi procedere. I membri del team con autorizzazioni per autorizzare le risorse potranno completare questa azione direttamente da una compilazione non riuscita.

Nuovi punti di contributo dell'estensione nella scheda Test Pipelines

È stato continuato a rendere il framework di estensione più potente aggiungendo due nuovi punti di contributo nella scheda Risultati test in Pipeline. Questo consentirà alle estensioni del Marketplace di offrire esperienze di creazione di report più personalizzate e aggiungere ulteriore interattività.

I due punti di contributo sono:

1. pulsante Azione personalizzata nella barra degli strumenti

   A volte può essere necessario eseguire un'azione come l'aggiornamento dei dati di un'API o l'esecuzione di strumenti personalizzati usando i metadati dei risultati del test. Con questo punto di contributo, è possibile creare estensioni che usano il contesto immediato del risultato del test selezionato per aggiungere un'azione personalizzata al pulsante *Azione personalizzata- .

   

2. Scheda Dettagli Personalizzati nel Riquadro dei Dettagli

   È possibile che si disponga di un'ampia gamma di flussi di lavoro di utilizzo dei report di test e che si vogliano visualizzare punti dati diversi rispetto ai test non superati per il debug e l'analisi. Usando questo punto di contributo, il team può aggiungere una nuova scheda al riquadro dei dettagli che verrà visualizzato quando si seleziona la riga dei risultati del test nella griglia dei dati. Questa nuova scheda può visualizzare una visualizzazione con contenuto statico o dati dinamici recuperati tramite API interne o esterne.

Eseguire una sola volta l'agente

Se si utilizza un'infrastruttura come Azure Container Instances per eseguire agenti privati elastici, spesso si desidera che ogni agente accetti un solo processo prima di terminare. Finora, questo non è stato facile perché è stato necessario terminare l'agente (probabilmente causando un errore da segnalare) o accettare il rischio che un agente possa ricevere un altro incarico prima di poterlo arrestare. Con questo aggiornamento è stato aggiunto il flag --once alla configurazione dell'agente. Quando si configura l'agente in questo modo, accetta un solo compito e poi si spegne.

Aggiornamento dell'interfaccia utente del pool di agenti

La pagina di gestione dei pool di agenti nelle impostazioni del progetto è stata aggiornata con una nuova interfaccia utente. Ora puoi vedere facilmente tutti i lavori in esecuzione in un pool. Inoltre, è possibile scoprire perché un job non è in esecuzione.

Eseguire la distribuzione in destinazioni con errori nel gruppo di distribuzione

Per impostazione predefinita, Azure Pipelines veniva utilizzato per eseguire nuovamente tutti i processi quando ridistribuivate un'esecuzione precedentemente non riuscita. È ora possibile eseguire l'override di questo comportamento configurando l'opzione di distribuzione durante la distribuzione. Selezionando l'opzione Tutti i processi e limitare alle destinazioni non riuscite in un gruppo di distribuzione, la ri-esecuzione eseguirà tutti i processi e salterà le distribuzioni verso le destinazioni già aggiornate.

Ridistribuire automaticamente in caso di errore

Quando una distribuzione in una fase ha esito negativo, Azure Pipelines ora può ridistribuire automaticamente l'ultima distribuzione riuscita. È possibile configurare la fase per distribuire automaticamente l'ultima versione riuscita configurando il trigger di ridistribuzione automatica nelle condizioni di post-distribuzione . Si prevede di aggiungere altri eventi e azioni attivati alla configurazione di ridistribuimento automatico in uno sprint futuro. Per altre informazioni, vedere la documentazione sui gruppi di distribuzione .

Collegamento del servizio di annotazioni di Grafana

Ora supportiamo un nuovo hook di servizio che consente di aggiungere annotazioni di Grafana per gli eventi di Distribuzione completata a una dashboard di Grafana. Ciò consente di correlare le distribuzioni con le modifiche apportate alle metriche dell'applicazione o dell'infrastruttura visualizzate in un dashboard di Grafana.

Eseguire interrogazioni sulle attività degli avvisi di Azure Monitor

La versione precedente dell'attività Query dei Monitor di Azure supportava solo l'esecuzione di query sugli avvisi nell'esperienza di monitoraggio classica. Con questa nuova versione del task, è possibile eseguire query sugli avvisi nell'esperienza di monitoraggio unificata recentemente introdotta da Azure Monitor.

Input inline del file di configurazione nell'attività Distribuisci in Kubernetes

In precedenza, l'attività di distribuzione Kubernetes richiedeva di fornire un percorso di file per la configurazione. È ora possibile aggiungere anche la configurazione inline.

Attività di installazione del Docker CLI

Questa attività consente l'installazione di qualsiasi versione dell'interfaccia della riga di comando di Docker negli agenti, come specificato dall'utente.

Ripristinare le pipeline di rilascio eliminate

L'eliminazione delle pipeline di versione inutilizzate consente di mantenere pulito l'elenco delle pipeline di versione, ma a volte si elimina qualcosa per errore. Con questo aggiornamento è ora possibile ripristinare una pipeline di versione eliminata negli ultimi 30 giorni. È stata aggiunta una nuova scheda al pannello sinistro della pagina Versioni che visualizzerà un elenco di pipeline di versione eliminate. Da questa visualizzazione è possibile ripristinare una pipeline di versione eliminata selezionando la pipeline dall'elenco e facendo clic sul pulsante Ripristina.

Notifiche in caso di errore di una richiesta di creazione della versione

È possibile impostare le notifiche per ricevere messaggi di posta elettronica man mano che si verificano modifiche alle compilazioni, alla codebase e ad altre operazioni. Ad esempio, è possibile impostare un avviso per ricevere una notifica quando viene assegnato un elemento di lavoro.

Con questo aggiornamento, abbiamo aggiunto una nuova sottoscrizione di notifica alla categoria release. Questa notifica verrà inviata tramite email quando una richiesta di creazione di una versione non va a buon fine. Uno scenario di esempio in cui può essere utile è quando una richiesta di creazione di una versione ha esito negativo perché non è disponibile una versione dell'artefatto. Per informazioni su come gestire le notifiche, vedere la documentazione qui.

Pianificare i rilasci quando la sorgente o la pipeline cambiano

In precedenza, quando si dispone di un trigger di rilascio pianificato, una versione verrebbe attivata anche quando non è stata rilevata alcuna modifica nell'artefatto upstream o nella definizione di versione. È stata aggiunta un'opzione al pannello Schedule release trigger (Pianifica rilascio) per pianificare le versioni solo se la versione dell'artefatto o la definizione di versione è stata modificata.

Punto di contributo per le variabili nella finestra di dialogo crea versione

In precedenza, i valori delle variabili necessari durante la creazione della versione devono essere immessi dall'utente senza assistenza o suggerimenti. Sono stati aggiunti punti di contribuzione alla Finestra di dialogo per creare una nuova versione per supportare le estensioni che consentiranno di impostare il valore di una variabile durante la creazione della versione.

Pubblicare sulle code di sessione dell'Azure Service Bus

Abbiamo esteso l'attività di build senza agente per includere la possibilità di pubblicare messaggi nelle code di sessione. Questa opzione è stata aggiunta all'attività Pubblica nel Service Bus di Azure.

Nuova opzione di sottoscrizione di Azure nella connessione al servizio Kubernetes

Le connessioni al servizio per le compilazioni e le versioni consentono di connettersi a servizi esterni e remoti per eseguire attività per una compilazione o una distribuzione. È possibile definire e gestire una connessione al servizio dalle impostazioni di amministrazione del progetto.

Con questo aggiornamento è stata aggiunta un'opzione di autenticazione al modulo di connessione al servizio Kubernetes. Ora puoi selezionare Sottoscrizione Azure per autenticare la connessione. Ciò semplifica la distribuzione in namespace specifici impostando le connessioni Kubernetes con la sottoscrizione di Azure e il nome del cluster.

Per un cluster con controllo degli accessi basato su ruoli abilitato, ServiceAccount e oggetti RoleBinding vengono creati nello spazio dei nomi scelto. L'oggetto RoleBinding limita le operazioni dell'account del servizio creato solo allo spazio dei nomi scelto. Per un cluster con controllo degli accessi in base al ruolo disabilitato, l'account del servizio creato dispone di autorizzazioni a livello di cluster attraverso i namespace.

Connessione al servizio registry di Docker tramite Azure Container Registry

È ora possibile creare una connessione al servizio registro Docker dalla pagina delle impostazioni del progetto. Per creare la connessione, scegliere un registro Azure Container in una delle sottoscrizioni associate all'identità di Azure Active Directory (AAD). Tutte le attività che richiedono connessioni al servizio ai registri contenitori, ad esempio Docker@2 e KubernetesManifest@0 supportano un unico modo per specificare una connessione.

Cercare in base al nome della cartella nelle definizioni di versione

È possibile organizzare le definizioni di versione archiviandole in cartelle. In precedenza non era possibile eseguire una ricerca in base alla cartella. È stato difficile trovare una definizione di versione specifica se sono state create molte cartelle. È ora possibile cercare in base al nome della cartella nella definizione di versione, semplificando la ricerca delle definizioni desiderate.

Compito di installazione dello strumento Duffle nel processo di sviluppo e rilascio

Duffle è uno strumento da riga di comando che consente di installare e gestire bundle di applicazioni native cloud (CNAB). Con I CNAB è possibile aggregare, installare e gestire app native del contenitore e i relativi servizi.

In questo aggiornamento è stata aggiunta una nuova attività per le pipeline di compilazione e versione che consente di installare una versione specifica del file binario Duffle.

Attività Kubernetes manifest

È stata aggiunta una nuova attività alle pipeline di versione per semplificare il processo di distribuzione nei cluster Kubernetes usando i file manifesto. Questa attività offre i vantaggi seguenti rispetto all'uso del file binario kubectl negli script:

• Sostituzione degli artefatti - L'azione di distribuzione prende come input un elenco di immagini container che può essere specificato insieme ai loro tag o digest. Questa viene inserita nella versione non template dei file manifest prima di applicarla al cluster per garantire che la versione corretta dell'immagine venga scaricata dai nodi del cluster.

• Stabilità del manifest: lo stato del rollout viene controllato per gli oggetti Kubernetes distribuiti al fine di incorporare i controlli di stabilità, calcolando così lo stato dell'attività come successo/fallimento.

• Annotazioni di tracciabilità: le annotazioni vengono aggiunte agli oggetti Kubernetes distribuiti per sovrapporre informazioni sulla tracciabilità di origine, progetto, pipeline ed esecuzione.

• Manifesto del bake: l'azione di bake dell'attività consente di incorporare i chart Helm nei file manifesto di Kubernetes in modo che possano essere applicati al cluster.

• Strategia di distribuzione: la scelta della strategia canary con l'azione di distribuzione comporta la creazione della percentuale desiderata di carichi di lavoro con suffisso -baseline e -canary, in modo che possano essere confrontati durante un compito di ManualIntervention, prima di utilizzare l'azione di promozione/rifiuto del compito per finalizzare la versione da conservare.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

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

Aggiornamenti per il task Docker

Abbiamo aggiornato l'attività Docker per semplificare l'esperienza di creazione della pipeline. Il comando buildAndPush può ora essere usato per compilare più tag per un repository di contenitori specifico ed eseguirne il push in più registri contenitori in un unico passaggio. L'attività può usare le connessioni del servizio registro Docker per l'accesso ai registri contenitori. I metadati di tracciabilità relativi al repository di origine, al commit e alla provenienza della compilazione vengono aggiunti come etichette alle immagini compilate usando questa attività.

steps:
- task: Docker@2
  displayName: Container registry login - ACR1 service connection
  inputs:
    command: login
    containerRegistry: acr1
- task: Docker@2
  displayName: Container registry login - ACR2 service connection
  inputs:
    command: login
    containerRegistry: acr2
- task: Docker@2
  displayName: Build and push images
  inputs:
    repository: test
    tags: |
      d1
      d2

Programma di installazione dello strumento Kubectl

È stata aggiunta una nuova attività che consente di installare una versione specifica del file binario Kubectl negli agenti. Le più recenti e semver stringhe di versione, ad esempio 'v1.14.0', vengono accettate come valori validi come input per la specifica della versione di Kubectl.

Miglioramenti all'integrazione di ServiceNow

Una funzionalità chiave per la collaborazione tra team consiste nell'consentire a ogni team di usare un servizio di propria scelta e di offrire un recapito end-to-end efficace. Con questo aggiornamento è stata migliorata l'integrazione di ServiceNow per supportare tutti i tipi di modifiche (normale, standard e di emergenza). Inoltre, è ora possibile specificare il gate usato per creare una nuova richiesta di modifica usando un modello esistente, in base al processo di Gestione dei servizi IT seguito nell'organizzazione. Infine, è anche possibile autorizzare le versioni in base alle richieste di cambiamento esistenti. In questo modo è possibile adottare il CD, senza dover modificare il processo consigliato dai team IT.

Supporto per Red Hat Enterprise Linux 6

Con questo aggiornamento è stato aggiunto il supporto dell'agente per Red Hat Enterprise Linux 6. È ora possibile configurare gli agenti destinati alla piattaforma Red Hat Enterprise Linux 6 per l'esecuzione di processi di compilazione e rilascio.

Supporto per il modulo Az di Azure PowerShell

Azure PowerShell offre un set di cmdlet che è possibile usare per gestire le risorse di Azure dalla riga di comando. Lo scorso dicembre, il modulo Az di Azure PowerShell è diventato disponibile ed è ora il modulo destinato alla gestione delle risorse di Azure.

In precedenza non è stato fornito supporto per il modulo Az di Azure PowerShell negli agenti ospitati. Con la nuova attività di Azure PowerShell versione 4.* nelle pipeline di build e rilascio, è stato aggiunto il supporto per il nuovo modulo Az per tutte le piattaforme. L'attività Azure PowerShell versione 3.* continuerà a supportare il modulo AzureRM. Tuttavia, per mantenere il passo con i servizi e le funzionalità di Azure più recenti, è consigliabile passare all'attività di Azure PowerShell versione 4.* appena possibile.

Il modulo Az ha una modalità di compatibilità che consente di usare gli script esistenti durante l'aggiornamento per usare la nuova sintassi. Per abilitare la compatibilità per il modulo Az, usare il comando Enable-AzureRmAlias. Gli alias consentono di usare i nomi dei cmdlet precedenti con il modulo Az. È possibile ottenere altri dettagli sulla migrazione dal modulo Azure RM al modulo Az di Azure PowerShell qui.

Per altre informazioni sul modulo Az di Azure PowerShell, vedere la documentazione qui.

Supporto dell'autenticazione di Azure Active Directory (AD) per l'attività SQL di Azure

L'attività SQL di Azure è stata migliorata per supportare la connessione a un database tramite Azure AD (integrated & Password) e una stringa di connessione oltre al supporto esistente per l'autenticazione di SQL Server.

Pubblicare artefatti di compilazione con percorsi di file lunghi

Fino ad ora, c'era una limitazione che impediva il caricamento degli artefatti di compilazione con percorsi più lunghi di 233 caratteri. Ciò potrebbe impedire il caricamento dei risultati di code coverage da compilazioni Linux e macOS con percorsi di file più lunghi del limite. Il limite è stato aggiornato per supportare percorsi lunghi.

Saltare l'integrazione continua (CI) per un commit

È ora possibile indicare ad Azure Pipelines di ignorare un commit e ignorare l'esecuzione di una pipeline che normalmente viene attivata dal commit. È sufficiente includere [skip ci] nel messaggio di commit del commit HEAD e Azure Pipelines ignorerà il CI. È anche possibile usare una delle varianti elencate di seguito. Questa funzionalità è supportata per i commit in Git Azure Repos e GitHub Enterprise Server.

• [skip ci] o [ci skip]
• skip-checks: true o skip-checks:true
• [skip azurepipelines] o [azurepipelines skip]
• [skip azpipelines] o [azpipelines skip]
• [skip azp] o [azp skip]
• ***NO_CI***

Piani di test

Widget tendenza risultati test (avanzato)

Il widget Test result trend (Advanced) offre visibilità quasi in tempo reale sui dati di test per più compilazioni e versioni. Il widget Test result trend (Advanced) visualizza l'andamento dei risultati dei tuoi test per le tue pipeline o attraverso diverse pipeline. È possibile usarlo per tenere traccia del numero giornaliero di test, velocità di superamento e durata del test. Mantenere la tracciabilità della qualità dei test nel tempo e migliorare le risorse per i test è fondamentale per mantenere una pipeline DevOps efficiente.

Il widget Test result trend (Advanced) consente di individuare gli outlier nei risultati del test e rispondere a domande come: i test richiedono più tempo del solito? Quale file di test o pipeline influisce sulla percentuale di successo complessiva? Quali sono i miei test che richiedono molto tempo?

Per rispondere a queste domande, il widget fornisce queste funzionalità:

• Visualizza una tendenza della frequenza di superamento e il conteggio dei risultati o della durata del test
• Presenta i risultati dei test in base a più pipeline di compilazione o di versione
• Usa le opzioni di creazione di grafici combinati per visualizzare due metriche sulla stessa tendenza
• Filtra nel tempo il conteggio dei test in base ai risultati.
• Filtra tutti i risultati dei test per ramo o test
• Mette in pila le metriche in base agli attributi di test, ad esempio priorità o ambiente
• Raggruppare i dati sui file di test, sul proprietario o sulle pipeline.

Il widget è altamente configurabile che consente di usarlo per un'ampia gamma di scenari.

Condividere i risultati dell'esecuzione dei test tramite URL

È possibile configurare test automatizzati da eseguire come parte di una compilazione o di una versione. I risultati dei test pubblicati possono essere visualizzati nella scheda Tests nel riepilogo della build o della versione. Con questo aggiornamento, abbiamo aggiunto una funzionalità Copia URL dei risultati così da poter condividere i risultati di una singola esecuzione di un test con altri membri del team.

I livelli di condivisione includono:

• Livello di esecuzione
• Livello di risultato
• Scheda singola selezionata nella sessione di test
• La condivisione è compatibile anche con le schede di estensioni configurate

Quando si condivide l'URL, i visualizzatori visualizzeranno i risultati dell'esecuzione del test nella visualizzazione a schermo intero.

Manufatti

Pacchetti NuGet con numeri di versione SemVer 2.0.0

In precedenza, Azure Artifacts non supportava i pacchetti NuGet con numeri di versione SemVer 2.0.0 (in genere numeri di versione che contengono la parte dei metadati di compilazione della versione, indicata da un +). È ora possibile salvare i pacchetti da nuget.org che contengono metadati di compilazione ed eseguire il push dei propri pacchetti con i metadati di compilazione. Secondo le specifiche SemVer e la politica di NuGet.org, non è possibile usare i metadati di compilazione per ordinare i pacchetti. Pertanto, non è possibile pubblicare sia 1.0.0+build1 che 1.0.0+build2 in Azure Artifacts (o nuget.org) perché tali versioni verranno considerate equivalenti e quindi soggette ai vincoli di immutabilità .

Informazioni sulla provenienza dei pacchetti

Con questo aggiornamento, è stato reso più semplice comprendere la provenienza dei pacchetti: chi o cosa li ha pubblicati e da quale commit del codice sorgente provengono. Queste informazioni vengono popolate automaticamente per tutti i pacchetti pubblicati usando NuGet, npm, Mavene Twine Authenticate (per Python) in Azure Pipelines.

Statistiche di utilizzo dei pacchetti

Fino ad ora, Azure Artifacts non ha fornito un modo per misurare l'utilizzo o la popolarità dei pacchetti. Con questo aggiornamento, è stato aggiunto un conteggio di Download e Utenti sia all'elenco dei pacchetti che alle pagine dei dettagli del pacchetto. È possibile visualizzare le statistiche sul lato destro di una delle due pagine.

Supporto per i pacchetti Python

Azure Artifacts può ora ospitare pacchetti Python: entrambi i pacchetti che si producono manualmente e i pacchetti upstream salvati dal pyPI pubblico. Per altre informazioni, vedere il post di blog sull'annuncio e la documentazione .

Ora è possibile ospitare tutti i pacchetti NuGet, npm, Maven e Python nello stesso feed.

Fonti principali per Maven

Le sorgenti upstream sono ora disponibili per i feed Maven. Questo include il repository centrale primario di Maven e i feed di Azure Artifacts. Per aggiungere upstream Maven a un feed esistente, visitare Impostazioni feed, selezionare il pivot Origini upstream, quindi selezionare Aggiungi origine upstream.

Supporto proxy per le attività correlate a Artifacts

Finora, molte attività di compilazione relative agli Artifacts non hanno fornito supporto completo per l'infrastruttura proxy di Azure Pipelines, il che ha portato a sfide nell'utilizzo delle attività dagli agenti locali. Con questo aggiornamento è stato aggiunto il supporto per i proxy alle attività seguenti:

• Npm@1 ('npm' nella finestra di progettazione)
• NuGetCommand@2 ('NuGet' nella finestra di progettazione): solo comandi di ripristino e push
• DotNetCoreCLI@2 ('.NET Core' nella finestra di progettazione): comandi di ripristino e di push di NuGet solo
• NpmAuthenticate@0, PipAuthenticate@0 e TwineAuthenticate@0 ('[type] Authenticate' nella finestra di progettazione): queste attività supportano proxy durante l'acquisizione di token di autenticazione, ma è comunque necessario configurare eventuali attività/script/strumenti successivi per usare anche il proxy. In alternativa, queste attività non configurano il proxy per lo strumento sottostante (npm, pip, twine).
• NuGetToolInstaller@0, NodeTool@0, DotNetCoreInstaller@0 ('[type] Installer' nella finestra di progettazione)

Tutti i tipi di pacchetto Artifacts supportati nelle versioni

Fino ad ora, solo i pacchetti NuGet sono stati supportati nel tipo di artefatto di Azure Artifacts nelle versioni pipeline. Con questo aggiornamento sono supportati tutti i tipi di pacchetto Di Azure Artifacts, maven, npm e Python.

Viste degli artefatti supportate nelle versioni

In precedenza, il tipo di artefatto di Azure Artifacts poteva essere attivato solo quando sono state pubblicate nuove versioni del pacchetto nel feed. Abbiamo anche aggiunto il supporto per le visualizzazioni, quindi è possibile attivare i rilasci quando i pacchetti già presenti nel feed vengono trasferiti a una visualizzazione.

I criteri di conservazione possono ignorare i pacchetti scaricati di recente

Fino ad ora, i feed di Azure Artifacts hanno offerto criteri di conservazione di base che iniziano a eliminare le versioni precedenti del pacchetto quando è stato raggiunto un "numero massimo di versioni per pacchetto". Con questo aggiornamento è stata aggiunta la possibilità di ignorare i pacchetti scaricati di recente durante la pulizia. Per attivare, modifica il feed e seleziona la casella di controllo Ignora pacchetti scaricati di recente.

Incaricare chi può gestire i feed

In Azure Artifacts gli amministratori della raccolta di progetti (PCA) sono sempre stati in grado di amministrare tutti i feed in un server Azure DevOps. Con questo aggiornamento, le CA possono anche offrire questa possibilità ad altri utenti e gruppi, delegando così la possibilità di gestire qualsiasi feed.

Wiki

Modelli markdown per formule e video

Non è più necessario ricordare la sintassi markdown per aggiungere formule , video e tag YAML durante la modifica di un wiki. È ora possibile fare clic sul menu di scelta rapida nella barra degli strumenti e selezionare l'opzione desiderata.

Incorporare i risultati delle query di Azure Boards in Wiki

È ora possibile incorporare i risultati delle query di Azure Boards in una pagina wiki sotto forma di tabella. L'immagine seguente mostra un esempio di una pagina wiki con un elenco di tutte le funzionalità rilasciate e tutti i bug attivi nello sprint corrente incorporato nel wiki. Il contenuto visualizzato nella pagina utilizza una query di un elemento di lavoro esistente. Con questa nuova funzionalità è possibile creare contenuto dinamico e non è necessario preoccuparsi di aggiornare manualmente la pagina wiki.

I risultati della query possono essere aggiunti in due passaggi:

1. Fare clic sul pulsante "Risultati query" sulla barra degli strumenti di modifica.

2. Selezionare la query richiesta e fare clic sul pulsante "Inserisci".

I risultati della query possono ora essere visualizzati sotto forma di tabella dopo aver salvato la pagina.

Carattere a larghezza fissa per l'editor di Wiki Markdown

Con l'introduzione di tipi di carattere monospaced per l'editor Markdown wiki, la leggibilità non è più una sfida. Il codice sorgente Markdown è pulito e facile da leggere. Questa funzionalità è stata prioritizzata in base a questo ticket di suggerimento.

Permalink per le pagine wiki

Fino ad ora, i collegamenti alla pagina Wiki condivisa si sono interrotti se la pagina collegata è stata rinominata o spostata. Sono stati ora introdotti collegamenti permanenti aggiungendo un ID di pagina all'URL. In questo modo si garantisce che i collegamenti condivisi rimangano intatti man mano che il wiki cambia nel tempo.

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

Mostra lo stato dell'elemento di lavoro nelle pagine Wiki

In questo aggiornamento sono stati migliorati i riferimenti agli elementi di lavoro nelle pagine Wiki aggiungendo lo stato dell'elemento di lavoro alla pagina, insieme al relativo ID e titolo.

I riferimenti agli elementi di lavoro nei commenti delle Pull Request e nelle discussioni delle Boards mostreranno anche lo stato.

@mention utenti e gruppi

È ora possibile menzionare utenti e gruppi in una pagina wiki. In questo modo, documenti come la pagina di contatto di un team, documenti guida e documenti informativi risultano più ricchi. L'immagine seguente è un esempio che mostra una retrospettiva sprint con attività e la persona responsabile.

È anche possibile selezionare un utente o un gruppo dalla richiesta automatica digitando "@" nella pagina di modifica wiki. Anche la persona menzionata riceverà una notifica tramite posta elettronica.

Infine, è anche possibile fare clic sul @mentioned utente per visualizzare la scheda informazioni del profilo. Questa funzionalità è stata data priorità in base a questo suggerimento di funzionalità.

Notifiche nelle pagine wiki

Fino ad ora, non hai avuto modo di sapere quando il contenuto in una pagina wiki è stato modificato. È ora possibile seguire le pagine wiki per ricevere una notifica tramite posta elettronica quando la pagina viene modificata, eliminata o rinominata. Per tenere traccia delle modifiche apportate a un wiki, selezionare il pulsante Segui nella pagina wiki.

Questa funzionalità è stata assegnata in ordine di priorità in base questo ticket di suggerimento. Per altre informazioni, vedere la documentazione qui.

Supporto per i tag HTML

È ora possibile creare contenuti più avanzati nel wiki usando tag HTML. Di seguito sono riportate le operazioni che è possibile eseguire con i tag HTML.

1. È ora possibile creare sezioni collassabili all'interno delle tue pagine wiki usando i tag dettagli e riepilogo. È possibile aggiungere l'attributo "open" per mantenere i dettagli espansi per impostazione predefinita.

   

   Per altre informazioni sui dettagli del tag , vedere la documentazione qui.

   È stata data priorità a questo ticket di suggerimento .

   Nota

   Questo tag non è supportato nei browser Edge e Internet Explorer.

Miglioramento della creazione e modifica delle tabelle

Fino ad ora, la creazione e la modifica di tabelle in un wiki era difficile. Sono state apportate modifiche per semplificare l'aggiunta e la gestione delle tabelle nel wiki.

1. Creare una tabella dalla griglia

   Non è più necessario ricordare la sintassi della tabella markdown. È ora possibile creare facilmente una tabella markdown selezionando una griglia da 15 X 15. È sufficiente selezionare il numero necessario di colonne e righe per inserire una tabella con un solo clic.

   

   Questa funzionalità è stata assegnata in ordine di priorità in base ai ticket di suggerimento seguenti:

   • la vista tabella per il wiki
   • semplificare l'inserimento di tabelle in wiki

2. Migliore leggibilità delle tabelle

   È ora possibile attivare o disattivare ritorno a capo automatico per consentire all'editor di migliorare la leggibilità delle tabelle. La disabilitazione del ritorno a capo automatico aggiunge una barra di scorrimento che consente di visualizzare più facilmente il contenuto di tabelle grandi.

   

3. Formattazione automatica delle tabelle markdown

   Non è più necessario aggiungere spazi per allineare le colonne markdown. Con il pulsante Formatta tabelle, le tabelle markdown vengono formattate automaticamente aggiungendo spazi alle celle per allineare le colonne. Se hai tabelle di grandi dimensioni, usale con l'opzione disabilita ritorno a capo automatico per rendere le tabelle più facili da leggere.

   

   È anche possibile usare il collegamento CTRL+ MAIUSC + F per formattare le tabelle.

Rapportazione

L'estensione analisi non è più necessaria per l'uso di Analytics

L'analisi sta diventando sempre più parte integrante dell'esperienza di Azure DevOps. È una funzionalità importante per i clienti per aiutarli a prendere decisioni basate sui dati.

Per l'aggiornamento 1, siamo lieti di annunciare che i clienti non hanno più bisogno dell'estensione Analytics per l'uso di Analytics. I clienti possono ora abilitare Analisi in Impostazioni raccolta progetti. Si tratta di un processo semplice che è proprio all'interno del prodotto.

Ecco come i clienti possono abilitare Analytics:

1. Vai alle Impostazioni della Raccolta Progetti:

2. Fare clic su Abilita Analytics

E questo è tutto! Le esperienze basate sull'analisi verranno attivate per la raccolta.

Per impostazione predefinita, le nuove raccolte create nell'aggiornamento 1 e nelle raccolte di Azure DevOps Server 2019 con l'estensione Analytics installata che sono state aggiornate saranno abilitate per impostazione predefinita.

Per altre informazioni su Analytics e sulle esperienze abilitate:

• Scopri di più su e l'abilitazione di Analytics.
• Leggere la documentazione panoramica di Analytics.
• Leggere le funzionalità principali: gli widget analitici, Rapporto sui test con esito negativo frequente, integrazione con Power BIe l'Endpoint OData .
• Guarda questo video su Channel 9 su Azure DevOps Analytics.

Feedback

Ci piacerebbe sentire da te! È possibile segnalare un problema o fornire un'idea e monitorarla tramite Developer Community e ottenere consigli su Stack Overflow.