Note sulla versione di Azure DevOps Server 2019

Requisiti di sistema della | community | degli sviluppatori Condizioni | di licenza DevOps Blog | 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 Requisiti del server Azure DevOps. Per scaricare i prodotti Azure DevOps, visitare la pagina 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 di esecuzione della pipeline (compilazione) basato sulle 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.

Leggere il post di blog per altre informazioni su come eseguire l'aggiornamento sicuro da Azure DevOps Server 2019 ad Azure DevOps Server 2020.

Data di rilascio di Azure DevOps Server 2019.0.1 Patch 16: 14 novembre 2023

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

• Estendere l'elenco di caratteri consentiti per le attività di PowerShell 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

Gli aggiornamenti dell'agente di Azure Pipelines sono stati rilasciati con patch 15 rilasciati il 12 settembre 2023. Se gli aggiornamenti dell'agente non sono stati installati come descritto nelle note sulla versione per Patch 15, è consigliabile installare questi aggiornamenti prima di installare Patch 16. La nuova versione dell'agente dopo l'installazione di Patch 15 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	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9F9EFCED5034D2E5

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 

Data di rilascio di Azure DevOps Server 2019.0.1 Patch 15: 12 settembre 2023

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

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

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 2019.0.1 Patch 15.

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 

Data di rilascio di Azure DevOps Server 2019.0.1 Patch 14: 8 agosto 2022

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

• CVE-2023-36869: vulnerabilità spoofing del server Azure DevOps.

Data di rilascio di Azure DevOps Server 2019.0.1 Patch 13: 17 maggio 2022

È stata rilasciata una patch per Azure DevOps Server 2019.0.1 che corregge 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.0.1 Patch 12: 26 gennaio 2022

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

• È stata risolta la vulnerabilità di Elasticsearch rimuovendo la classe jndilookup dai file binari log4j.

Passaggi di installazione

1. Aggiornare il server con patch 12.
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. 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.

Nota

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

1. Aggiornare il server con patch 12.
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 C:\Program Files\{TFS Version Folder}\Search\zip nella cartella del file remoto elasticsearch.
4. Eseguire Configure-TFSSearch.ps1 -Operation update nel computer del server Elasticsearch.

Hash SHA-256: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

Data di rilascio di Azure DevOps Server 2019.0.1 Patch 11: 10 agosto 2021

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

• Correggere l'errore dell'interfaccia utente della definizione di compilazione.

Data di rilascio di Azure DevOps Server 2019.0.1 Patch 10: 13 aprile 2021

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

• CVE-2021-27067: divulgazione di informazioni

Per applicare patch 10, è necessario installare l'attività AzureResourceGroupDeploymentV2 .

Installazione dell'attività AzureResourceGroupDeploymentV2

Nota

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

Installa

1. Estrarre il pacchetto AzureResourceGroupDeploymentV2.zip in una nuova cartella nel computer. Ad esempio: 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. Creare un token di accesso personale con privilegi di accesso completo e copiarlo. Questo token di accesso personale verrà usato quando si esegue il comando 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.0.1 Patch 9: 8 dicembre 2020

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

• CVE-2020-1325: vulnerabilità spoofing del server Azure DevOps
• CVE-2020-17135: vulnerabilità spoofing del server Azure DevOps
• CVE-2020-17145: vulnerabilità di Azure DevOps Server e Team Foundation Server spoofing
• Correzione del problema relativo alla mancata elaborazione di tutti i risultati da parte del controllo della versione di Team Foundation

Importante

Leggere le istruzioni complete fornite di seguito prima di installare questa patch.

Installazione generale delle patch

Se si dispone di Azure DevOps Server 2019.0.1, è necessario installare Azure DevOps Server 2019.0.1 Patch 9.

Verifica dell'installazione

• Opzione 1: Eseguire devops2019.0.1patch9.exe CheckInstall, devops2019.0.1patch9.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 è installato in c:\Program Files\Azure DevOps Server 2019 per impostazione predefinita. Dopo aver installato Azure DevOps Server 2019.0.1 Patch 9, la versione sarà 17.143.30723.4 .

Installazione dell'attività AzurePowerShellV4

Nota

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

Prerequisiti

1. Installare il modulo Az di Azure PowerShell Azure PowerShell nel computer dell'agente privato.

2. Creare una pipeline con l'attività AzurePowerShellV4 . Nell'attività verrà visualizzato un solo errore non riuscita nell'attività.

Installa

1. Estrarre il pacchetto 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à 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. Il percorso del pacchetto estratto sarà D:\tasks (1)\AzurePowerShellv4.

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

Data di rilascio di Azure DevOps Server 2019.0.1 Patch 8: 8 settembre 2020

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

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

Data di rilascio di Azure DevOps Server 2019.0.1 Patch 7: 14 luglio 2020

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

• 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 durante la modifica dell'ereditarietà su Attivato o Disattivato nella definizione di compilazione XAML.

Data di rilascio di Azure DevOps Server 2019.0.1 Patch 6: 10 giugno 2020

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

• CVE-2020-1327: Assicurarsi che Azure DevOps Server sanifica gli input utente
• Aggiunta del supporto per SHA2 in SSH in Azure DevOps

Data di rilascio di Azure DevOps Server 2019.0.1 Patch 5: 10 marzo 2020

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

• 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.0.1 Patch 3: 10 settembre 2019

Microsoft ha rilasciato una patch di sicurezza per Azure DevOps Server 2019.0.1 che corregge i bug seguenti. Vedere il post di blog per altre informazioni.

• CVE-2019-1305: vulnerabilità cross site scripting (XSS) in Repos
• CVE-2019-1306: vulnerabilità di esecuzione remota del codice in Wiki

---

Data di rilascio di Azure DevOps Server 2019.0.1 Patch 2: 13 agosto 2019

Microsoft ha rilasciato una patch di sicurezza per Azure DevOps Server 2019.0.1 che corregge il bug seguente. Vedere il post di blog per altre informazioni.

• Sono state aggiunte informazioni alle connessioni al servizio per chiarire che sono autorizzate per tutte le pipeline per impostazione predefinita.

---

Data di rilascio di Azure DevOps Server 2019.0.1 Patch 1: 9 luglio 2019

Microsoft ha rilasciato una patch di sicurezza per Azure DevOps Server 2019.0.1 che corregge i bug seguenti. Vedere il post di blog per altre informazioni.

• CVE-2019-1072: vulnerabilità di esecuzione remota del codice nel rilevamento degli elementi di lavoro
• CVE-2019-1076: vulnerabilità di scripting tra siti (XSS) nelle richieste pull

---

Data di rilascio di Azure DevOps Server 2019.0.1: 21 maggio 2019

Azure DevOps Server 2019.0.1 è un rollup delle correzioni di bug. Include tutte le correzioni nelle patch di Azure DevOps Server 2019 rilasciate in precedenza. È possibile installare direttamente Azure DevOps Server 2019.0.1 o eseguire l'aggiornamento da Azure DevOps Server 2019 o Team Foundation Server 2012 o versione successiva.

Nota

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

Questa versione include correzioni per i bug seguenti:

Azure Boards

• "I criteri di campo per questo piano hanno un errore." durante la configurazione di un piano. Segnalato tramite la community degli sviluppatori.
• apiwitcontroller.executequery genera un'eccezione quando una query ha la stessa colonna più volte.
• Nel modello a oggetti client usando l'ambito oauth vso.work_full, WorkItemServer.DownloadFile() ha esito negativo.
• La copia di un'immagine incorporata da un campo dell'elemento di lavoro in un altro campo dell'elemento di lavoro in un progetto diverso può creare un'immagine interrotta.

Azure Repos

• "TF401019: GitRepositoryNotFoundException".

Azure Pipelines

• La scheda Analisi test ha una stella (*) che indica l'anteprima, anche se questa funzionalità non è in anteprima.
• Nella scheda Versioni l'azione per gestire la sicurezza viene ora visualizzata a tutti gli utenti indipendentemente dal fatto che possano modificare o meno le autorizzazioni.
• Nelle pagine di destinazione Delle versioni l'azione di rilascio iniziale stava creando una nuova versione, ma ora avvia la versione bozza.

Azure Test Plans

• Il filtro di 1 ora per TestRuns e TestResults CompletedDate è troppo granulare.
• Nel tipo di elemento di lavoro Test Case il tipo "Test Case" non deve essere localizzato.
• I test case non sono visualizzati in MTM o in un browser.
• Errore "Fase di convalida: non si dispone dell'autorizzazione per attivare le versioni nella pipeline di versione associata" durante l'esecuzione di test automatizzati da un piano di test. Segnalato tramite la community degli sviluppatori.
• Usando l'API delete test case, i test case possono essere eliminati da altri progetti. Segnalato tramite la community degli sviluppatori.
• Facendo clic su un collegamento a un elemento di lavoro in Test Runner viene aperto l'URL dell'elemento di lavoro all'interno di Test Runner anziché nel browser predefinito.
• Lo stato del test case non viene aggiornato per gli utenti che escono da Test Runner.
• Il nome utente e l'indirizzo di posta elettronica non sono visualizzati nell'elenco a discesa dell'utente in Test Runner.

Azure Artifacts

• Sposta su e Sposta giù non sono localizzati in Upstream.

Analisi

• I report di analisi possono mostrare dati incompleti perché il modello è contrassegnato come "pronto" prima che venga effettivamente completato.
• I widget velocità, burndown e burnup visualizzano diverse attività pianificate per gli utenti in fusi orari diversi.
• Un blocco può essere inserito nell'inserimento dati di Analytics durante l'esecuzione della manutenzione che può causare report non aggiornati.

Generali

• Gli elementi di spostamento a sinistra vengono compressi su Internet Explorer quando non c'è spazio sufficiente.

Amministrazione

• Registrazione aggiuntiva aggiunta all'aggiornamento della raccolta per facilitare il debug dei problemi.
• Quando TfsConfig offlineDetach ha esito negativo, il messaggio di errore non è interattivo.
• Il servizio TfsJobAgent si arresta in modo anomalo.
• L'estensione Di ricerca non viene installata al termine della configurazione.
• La console di amministrazione non risponde quando il database di configurazione è danneggiato.
• Gli hook del servizio potrebbero non elaborare correttamente le notifiche.
• L'indicizzazione di Ricerca codice non viene avviata dopo la configurazione di Ricerca.
• Nei risultati delle pagine di ricerca sono presenti stringhe non localizzate.

Questa versione include l'aggiornamento seguente:

Supporto per Visual Studio 2019 (VS2019) nell'attività Test di Visual Studio

È stato aggiunto il supporto per Visual Studio 2019 all'attività Test di Visual Studio nelle pipeline. Per eseguire test usando la piattaforma di test per Visual Studio 2019, selezionare le opzioni Più recenti o Visual Studio 2019 dall'elenco a discesa Versione della piattaforma di test.

---

Data di rilascio di Azure DevOps Server 2019 Patch 2: 14 maggio 2019

È stata rilasciata una patch di sicurezza per Azure DevOps Server 2019 che corregge i bug seguenti. Vedere il post di blog per altre informazioni.

• CVE-2019-0872: vulnerabilità di scripting tra siti (XSS) nei piani di test
• CVE-2019-0971: vulnerabilità di divulgazione delle informazioni nell'API Repos
• CVE-2019-0979: vulnerabilità di scripting tra siti (XSS) nell'hub utente

---

Data di rilascio di Azure DevOps Server 2019 Patch 1: 9 aprile 2019

È stata rilasciata una patch di sicurezza per Azure DevOps Server 2019 che corregge i bug seguenti. Vedere il post di blog per altre informazioni.

• CVE-2019-0857: Vulnerabilità di spoofing nel wiki
• CVE-2019-0866: vulnerabilità di esecuzione remota del codice nelle pipeline
• CVE-2019-0867: vulnerabilità di scripting tra siti (XSS) nelle pipeline
• CVE-2019-0868: vulnerabilità di scripting tra siti (XSS) nelle pipeline
• CVE-2019-0869: vulnerabilità di inserimento HTML nelle pipeline
• CVE-2019-0870: vulnerabilità di scripting tra siti (XSS) nelle pipeline
• CVE-2019-0871: vulnerabilità di scripting tra siti (XSS) nelle pipeline
• CVE-2019-0874: vulnerabilità di scripting tra siti (XSS) nelle pipeline
• CVE-2019-0875: vulnerabilità di elevazione dei privilegi in Boards

---

Data di rilascio di Azure DevOps Server 2019: 5 marzo 2019

Nota

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

---

Data di rilascio RC2: 22 gennaio 2019

Riepilogo delle novità di Azure DevOps Server 2019 RC2

A RC2 sono state aggiunte le funzionalità seguenti:

• Collegare i commit e le richieste pull di GitHub Enterprise agli elementi di lavoro di Azure Boards
• Configurare le compilazioni con YAML
• Le annotazioni delle schede includono bug e tipi di elementi di lavoro personalizzati
• Selezione migliorata dei rami
• Modifiche apportate agli artefatti e alle licenze della pipeline di distribuzione di Release Management

---

Data di rilascio RC1: 19 novembre 2018

Riepilogo delle novità di Azure DevOps Server 2019 RC1

Azure DevOps Server 2019 introduce una nuova esperienza di spostamento e molte nuove funzionalità. Tra le caratteristiche principali:

• Nuova esperienza di spostamento
• L'estensione del marketplace di Analisi per la creazione di report è ora disponibile
• Supporto per database SQL di Azure
• Elaborare l'ereditarietà nelle nuove raccolte
• Hub Nuovi elementi di lavoro
• Nuovi hub Boards, Backlog e Sprints
• Nuovo hub query
• Standardizzare le descrizioni delle richieste pull usando i modelli
• Cambiare il ramo di destinazione di una richiesta pull
• Gestire le pipeline di compilazione usando la nuova pagina Compilazioni
• Gestire le pipeline di versione usando la nuova pagina Versioni
• Visualizzare lo stato di avanzamento della versione
• Aggiornare localmente l'agente
• Esporre progressivamente le distribuzioni in fasi e usando i controlli di rilascio
• Origini upstream
• Creare il sommario per le pagine wiki

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

• Generali
• Bacheche
• Repos
• Pipeline
• Piani di test
• Elementi
• Wiki
• Report

---

Generali

Annuncio del server Azure DevOps

Il 10 settembre, Azure DevOps è stato annunciato come evoluzione di Visual Studio Team Services e Team Foundation Server . Azure DevOps Server 2019 è la prima versione locale con questo nuovo marchio. Per altre informazioni, vedere il post di blog.

Nuova esperienza di spostamento

Stiamo introducendo una nuova navigazione per modernizzare l'esperienza utente. Questa nuova navigazione è stata implementata nel servizio Azure DevOps ed è ora disponibile in Azure DevOps Server 2019. Per altre informazioni, vedere il blog .

Modifiche apportate agli artefatti e alle licenze della pipeline di distribuzione di Release Management

In base al feedback degli utenti, vengono apportate due modifiche chiave alle licenze con Azure DevOps Server 2019. In primo luogo, i clienti non dovranno più acquistare l'estensione Artifact per usare Artifacts. L'uso di una licenza artifacts verrà ora incluso nella licenza Basic. Tutti gli utenti a cui è stata assegnata una licenza Basic potranno ora usare artifacts. In secondo luogo, i clienti non dovranno più acquistare le pipeline di distribuzione di Release Management. Analogamente alle pipeline di compilazione, le pipeline di distribuzione di Release Management sono ora incluse in Azure DevOps Server 2019.

Supporto per database SQL di Azure

Per semplificare l'esperienza di esecuzione di Azure DevOps 2019 in Azure, è stato abilitato il supporto per database SQL di Azure (Utilizzo generico S3 e versioni successive). Ciò consentirà di sfruttare funzionalità di backup estese e opzioni di ridimensionamento in base alle esigenze, riducendo al contempo il sovraccarico amministrativo dell'esecuzione del servizio. Si noti che la macchina virtuale host deve trovarsi nella stessa area di Azure del database per mantenere bassa la latenza. Per altre informazioni, vedi la documentazione.

Elementi di lavoro e testare le API SOAP del modello a oggetti client nelle versioni future

Azure DevOps Server 2019 continua a supportare l'API SOAP di rilevamento degli elementi di lavoro e il modello a oggetti client. Tuttavia, verrà contrassegnato come deprecato nelle versioni future di Azure DevOps Server. Per altre informazioni, vedere la documentazione.

Elaborare l'ereditarietà nelle nuove raccolte

L'ereditarietà dei processi è ora disponibile nelle nuove raccolte. Gli utenti dovranno prendere una decisione di coscienza sul modello di processo durante la creazione di una nuova raccolta. Vedere la documentazione sul modello di ereditarietà e su come è diversa da XML.

Casella di ricerca espansa

È importante comprendere l'importanza della ricerca e riportare la casella di ricerca espansa nell'intestazione del prodotto. È anche possibile richiamare la casella di ricerca facendo clic su "/" in qualsiasi pagina del servizio in Azure DevOps.

Ecco la casella di ricerca predefinita:

Dopo aver digitato "/", verrà visualizzata la casella di ricerca espansa:

Riquadro a comparsa lavoro personale

Una nuova funzionalità che siamo molto entusiasti di presentare è il mio riquadro a comparsa di lavoro . Abbiamo sentito feedback che quando sei in una parte del prodotto e desideri alcune informazioni da un'altra parte, non vuoi perdere il tuo contesto. Con questa nuova funzionalità, è possibile accedere a questo riquadro a comparsa da qualsiasi punto del prodotto e offre una rapida panoramica delle informazioni cruciali, inclusi gli elementi di lavoro, le richieste pull e tutti i preferiti. Con questo nuovo riquadro a comparsa, se ci si trova in Repos si trova in basso nel codice, ma si vuole controllare rapidamente quale elemento di lavoro si dovrebbe lavorare successivamente, è sufficiente fare clic sul riquadro a comparsa e visualizzare gli elementi di lavoro assegnati all'utente e selezionare l'elemento successivo.

Di seguito è possibile visualizzare il riquadro a comparsa lavoro che mostra gli elementi di lavoro assegnati all'utente:

Qui è possibile visualizzare il secondo pivot che mostra le richieste pull assegnate all'utente corrente. Nel riquadro a comparsa è anche possibile accedere con un clic per visualizzare più richieste pull:

Qui è possibile visualizzare l'ultimo pivot, ovvero tutto ciò che si è preferito. Sono inclusi i team, i dashboard, le bacheche, i backlog, le query e i repository preferiti:

Boards

Collegare i commit e le richieste pull di GitHub Enterprise agli elementi di lavoro di Azure Boards

Teams che usano GitHub Enterprise per il codice e vogliono funzionalità avanzate di gestione dei progetti possono ora integrare i repository con Azure Boards. Connettendo GitHub e Azure Boards, è possibile ottenere tutte le funzionalità, ad esempio backlog, bacheche, strumenti di pianificazione dello sprint, più tipi di elemento di lavoro e ancora un flusso di lavoro che si integra con i flussi di lavoro degli sviluppatori in GitHub.

Il collegamento di commit e richieste pull agli elementi di lavoro è semplice. Menzionare l'elemento di lavoro usando la sintassi seguente:

AB#{work item ID}

Menzionare un elemento di lavoro in un messaggio di commit, un titolo della richiesta pull o una descrizione della richiesta pull e Azure Boards creerà un collegamento a tale artefatto. Si consideri ad esempio un messaggio di commit simile al seguente:

Adds support for deleting connections. Fixes AB#20.

Verrà creato un collegamento dall'elemento di lavoro #20 al commit in GitHub, che verrà visualizzato nella sezione Sviluppo dell'elemento di lavoro. ​

Se le parole "fix", "fixes" o "fixed" precedono la menzione dell'elemento di lavoro (come illustrato in precedenza), l'elemento di lavoro verrà spostato nello stato completato quando il commit viene unito al ramo predefinito.

I team che usano Azure Pipelines per compilare il codice in GitHub vedranno anche gli elementi di lavoro collegati ai commit di GitHub nel riepilogo della compilazione.

Hub Nuovi elementi di lavoro

L'hub degli elementi di lavoro è il nuovo hub che fungerà da home page degli elementi di lavoro. In questo caso, sono disponibili molte visualizzazioni elenco diverse degli elementi di lavoro con ambito in basso. È possibile visualizzare Assegnato a me per ottenere rapidamente un'occhiata a tutto il lavoro assegnato all'utente o Aggiornato di recente , che mostra tutti gli elementi di lavoro nel progetto che sono stati aggiornati più di recente. Tutte le opzioni dell'elenco possono essere visualizzate di seguito:

Se si vuole definire ulteriormente l'ambito degli elenchi, è possibile filtrare in base al tipo, assegnato a, stato, area, tag e parola chiave. Dopo aver ottenuto la visualizzazione elenco desiderata, è possibile ordinare gli elementi di lavoro semplicemente facendo clic sull'intestazione della colonna. Se una colonna è troppo stretta per visualizzare il contenuto completo della colonna, è possibile ridimensionare facilmente la colonna nell'area dell'intestazione. Queste esperienze possono essere visualizzate di seguito:

Nuovi hub Boards, Backlog e Sprints

L'hub Backlogs è stato suddiviso in tre hub distinti per migliorare l'esperienza utente. Anche se potente, l'hub Backlogs precedente ospitava troppe funzionalità. Questo spesso rendeva difficile trovare la funzionalità o le funzionalità che gli utenti cercavano. Per risolvere questo problema, l'hub Backlogs è stato suddiviso in:

• L'hub Backlogs ora ospita solo i backlog per un progetto. Un backlog è un elenco di lavoro con priorità per il team. I backlog offrono strumenti di pianificazione come gerarchia degli elementi di lavoro, previsione e nuova esperienza di pianificazione dello sprint.
• Il nuovo hub Boards ospita tutte le bacheche Kanban per un progetto. Le schede vengono usate per comunicare lo stato e il flusso. Le schede (elementi di lavoro) si spostano da sinistra a destra attraverso le colonne definite dal team.
• Il nuovo hub Sprints ospita le funzionalità usate per pianificare ed eseguire un incremento del lavoro. Ogni sprint contiene un backlog sprint, un taskboard e una visualizzazione per gestire e impostare la capacità per il team.

Nuovo hub query

Il nuovo hub di query semplifica molte delle funzionalità di query esistenti dall'hub precedente con un aspetto più moderno e offre nuove funzionalità per semplificare l'accesso alle query importanti. Ecco alcuni punti salienti della nuova esperienza:

• Pagine di directory con l'ultima modifica delle informazioni e la possibilità di cercare query
• Percorso di navigazione con URL univoci per le cartelle ai segnalibri di gruppi importanti di query
• Accesso rapido alle query preferite dalla pagina dei risultati

Altre informazioni su questi interessanti aggiornamenti sono disponibili nel blog di DevOps.

Spostare gli elementi di lavoro in un altro progetto e modificare un tipo di elemento di lavoro

È ora possibile modificare il tipo di elemento di lavoro o spostare gli elementi di lavoro in un altro progetto all'interno di una raccolta di progetti. Queste funzionalità richiedono che il data warehouse sia disabilitato. Con il data warehouse disabilitato, è possibile usare il servizio Analisi per supportare le esigenze di creazione di report. Per altre informazioni sulla disabilitazione del data warehouse, vedere Disabilitare il data warehouse e il cubo.

Funzionalità di pianificazione sprint

Le nuove funzionalità di pianificazione dello sprint consentono di accelerare e migliorare l'esperienza di pianificazione dello sprint.

• Creare lo sprint successivo o sottoscrivere una pianificazione dello sprint esistente direttamente dall'hub Sprint.
• Usare il nuovo riquadro Pianificazione nel backlog per trascinare gli elementi di lavoro negli sprint futuri. Il riquadro Pianificazione include date sprint, conteggi degli elementi di lavoro e lavoro pianificato.
• Aggiungere i requisiti all'inizio della Schermata attività o usare la creazione rapida per aggiungere alla riga superiore, inferiore o di scelta nel backlog dello sprint.
• Usare i filtri per assegnatario, tipo di elemento di lavoro, stato e tag per adattare le visualizzazioni alle proprie esigenze.

Nuove pagine della directory

Tutti i nuovi hub, inclusi Backlog, Boards e Sprint, hanno ora nuove pagine di directory organizzate con le sezioni seguenti:

• Continua dove hai lasciato Questa nuova sezione fornisce un collegamento rapido direttamente all'ultimo (scheda | Backlog | Sprint) sei stato acceso.
• Preferiti Tutti i tuoi tabelloni preferiti, sprint e backlog in tutti i team.
• My All of the boards, backlogs, and sprints for teams you belong to.
• Tutto Un elenco completo di tutte le schede, i backlog e gli sprint.

Menu Nuove opzioni visualizzazione

I nuovi hub, inclusi backlog, bacheche e sprint, hanno un nuovo menu Opzioni di visualizzazione. Questa è una nuova home page per tutte le azioni per personalizzare il layout e il contenuto della pagina. Usare Opzioni di visualizzazione per abilitare visualizzazioni aggiuntive, ad esempio la visualizzazione della gerarchia nei backlog o la modifica dell'opzione Raggruppa per in una lavagna delle attività, per attivare il pannello laterale per i mapping e pianificare gli sprint o per esplorare i grafici dei dettagli di lavoro.

Per altre informazioni su questi interessanti aggiornamenti, sul nuovo riquadro Profilo team e sui Preferiti, vedere il blog di DevOps.

Le annotazioni delle schede includono bug e tipi di elementi di lavoro personalizzati

Le annotazioni delle schede sono apprezzate per la visualizzazione e l'interazione intuitiva dell'elenco di controllo. In precedenza, le annotazioni delle schede erano limitate ai tipi di livello backlog predefiniti e non supportavano bug o tipi personalizzati. Con la nuova versione, abbiamo rimosso la restrizione sui tipi di elemento di lavoro e abbiamo aggiunto la possibilità di visualizzare Bug e qualsiasi tipo di elemento di lavoro personalizzato come annotazione scheda.

Le impostazioni della scheda per le annotazioni scheda sono state espanse per includere tutti i tipi di elemento di lavoro disponibili per tale livello di backlog.

Quando le annotazioni per l'elemento di lavoro sono abilitate, il conteggio per tale tipo di elemento di lavoro viene incluso nella scheda come elenco di controllo separato.

La creazione rapida dei tipi di elementi di lavoro abilitati è disponibile anche tramite il menu di scelta rapida della scheda.

Spostare il lavoro usando aree e iterazioni suggerite

Può essere comune lavorare nella stessa area o nella stessa iterazione e esplorare ripetutamente le gerarchie quando si spostano elementi di lavoro. I controlli Percorso area e iterazione includono ora un elenco di valori usati di recente come suggerimenti, consentendo di accedere rapidamente all'impostazione e all'spostamento.

Inoltre, le date di iterazione sono incluse a destra del nome in modo da poter giudicare rapidamente quando deve essere recapitato un elemento di lavoro.

Il lavoro delle query nella pianificazione dell'iterazione con +/- @CurrentIteration

La @CurrentIteration macro che consente al team di tenere traccia del lavoro in base alla pianificazione dell'iterazione supporta ora l'offset integer. Tenere facilmente le schede sul lavoro che non è stato chiuso con @CurrentIteration - 1 o guardare avanti il lavoro pianificato per le iterazioni future con @CurrentIteration + 1. Per altre informazioni, vedere il post @CurrentIteration nel blog di Microsoft DevOps.

Chiarire le pianificazioni di iterazione delle query con il @CurrentIteration parametro Team

Se in passato è stata usata la @CurrentIteration macro nelle query, si potrebbe notare che i risultati possono variare se il contesto del team cambia in Teams con pianificazioni di iterazione diverse. Ora, quando si crea o si modifica una query con la @CurrentIteration macro, sarà necessario selezionare anche il team con la pianificazione dell'iterazione pertinente per la query. Con il parametro Team è possibile usare la @CurrentIteration macro nella stessa query, ma tra i team. Un esempio può essere una query per gli elementi di lavoro in due progetti team diversi usando nomi di iterazione diversi e persino pianificazioni. Ciò significa che non è più necessario aggiornare le query man mano che cambiano gli sprint. Per altre informazioni, vedere il post @CurrentIteration nel blog di Microsoft DevOps.

Le query funzionano nei percorsi di area di un team con la nuova @TeamAreas macro

Nelle impostazioni di un team è possibile associare uno o più percorsi di area, che consentono di concentrare l'attenzione su backlog, bacheche, piani, persino dashboard per il lavoro per tale team. Se tuttavia si vuole scrivere una query per un team, è necessario elencare i percorsi di area specifici per tale team nelle clausole di query. È ora disponibile una nuova macro @TeamAreas per fare facilmente riferimento ai percorsi di area di proprietà del team specificato.

Query per campi RTF vuoti

Trovare elementi di lavoro con un campo RTF vuoto, ad esempio Description, usando il nuovo operatore di query IsEmpty .

Trovare facilmente elementi di lavoro esistenti in esperienze di collegamento e menzione

Quando si desidera collegare due elementi di lavoro esistenti, è ora possibile trovare facilmente l'elemento importante per l'uso del nuovo controllo di ricerca degli elementi di lavoro. Il selettore di query è stato sostituito con suggerimenti inline in base agli elementi di lavoro a cui si accede di recente, nonché a un punto di ingresso per cercare un elemento di lavoro specifico in base all'ID o al titolo.

Apri elementi di lavoro dalla ricerca

In precedenza, non è stato possibile aprire un elemento di lavoro dalla pagina dei risultati della ricerca se il riquadro di anteprima dell'elemento di lavoro è stato disattivato. Ciò renderebbe difficile esaminare i risultati della ricerca. È ora possibile fare clic sul titolo dell'elemento di lavoro per aprire gli elementi di lavoro in una finestra modale.

Repos

Selezione migliorata dei rami

La maggior parte delle esperienze in Azure Repos richiede di selezionare un repository e quindi un ramo in tale repository. Per migliorare questa esperienza per le organizzazioni con un numero elevato di rami, viene implementata una nuova selezione rami. La selezione consente ora di selezionare i rami preferiti o di cercare rapidamente un ramo.

Ricevere notifiche quando i criteri delle richieste pull vengono ignorati

Per i team che usano richieste pull e criteri di ramo, possono verificarsi occasioni in cui gli utenti devono eseguire l'override e ignorare tali criteri, ad esempio quando si distribuisce un hotfix in un problema di produzione durante la notte. Ha senso fidarsi degli sviluppatori di fare la cosa giusta e di usare la funzionalità di override con moderazione. Allo stesso tempo, i team hanno bisogno di un modo per verificare che tali sostituzioni dei criteri vengano usate nelle situazioni corrette. Per supportare questo problema, è stato aggiunto un nuovo filtro di notifica per consentire a utenti e team di ricevere avvisi di posta elettronica ogni volta che un criterio viene ignorato. Iniziare con il modello Viene creata o aggiornata una richiesta pull e selezionare Ignora criteri dall'elenco dei filtri. Selezionare Criteri ignorati come valore e si riceverà una notifica ogni volta che viene completata una richiesta pull e i criteri vengono ignorati.

Consentire il bypass dei criteri di ramo senza rinunciare alla protezione push

Esistono molti scenari in cui si ha la necessità occasionale di ignorare un criterio di ramo: ripristino di una modifica che ha causato un'interruzione di compilazione, applicazione di un hotfix durante la notte e così via. In precedenza, è stata offerta un'autorizzazione ("esentata dall'imposizione dei criteri") per aiutare i team a gestire gli utenti a cui è stata concessa la possibilità di ignorare i criteri dei rami durante il completamento di una richiesta pull. Tuttavia, tale autorizzazione ha anche concesso la possibilità di eseguire il push direttamente nel ramo, ignorando completamente il processo di richiesta pull.

Per migliorare questa esperienza, è stata divisa l'autorizzazione precedente per offrire maggiore controllo ai team che concedono autorizzazioni di bypass. Esistono due nuove autorizzazioni per sostituire quella precedente:

1. Criteri da ignorare quando si completano richieste pull. Gli utenti con questa autorizzazione potranno usare l'esperienza "Override" per le richieste pull.
2. Criteri da ignorare durante il push. Gli utenti con questa autorizzazione potranno eseguire il push direttamente nei rami con criteri necessari configurati.

Concedendo la prima autorizzazione e negando la seconda, un utente sarà in grado di usare l'opzione di bypass quando necessario, ma avrà comunque la protezione dal push accidentale in un ramo con criteri.

Nota

Questa modifica non introduce modifiche al comportamento. Agli utenti a cui è stata concessa in precedenza l'opzione Consenti l'esenzione dall'imposizione dei criteri verrà concessa Consenti per entrambe le nuove autorizzazioni, in modo da poter eseguire l'override del completamento nelle richieste pull e di eseguire il push direttamente nei rami con i criteri.

Per altre informazioni, vedere la documentazione Impostare le autorizzazioni per i rami.

Descrivere rapidamente le richieste pull usando messaggi di commit

La scrittura di messaggi di commit descrittivi aggiunge valore alla cronologia di qualsiasi repository Git. Per incoraggiare i messaggi di commit qualitativo, le nuove richieste pull (PR) con più commit richiederanno ai collaboratori di immettere manualmente un titolo.

Le descrizioni delle richieste pull continueranno a essere vuote per impostazione predefinita, ma una nuova funzionalità renderà più semplice incorporare i messaggi di commit dai commit della richiesta pull nella descrizione della richiesta pull. Per aggiungere i messaggi di commit, è sufficiente fare clic su Aggiungi messaggi di commit per aggiungere i messaggi di commit alla fine del testo della descrizione della richiesta pull.

Creare richieste pull senza un team predefinito come revisore

Quando è stata avviata per la prima volta l'esperienza pull request (PR), si è pensato che sia opportuno assegnare tutte le richieste pull al contesto del team selezionato durante la creazione della richiesta pull. Questo comportamento è stato un punto di frustrazione, poiché molte persone non hanno notato la connessione tra il contesto del team e l'assegnazione della richiesta pull.

Come parte delle nuove modifiche di spostamento, abbiamo avuto l'opportunità di modificare questa associazione predefinita con i team. Si noteranno due modifiche:

1. Quando si crea una richiesta pull, per impostazione predefinita non vengono aggiunti revisori. L'elenco dei revisori dispone di una funzionalità per semplificare l'aggiunta di singoli utenti e gruppi aggiunti di recente alle richieste pull. I criteri dei revisori necessari possono anche aiutare i team che vogliono assicurarsi che vengano aggiunti revisori specifici per esaminare il codice.
2. L'hub richieste pull include una nuova sezione personalizzabile. Per impostazione predefinita, questa sezione mostra le richieste pull "Assegnate ai miei team", fornendo funzionalità equivalenti come la sezione precedente. Tuttavia, se si appartiene a più team, questa sezione mostrerà le richieste pull assegnate a uno dei team. La sezione è anche personalizzabile. È sufficiente fare clic sull'azione "Personalizza questa visualizzazione" accanto all'intestazione di sezione.

Standardizzare le descrizioni delle richieste pull usando i modelli

La scrittura di descrizioni di richieste pull valide è un ottimo modo per aiutare i revisori a sapere cosa aspettarsi durante la revisione del codice. Sono anche un ottimo modo per tenere traccia delle operazioni che devono essere eseguite per ogni modifica, ad esempio i test, l'aggiunta di unit test e l'aggiornamento della documentazione. Molti di voi hanno richiesto di aggiungere modelli di richiesta pull per semplificare la scrittura di descrizioni dettagliate da parte dei team ed è stata aggiunta questa funzionalità.

Oltre a supportare un modello di descrizione richiesta pull predefinito, i team possono aggiungere più modelli, che vengono presentati all'utente in un menu nella pagina crea richiesta pull. È sufficiente fare clic sul pulsante Aggiungi un modello per scegliere da qualsiasi modello nel repository per aggiungerlo alla descrizione della richiesta pull.

I modelli specifici del ramo sono supportati anche se si vuole applicare un modello diverso per una richiesta pull in un ramo specifico o in una cartella di ramo. Ad esempio, se si vuole avere un modello specifico per tutti i rami che iniziano con "hotfix/" è possibile aggiungere un modello che verrà usato per tutte le richieste pull in tali rami.

Per altre informazioni su come creare e usare modelli, vedere la documentazione relativa ai modelli di richiesta pull.

Cambiare il ramo di destinazione di una richiesta pull

Per la maggior parte dei team, quasi tutte le richieste pull hanno come destinazione lo stesso ramo, ad esempio main o develop. Tuttavia, nel caso in cui sia necessario impostare come destinazione un ramo diverso, è facile dimenticare di modificare il ramo di destinazione dal valore predefinito. Con la nuova funzionalità per modificare il ramo di destinazione di una richiesta pull attiva, questa è ora una semplice azione. È sufficiente fare clic sull'icona a forma di matita accanto al nome del ramo di destinazione nell'intestazione della richiesta pull.

Oltre a correggere solo gli errori, la funzionalità per modificare i rami di destinazione semplifica anche la ridefinizione di una richiesta pull quando il ramo di destinazione è stato unito o eliminato. Si consideri uno scenario in cui si dispone di una richiesta pull destinata a un ramo di funzionalità che contiene alcune funzionalità da cui dipendono le modifiche. Si vogliono esaminare le modifiche dipendenti in isolamento da altre modifiche nel ramo delle funzionalità, quindi inizialmente si ha come destinazione features/new-feature. I revisori possono quindi visualizzare solo le modifiche e lasciare i commenti appropriati.

A questo punto, considerare cosa accadrebbe se il ramo delle funzionalità disponesse anche di una richiesta pull attiva ed è stato unito prima main delle modifiche? In precedenza, è necessario abbandonare le modifiche e creare una nuova richiesta pull in maino unire la richiesta pull in features/new-featuree quindi creare un'altra richiesta pull da features/new-feature a main. Con questa nuova azione per aggiornare il ramo di destinazione, è sufficiente modificare il ramo di destinazione della richiesta pull da features/new-feature a main, mantenendo tutto il contesto e i commenti. La modifica del ramo di destinazione crea anche un nuovo aggiornamento alla richiesta pull, che consente di esaminare facilmente le differenze precedenti prima della modifica del ramo di destinazione.

Gli autori di estensioni possono eseguire query sul contesto relative al repository corrente

Uno dei problemi per un autore di un'estensione del controllo della versione consiste nell'ottenere il contesto del repository visualizzato all'utente, ad esempio il nome, l'ID e l'URL. A tale scopo, è stato aggiunto VersionControlRepositoryService come servizio accessibile dall'estensione. In questo modo, un autore di estensioni può eseguire una query per ottenere informazioni sul contesto del repository Git corrente all'interno dell'interfaccia utente Web. Attualmente ha un metodo, getCurrentGitRepository().

• Se è selezionato un repository Git, viene restituito un oggetto GitRepository con dati di base sul repository (nome, ID e URL)
• Se è selezionato un repository TFVC o si accede al servizio all'esterno delle pagine Di Azure Repos, verrà restituito null.

Ecco un'estensione di esempio che usa questo servizio.

Pipeline

Gestire le pipeline di compilazione usando la nuova pagina Compilazioni

Stiamo apportando diversi miglioramenti e implementando una nuova versione della pagina Compilazioni . Questa nuova versione combina la directory di tutte le pipeline di compilazione e l'elenco delle compilazioni correnti, in modo che sia possibile spostarsi rapidamente tra le compilazioni del progetto per visualizzare il relativo stato. Include anche un'anteprima dell'analisi dei test per la pipeline selezionata.

Gestire meglio i messaggi di posta elettronica di completamento della compilazione e della distribuzione usando una formattazione migliorata

I messaggi di posta elettronica di completamento della compilazione e della distribuzione sono stati aggiornati per essere più filtrabili in base alle regole di posta elettronica. Ora la riga dell'oggetto include informazioni più rilevanti a colpo d'occhio, il corpo contiene altri dettagli e il loro stile è stato aggiornato con il marchio più recente.

Gli elementi del nuovo formato sono:

• [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
• [Deployment result] [pipeline name] > [release name] : [stage name]

Ecco alcuni esempi:

• [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
• [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

Seguire la nuova terminologia unificata di Azure Pipelines

In tutte le build e versioni sono stati usati termini diversi storicamente per concetti simili. In altri casi, i significati dei termini erano vaghi. Ad esempio, indicando la differenza tra un pool di agenti e una coda di agenti.

La terminologia è stata unificata in Azure Pipelines per chiarire i concetti. Verranno ora visualizzati i termini unificati seguenti:

Termine precedente	Termine unificato	significato
Agente ospitato	Pool ospitato da Microsoft	Agente di compilazione/versione eseguito nell'infrastruttura ospitata nel cloud gestito da Microsoft.
Agente privato	Agente self-hosted	Agente di compilazione/versione eseguito in un computer fornito e gestito dall'utente.
Pool di agenti	Pool di agenti	Un set di computer agente a livello di organizzazione che possono eseguire compilazioni o versioni.
Coda agente	Pool di agenti	Set di computer agente a livello di progetto che possono eseguire compilazioni o versioni. È collegato a un pool di agenti a livello di organizzazione.
Definizione di compilazione	Pipeline di compilazione	Set end-to-end di passaggi di compilazione per un'applicazione.
Build	Build	Istanza di una pipeline di compilazione in esecuzione o in esecuzione.
Fase	Mansione	Serie di attività eseguite in sequenza o in parallelo su un agente. Una pipeline di compilazione o versione può contenere un processo o un grafico di più processi.
Definizione di versione	Pipeline di versione	Set end-to-end di passaggi di rilascio per la distribuzione di un'applicazione in varie fasi.
Rilascio	Rilascio	Istanza di una pipeline di versione in esecuzione o in esecuzione.
Ambiente	Fase	Entità logica e indipendente che rappresenta la posizione in cui si vuole distribuire una versione generata da una pipeline di versione.
Processo/pipeline simultanei	Processo parallelo	Un processo parallelo consente di eseguire un singolo processo di compilazione o rilascio alla volta nell'organizzazione. Con più processi paralleli disponibili, è possibile eseguire più processi di compilazione e rilascio contemporaneamente.
Endpoint di servizio	Connessione al servizio	Un gruppo di impostazioni, ad esempio le credenziali, usato per connettersi a servizi esterni per eseguire attività in una compilazione o versione.

Per altre informazioni, vedere la documentazione sui concetti .

Gestire le pipeline di versione usando la nuova pagina Versioni

Per la pagina di destinazione della versione è disponibile un'esperienza utente nuova e completamente riprogettata. Vedere un elenco delle pipeline di versione rilasciate spesso a sinistra. È anche possibile eseguire ricerche nelle pipeline e selezionarle come preferite.

Passare alla visualizzazione cartelle per creare cartelle per l'organizzazione e la sicurezza. La sicurezza può essere impostata a livello di cartella.

Visualizzare lo stato di avanzamento della versione

La nuova visualizzazione dello stato di avanzamento della versione offre aggiornamenti in tempo reale dello stato di avanzamento della distribuzione e l'accesso con un clic per altri dettagli. La nuova visualizzazione visualizza la pipeline di versione, semplificando la comprensione di ciò che accade e presenta i dettagli e le azioni appropriate in diverse fasi della versione.

Pipeline, dettagli sulla versione e ambienti

La visualizzazione Pipeline mostra gli artefatti della versione e gli ambienti in cui verranno distribuiti. L'area Rilascio fornisce dettagli sulla versione, ad esempio il trigger di rilascio, le versioni degli artefatti e i tag.

Gli ambienti vengono modellati in modo da facilitare la comprensione dello stato, insieme all'avanzamento dettagliato. In qualsiasi momento, è possibile accedere ai log facendo clic sul collegamento di stato all'interno dell'ambiente.

Pre-distribuzione e post-distribuzione

Se sono state impostate condizioni di pre-distribuzione o post-distribuzione per un ambiente, viene indicato nell'ambiente con la presenza di approvazioni e controlli. Lo stato delle approvazioni e dei controlli viene visualizzato anche nello stato dell'ambiente. È possibile intervenire o visualizzare altri dettagli facendo clic sull'icona della condizione dell'ambiente appesa al lato destro o sinistro dell'ambiente.

Commit ed elementi di lavoro

Con ogni nuova versione, è possibile visualizzare l'elenco di commit e elementi di lavoro associati per ogni ambiente separatamente facendo clic sull'ambiente. Se l'elenco è lungo, usare i filtri per trovare un commit o un elemento di lavoro a cui si è interessati.

Avanzamento e log della distribuzione

Gli ambienti mostrano gli aggiornamenti in tempo reale per le distribuzioni in corso, tra cui il numero di fasi e attività completate e il tempo di esecuzione. Facendo clic sullo stato dell'ambiente si apre una visualizzazione contenente i log, con lo stato attivo.

È possibile fare clic nei log per immettere una visualizzazione con stato attivo.

Impatto dell'aggiornamento ad Azure DevOps Server 2019 sulle attività: Copia file del computer Windows e PoweShell nel computer di destinazione

I gruppi di computer in Hub di test sono stati deprecati in TFS 2017 RTM. Con Azure DevOps Server 2019, il servizio Gruppi di computer non è più disponibile. Ciò influirà sugli utenti dell'attività "Copia file del computer Windows" versione 1.* e "PowerShell nei computer di destinazione" versione 1.*. Affinché le pipeline continuino a funzionare,

• È necessario passare all'attività "Copia file del computer Windows" versione 2.* e specificare il nome di dominio completo per il computer di destinazione anziché solo il nome del computer.
• Passare all'attività "PowerShell on Target Machine" versione 2.* o successiva e specificare l'fqdn completo del computer o del nome del computer seguito dalle porte di gestione remota windows (http/https). Ad esempio, targetMachine:5985 o targetMachine:5986

Risultati ed estendibilità dei test

Anche i risultati dell'esecuzione dei test vengono visualizzati per ogni ambiente. Facendo clic sui risultati del test si apre una visualizzazione contenente i dettagli del test, inclusi i risultati di altre estensioni che contribuiscono al processo.

Le estensioni esistenti funzionano in questa nuova visualizzazione, oltre a nuovi punti di estendibilità per consentire lo sviluppo di estensioni per visualizzare ancora più informazioni per un ambiente. Per altre informazioni, vedere la documentazione relativa ai contributi e alle estensioni .

Configurare le compilazioni con YAML

Le pipeline di compilazione basate su YAML sono disponibili in Azure DevOps Server. Automatizzare la pipeline di integrazione continua usando un file YAML archiviato nel repository. Un riferimento completo per lo schema YAML è disponibile qui.

Per supportare più facilmente le pipeline di compilazione basate su YAML, è stato modificato il comportamento predefinito per tutte le nuove risorse create, ad esempio connessioni al servizio, gruppi di variabili, pool di agenti e file sicuri, in modo che siano utilizzabili in tutte le pipeline di tale progetto. Se si vuole un controllo più rigoroso sulle risorse, è possibile disabilitare il modello di autorizzazione predefinito (vedere la figura seguente). In questo caso, un utente con autorizzazioni per l'uso della risorsa deve salvare in modo esplicito la pipeline nell'editor Web dopo l'aggiunta di un riferimento a una risorsa al file YAML.

Concatenare le compilazioni correlate usando i trigger di completamento della compilazione

I prodotti di grandi dimensioni hanno diversi componenti che dipendono l'uno dall'altro. Questi componenti vengono spesso compilati in modo indipendente. Quando un componente upstream (ad esempio una libreria) cambia, le dipendenze downstream devono essere ricompilate e riconvalidate. In genere, Teams gestisce queste dipendenze manualmente.

È ora possibile attivare una compilazione al completamento di un'altra compilazione. Gli artefatti prodotti da una compilazione upstream possono essere scaricati e usati nella compilazione successiva ed è anche possibile ottenere dati da queste variabili: Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName. Per altre informazioni, vedere la documentazione sui trigger di compilazione.

Tenere presente che in alcuni casi, una singola compilazione a più fasi potrebbe soddisfare le proprie esigenze. Tuttavia, un trigger di completamento della compilazione è utile se i requisiti includono impostazioni di configurazione diverse, opzioni o un team diverso per possedere il processo dipendente.

Aggiornare localmente l'agente

Le attività installate dalla raccolta in alcuni casi richiedono una versione più recente dell'agente di pipeline. Se azure DevOps Server può connettersi a Internet, le versioni più recenti vengono scaricate automaticamente. In caso contrario, è necessario aggiornare manualmente ogni agente. A partire da questa versione, è possibile configurare Azure DevOps Server per cercare i file del pacchetto dell'agente nel disco locale anziché da Internet. Ciò offre flessibilità e controllo sulle versioni dell'agente disponibili, senza dover esporre Azure DevOps Server a Internet.

URL nuova notifica dello stato della compilazione

Le notifiche di compilazione incorporate nella home page di un repository sono un modo comune per mostrare l'integrità del repository. Anche se fino ad ora erano presenti badge di compilazione, ci sono stati alcuni problemi:

• L'URL non è stato intuitivo
• Il badge non era specifico di un ramo
• Non c'era modo per un utente di fare clic sul badge per portare l'utente alla build più recente di tale definizione

È ora in fase di implementazione una nuova API per i badge di compilazione che risolvono questi problemi. La nuova API consente agli utenti di pubblicare uno stato per ramo e può portare gli utenti alla build più recente del ramo selezionato. È possibile ottenere il markdown per il nuovo URL badge di stato selezionando l'azione di menu Notifica stato nella nuova pagina Compilazioni.

Per garantire la compatibilità con le versioni precedenti, continueremo a rispettare anche gli URL delle notifiche di compilazione precedenti.

Aggiungi contatori di compilazione personalizzati alle tue build

I contatori di compilazione consentono di numerare ed etichettare in modo univoco le compilazioni. In precedenza, è possibile usare la variabile speciale $(rev:r) per eseguire questa operazione. Ora è possibile definire le variabili del contatore personalizzate nella definizione di compilazione che vengono incrementate automaticamente ogni volta che si esegue una compilazione. Questa operazione viene eseguita nella scheda variabili di una definizione. Questa nuova funzionalità offre maggiore potenza nei modi seguenti:

• È possibile definire un contatore personalizzato e impostarne il valore di inizializzazione. Ad esempio, è possibile avviare il contatore a 100. $(rev:r) inizia sempre a 0.
• È possibile usare la logica personalizzata per reimpostare un contatore. $(rev:r) è associato alla generazione del numero di build e viene reimpostato automaticamente ogni volta che è presente un nuovo prefisso nel numero di build.
• È possibile definire più contatori per definizione.
• È possibile eseguire una query per il valore di un contatore all'esterno di una compilazione. Ad esempio, è possibile contare il numero di compilazioni eseguite dall'ultima reimpostazione usando un contatore.

Per altre informazioni sui contatori di compilazione, vedere la documentazione sulle variabili definite dall'utente.

Convalide della conformità e della sicurezza di Criteri di Azure in Azure Pipelines

Vogliamo garantire stabilità e sicurezza del software all'inizio del processo di sviluppo, mettendo insieme lo sviluppo, la sicurezza e le operazioni. A tale scopo, è stato aggiunto il supporto per Criteri di Azure.

Criteri di Azure consente di gestire ed evitare problemi IT con definizioni dei criteri che applicano regole e azioni per le risorse. Quando si usa Criteri di Azure, le risorse rimangono conformi agli standard aziendali e ai contratti di servizio.

Per rispettare le linee guida per la conformità e la sicurezza nell'ambito del processo di rilascio, è stata migliorata l'esperienza di distribuzione del gruppo di risorse di Azure. In questo caso, l'attività di distribuzione del gruppo di risorse di Azure ha esito negativo con errori correlati ai criteri pertinenti in caso di violazioni durante la distribuzione dei modelli di Resource Manager.

È stato inoltre aggiunto Criteri di Azure modello di definizione della versione. In questo modo gli utenti potranno creare criteri di Azure e assegnare questi criteri a risorse, sottoscrizioni o gruppi di gestione dalla definizione di versione stessa.

Compila nelle piattaforme Linux/ARM e Windows a 32 bit

L'agente open source azure Pipelines multipiattaforma è sempre stato supportato in Windows, macOS e Linux a 64 bit (x64). Con questa versione vengono introdotti due nuove piattaforme supportate: Linux/ARM e Windows/32 bit. Queste nuove piattaforme offrono la possibilità di eseguire la compilazione su piattaforme meno comuni, ma non meno importanti, come Raspberry Pi, un computer Linux/ARM.

Esperienze migliorate per i test nelle pipeline

La scheda Test offre ora un'esperienza moderna che offre informazioni dettagliate sul test nel contesto per pipeline. La nuova esperienza offre una visualizzazione test in corso, un'esperienza di debug a pagina completa, nella cronologia dei test del contesto, nella segnalazione dell'esecuzione di test interrotti e nel riepilogo del livello di esecuzione.

Visualizzare l'esecuzione di test in corso

I test, ad esempio i test di integrazione e funzionale, possono essere eseguiti per molto tempo, quindi è importante visualizzare l'esecuzione dei test in qualsiasi momento. Con la visualizzazione Test in corso non è più necessario attendere il completamento dell'esecuzione del test per conoscere il risultato del test. I risultati sono disponibili quasi in tempo reale man mano che vengono eseguiti, consentendo di eseguire azioni più velocemente. È possibile eseguire il debug di un errore o un'interruzione, inviare un bug o interrompere la pipeline. La funzionalità è attualmente disponibile sia per la pipeline di compilazione che per la pipeline di versione usando l'attività Test di Visual Studio in più agenti, usando l'attività Pubblica risultati test o pubblicando i risultati dei test usando le API. In futuro si prevede di estendere questa esperienza per l'esecuzione di test usando Single Agent.

La visualizzazione seguente mostra il riepilogo dei test in corso nella nuova visualizzazione dello stato di avanzamento della versione, segnalando il numero totale di test e il numero di errori di test in un determinato momento.

Facendo clic sul riepilogo test in corso precedente, è possibile visualizzare il riepilogo dettagliato del test insieme alle informazioni di test non riuscite o interrotte in Piani di test. Il riepilogo del test viene aggiornato a intervalli periodici con la possibilità di aggiornare la visualizzazione dei dettagli su richiesta, in base alla disponibilità di nuovi risultati.

Visualizzare i dettagli del debug dell'esecuzione dei test nella pagina completa

I messaggi di errore e le tracce dello stack sono lunghi e hanno bisogno di spazio sufficiente per visualizzare i dettagli durante il debug. Per avere un'esperienza di debug immersiva, è ora possibile espandere la visualizzazione di esecuzione test o test alla visualizzazione pagina completa, pur essendo ancora in grado di eseguire le operazioni necessarie in operazioni di contesto come la creazione di bug o l'associazione dei requisiti per il risultato del test corrente.

Visualizzare la cronologia dei test nel contesto

Storicamente, i team dovranno passare all'hub Esecuzioni per visualizzare la cronologia di un risultato di test. Con la nuova esperienza, la cronologia dei test viene inserita direttamente nel contesto all'interno della scheda Piani di test per la compilazione e il rilascio. Le informazioni sulla cronologia dei test vengono fornite in modo progressivo a partire dalla definizione o dall'ambiente di compilazione corrente per il test selezionato, seguiti rispettivamente da altri rami e ambienti per la compilazione e il rilascio.

Visualizzare i test interrotti

L'esecuzione dei test può interrompere a causa di diversi motivi, ad esempio codice di test non valido, origine sottoposta a test e problemi ambientali. Indipendentemente dal motivo dell'interruzione, è importante diagnosticare il comportamento e identificare la causa radice. È ora possibile visualizzare i test interrotti e le esecuzioni di test, insieme alle esecuzioni completate in Piani di test. La funzionalità è attualmente disponibile sia per la pipeline di compilazione che per la pipeline di versione usando l'attività di test di Visual Studio in più fasi o la pubblicazione dei risultati dei test usando le API. In futuro si prevede di estendere questa esperienza per l'esecuzione di test usando Single Agent.

Supporto della tracciabilità dei test e degli ambienti di rilascio nella cronologia dei test

È in corso l'aggiunta del supporto per la visualizzazione della cronologia di un test automatizzato raggruppato in diversi ambienti di rilascio in cui viene eseguito il test. Se si modellano gli ambienti di rilascio come pipeline di rilascio o ambienti di test e si eseguono test in tali ambienti, è possibile verificare se un test passa nell'ambiente di sviluppo, ma non riesce nell'ambiente di integrazione. È possibile scoprire se passa le impostazioni locali in inglese, ma si verifica un errore in un ambiente con impostazioni locali turche. Per ogni ambiente, si troverà lo stato del risultato del test più recente e, se il test non è riuscito in tale ambiente, si troverà anche la versione da cui il test non è riuscito.

Esaminare i risultati dei test riepilogati

Durante l'esecuzione del test, un test può generare più istanze di test che contribuiscono al risultato complessivo. Alcuni esempi includono: test eseguiti di nuovo a causa di errori, test composti da una combinazione ordinata di altri test (ad esempio test ordinati) o test con istanze diverse in base al parametro di input fornito (test basati sui dati). Poiché questi test sono correlati, devono essere segnalati insieme al risultato complessivo derivato in base ai singoli risultati del test. Con questo aggiornamento, viene introdotta una versione migliorata dei risultati dei test presentata come gerarchia nella scheda Test di una versione. Di seguito è descritto un esempio.

In precedenza è stata introdotta la possibilità di rieseguire test non riusciti nell'attività Di test di Visual Studio . Tuttavia, è stato segnalato solo l'ultimo tentativo di un test, che ha in qualche modo limitato l'utilità di questa funzionalità. Questa funzionalità è stata ora estesa per segnalare ogni istanza dell'esecuzione del test come tentativo. Inoltre, l'API Gestione test supporta ora la possibilità di pubblicare ed eseguire query sui risultati dei test gerarchici. Per altre informazioni, vedere la documentazione dell'API Dei risultati dei test.

Nota

Le metriche nella sezione di riepilogo dei test ,ad esempio test totali, superati e così via, vengono calcolate usando il livello radice della gerarchia anziché ogni singola iterazione dei test.

Visualizzare le analisi di test in Pipelines

La qualità dei test di rilevamento nel tempo e il miglioramento del materiale collaterale dei test è fondamentale per mantenere una pipeline integra. La funzionalità di analisi dei test offre visibilità quasi in tempo reale sui dati di test per le compilazioni e le pipeline di versione. Consente di migliorare l'efficienza della pipeline identificando problemi di qualità ripetitivi e ad alto impatto.

È possibile raggruppare i risultati dei test in base a vari elementi, identificare i test chiave per il ramo o i file di test oppure eseguire il drill-down in un test specifico per visualizzare le tendenze e comprendere i problemi di qualità, ad esempio flakiness.

Visualizzare l'analisi dei test per le compilazioni e il rilascio, anteprima di seguito:

Per altre informazioni, vedere la documentazione.

Semplificare le definizioni con più attività senza agente

Le attività in una fase senza agente vengono orchestrate e eseguite nel server. Le fasi senza agente non richiedono un agente o alcun computer di destinazione. A differenza delle fasi dell'agente, è possibile aggiungere una sola attività a ogni fase senza agente nelle definizioni. Ciò significava che era necessario aggiungere più fasi quando c'era più di un'attività senza agente nel processo, rendendo la definizione bulky. Questa restrizione è stata rilassata, che consente di gestire più attività in fasi senza agente. Le attività nella stessa fase vengono eseguite in sequenza, esattamente come avvieni per le fasi dell'agente. Per altre informazioni, vedere la documentazione sulle fasi del server.

Esporre progressivamente le distribuzioni in fasi e usando i controlli di rilascio

Usando i controlli di rilascio, è possibile specificare i criteri di integrità dell'applicazione che devono essere soddisfatti prima che una versione venga promossa all'ambiente successivo. Tutti i controlli specificati vengono valutati periodicamente prima o dopo qualsiasi distribuzione, fino a quando non hanno esito positivo. Sono disponibili quattro tipi di cancelli predefiniti ed è possibile aggiungere altri controlli dal Marketplace. Sarà possibile controllare che siano stati soddisfatti tutti i criteri necessari per una distribuzione. Per altre informazioni, vedere la documentazione relativa alle attività di controllo per la versione.

Conservare le distribuzioni fino a quando i controlli hanno esito positivo in modo coerente

I controlli di rilascio consentono la valutazione automatica dei criteri di integrità prima che una versione venga promossa all'ambiente successivo. Per impostazione predefinita, il rilascio avanza dopo che è stato ricevuto un esempio riuscito per tutti i controlli. Anche se un gate è irregolare e il campione di successo ricevuto è rumore, il rilascio avanza. Per evitare questi tipi di problemi, è ora possibile configurare la versione per verificare la coerenza dell'integrità per una durata minima prima dell'avanzamento. In fase di esecuzione, il rilascio garantisce che le valutazioni consecutive dei cancelli siano riuscite prima di consentire la promozione. Il tempo totale per la valutazione dipende dal "tempo tra la rivalutazione" e in genere è maggiore della durata minima configurata. Per altre informazioni, vedere la documentazione relativa al controllo della distribuzione del rilascio tramite gate .

Eseguire automaticamente la distribuzione in nuove destinazioni in un gruppo di distribuzione

In precedenza, quando sono state aggiunte nuove destinazioni a un gruppo di distribuzione, era necessaria una distribuzione manuale per garantire che tutte le destinazioni abbiano la stessa versione. È ora possibile configurare l'ambiente per distribuire automaticamente l'ultima versione riuscita nelle nuove destinazioni. Per altre informazioni, vedere la documentazione relativa ai gruppi di distribuzione.

Distribuire continuamente compilazioni contrassegnate dall'elaborazione post-compilazione

I trigger di distribuzione continua creano una versione al completamento della compilazione. Tuttavia, a volte le compilazioni vengono post-elaborate e la compilazione deve essere rilasciata solo dopo il completamento dell'elaborazione. È ora possibile sfruttare i tag di compilazione, che verrebbero assegnati durante la post-elaborazione, nei filtri trigger della versione.

Impostare una variabile in fase di rilascio

In una definizione di versione è ora possibile scegliere le variabili da impostare quando si crea la versione.

Il valore specificato per la variabile quando viene creata la versione viene usato solo per tale versione. Questa funzionalità consente di evitare più passaggi per Create-in-Draft, aggiornare le variabili nella bozza e attivare la versione con la variabile.

Passare le variabili di ambiente alle attività

Gli autori di attività CI/CD possono impostare una nuova proprietà, showEnvironmentVariables, nel task.json per passare variabili di ambiente alle attività. In questo caso, viene eseguito il rendering di un controllo aggiuntivo sull'attività nell'editor di compilazione. Questa opzione è disponibile per le attività di PowerShell, Cmd e Bash .

Ciò consente due scenari:

• Un'attività richiede una variabile di ambiente con maiuscole e minuscole mantenute nel nome della variabile. Ad esempio, nell'esempio precedente, la variabile di ambiente passata all'attività sarà "foo" e non "FOO".
• Consente di passare i valori dei segreti in modo sicuro agli script. È preferibile passare i segreti come argomenti agli script, perché il sistema operativo nell'agente può registrare la chiamata di processi, inclusi i relativi argomenti.

Clona i gruppi di variabili

È stato aggiunto il supporto per la clonazione di gruppi di variabili. Ogni volta che si vuole replicare un gruppo di variabili e aggiornare solo alcune delle variabili, non è necessario eseguire il processo noioso di aggiunta di variabili una alla volta. È ora possibile creare rapidamente una copia del gruppo di variabili, aggiornare i valori in modo appropriato e salvarli come nuovo gruppo di variabili.

Nota

I valori delle variabili segrete non vengono copiati quando si clona un gruppo di variabili. È necessario aggiornare le variabili crittografate e quindi salvare il gruppo di variabili clonato.

Ignorare un controllo di rilascio per una distribuzione

I controlli di rilascio consentono la valutazione automatica dei criteri di integrità prima che una versione venga promossa all'ambiente successivo. Per impostazione predefinita, la pipeline di versione avanza solo quando tutti i controlli sono integri contemporaneamente. In determinate situazioni, ad esempio quando si accelera una versione o dopo il controllo manuale dell'integrità, un responsabile approvazione può voler ignorare un gate e consentire al rilascio di progredire anche se tale gate deve ancora valutare come integro. Per altre informazioni, vedere la documentazione relativa ai controlli di rilascio.

Eseguire test aggiuntivi usando un trigger di rilascio della richiesta pull

È stato possibile attivare una compilazione basata su una richiesta pull e ottenere il feedback rapido prima di un merge per un po'. Ora è possibile configurare anche un trigger di richiesta pull per una versione. Lo stato della versione verrà pubblicato nuovamente nel repository di codice e può essere visualizzato direttamente nella pagina della richiesta pull. Ciò è utile se si desidera eseguire test funzionali o manuali aggiuntivi come parte del flusso di lavoro delle richieste pull.

Creare una connessione del servizio di Azure con un'entità servizio che esegue l'autenticazione con un certificato

È ora possibile definire una connessione al servizio di Azure con un'entità servizio e un certificato per l'autenticazione. Con la connessione al servizio di Azure ora che supporta l'entità servizio che esegue l'autenticazione con un certificato, è ora possibile eseguire la distribuzione in Azure Stack configurato con AD FS. Per creare un'entità servizio con l'autenticazione del certificato, vedere l'articolo su come creare un'entità servizio che esegue l'autenticazione con un certificato.

Esecuzione da pacchetto supportata nelle distribuzioni del Servizio app di Azure

La versione dell'attività di distribuzione del servizio app Azure (4.*) supporta ora RunFromPackage (precedentemente denominata RunFromZip).

servizio app supporta diverse tecniche per distribuire i file, ad esempio msdeploy (noto anche come WebDeploy), git, ARM e altro ancora. Ma tutte queste tecniche hanno una limitazione. I file vengono distribuiti nella cartella wwwroot (in particolare d:\home\site\wwwroot) e il runtime esegue i file da questa posizione.

Con Esegui dal pacchetto non è più disponibile un passaggio di distribuzione che copia i singoli file in wwwroot. Invece, si punta solo a un file ZIP, e il zip viene montato su wwwroot come file system di sola lettura. Ciò comporta diversi vantaggi:

• Riduce il rischio di problemi di blocco di copia dei file.
• Possono essere distribuiti in un'app di produzione (con il riavvio).
• È possibile sapere con sicurezza quali file sono in esecuzione nell'app.
• Migliora le prestazioni delle distribuzioni del servizio app Azure.
• Si possono ridurre i tempi di avvio a freddo, in particolare per le funzioni di JavaScript con grandi alberi del pacchetto npm.

Distribuisci contenitori Linux con l'attività di distribuzione del server applicazioni

La versione 4.* dell'attività di distribuzione del servizio app Azure supporta ora la distribuzione di un contenitore personalizzato in Funzioni di Azure in Linux.

Il modello di hosting Linux per Funzioni di Azure si basa su contenitori Docker che offrono maggiore flessibilità in termini di creazione di pacchetti e uso di dipendenze specifiche dell'app. Le funzioni in Linux possono essere ospitate in due modalità diverse:

1. Immagine del contenitore predefinita: il codice dell'app per le funzioni e Azure fornisce e gestisce il contenitore (modalità immagine predefinita), quindi non è necessaria alcuna conoscenza specifica correlata a Docker. Questa opzione è supportata nella versione esistente di servizio app Attività Distribuisci.
2. Immagine del contenitore personalizzata: è stata migliorata l'attività di distribuzione servizio app per supportare la distribuzione di immagini di contenitori personalizzate in Funzioni di Azure in Linux. Quando le funzioni necessitano di una versione specifica del linguaggio o richiedono una dipendenza o una configurazione specifica che non viene fornita all'interno dell'immagine predefinita, è possibile compilare e distribuire un'immagine personalizzata in Funzione di Azure in Linux usando Azure Pipelines.

L'attività Xcode supporta le funzionalità di Xcode 10 appena rilasciato

In coincidenza con la versione di Apple di Xcode 10, è ora possibile impostare i progetti per compilare o essere testati in modo specifico con Xcode 10. La pipeline può anche eseguire processi in parallelo con una matrice di versioni di Xcode. È possibile usare il pool di agenti macOS ospitato da Microsoft per eseguire queste compilazioni. Vedere le indicazioni per l'uso di Xcode in Azure Pipelines.

Semplificare la distribuzione in Kubernetes con Helm

Helm è uno strumento che semplifica l'installazione e la gestione delle applicazioni Kubernetes. Ha anche guadagnato un sacco di popolarità e supporto della community nell'ultimo anno. Un'attività Helm in Release è ora disponibile per la creazione di pacchetti e la distribuzione di grafici Helm nel servizio Azure Container o in qualsiasi altro cluster Kubernetes.

Con l'aggiunta di questa attività Helm, è ora possibile configurare una pipeline CI/CD basata su Helm per distribuire contenitori in un cluster Kubernetes. Per altre informazioni, vedere la documentazione Relativa alla distribuzione con Kubernetes nel servizio Azure Container.

Controllare la versione Helm usata nella versione

L'attività Programma di installazione dello strumento Helm acquisisce una versione specifica di Helm da Internet o dalla cache degli strumenti e la aggiunge al percorso dell'agente (ospitato o privato). Usare questa attività per modificare la versione di Helm usata nelle attività successive, ad esempio l'attività dell'interfaccia della riga di comando di .NET Core. L'aggiunta di questa attività prima dell'attività Helm Deploy in una definizione di compilazione o versione garantisce la creazione di pacchetti e la distribuzione dell'app con la versione Helm corretta. Questa attività consente anche di installare facoltativamente lo strumento kubectl , che è un prerequisito per il funzionamento di Helm.

Eseguire continuamente la distribuzione in Database di Azure per MySQL

È ora possibile eseguire la distribuzione continua in Database di Azure per MySQL - Database MySQL di Azure come servizio. Gestire i file di script MySQL nel controllo della versione e distribuirli continuamente come parte di una pipeline di versione usando un'attività nativa anziché gli script di PowerShell.

Usare attività basate su Windows Remote PowerShell migliorate

Sono disponibili attività basate su Windows Remote PowerShell nuove e migliorate. Questi miglioramenti includono diverse correzioni delle prestazioni e supportano i log live e i comandi di output della console, ad esempio Write-Host e Write-Output.

PowerShell nell'attività di destinazione (versione: 3.*): è possibile aggiungere script inline, modificare le opzioni PSSession, controllare "ErrorActionPreference" e non riuscire in caso di errore standard.

Attività Copia file di Azure (versione: 2.*): include la versione più recente di AzCopy (v7.1.0) che risolve un problema di GitHub.

Filtrare i rami per GitHub Enterprise o gli artefatti Git esterni

Quando si rilascia da GitHub Enterprise o da repository Git esterni, è ora possibile configurare i rami specifici che verranno rilasciati. Ad esempio, è possibile distribuire solo compilazioni provenienti da un ramo specifico all'ambiente di produzione.

Compilare applicazioni scritte in Go

Usare l'attività Programma di installazione strumento Go per installare una o più versioni di Go Tool in tempo reale. Questa attività acquisisce una versione specifica dello strumento Go necessaria per il progetto e la aggiunge al percorso dell'agente di compilazione. Se la versione dello strumento Go di destinazione è già installata nell'agente, questa attività ignorerà il processo di download e installazione di nuovo.

L'attività Go consente di scaricare dipendenze, compilare o testare l'applicazione. È anche possibile usare questa attività per eseguire un comando Go personalizzato di propria scelta.

Eseguire script Python inline o basati su file nella pipeline

Una nuova attività Script Python semplifica l'esecuzione di script Python nella pipeline. L'attività eseguirà uno script da un file Python (.py) nel repository oppure è possibile immettere manualmente uno script nelle impostazioni dell'attività per salvare come parte della pipeline. L'attività userà la versione di Python nel percorso oppure è possibile specificare un percorso assoluto per un interprete Python da usare.

Sfruttare l'output di compilazione e test di Xcode migliorato da xcpretty

xcpretty migliora la leggibilità dell'output di xcodebuild e genera i risultati dei test in formato JUnit. L'attività di compilazione Xcode usa ora automaticamente xcpretty quando è disponibile nel computer dell'agente, perché si trova negli agenti macOS ospitati. Anche se l'output xcpretty può essere diverso e meno dettagliato rispetto all'output di xcodebuild, i log xcodebuild completi sono disponibili con ogni compilazione.

Test Plans

Client test Runner (Piani di test di Azure) per eseguire test manuali per le applicazioni desktop

È ora possibile usare il client Test Runner (Piani di test di Azure) per eseguire test manuali per le applicazioni desktop. Ciò consentirà di passare da Microsoft Test Manager ai piani di test di Azure. Fare riferimento alle indicazioni riportate qui. Usando il client test Runner, è possibile eseguire i test manuali e registrare i risultati dei test per ogni passaggio di test. Sono disponibili anche funzionalità di raccolta dati, ad esempio screenshot, log azioni immagine e registrazione audio video. Se si verifica un problema durante il test, usare Test Runner per creare un bug con passaggi di test, screenshot e commenti inclusi automaticamente nel bug.

Test Runner (Piani di test di Azure) richiede un download e un'installazione monouso dello strumento di esecuzione. Selezionare Esegui per applicazione desktop come illustrato di seguito.

Artifacts

Origini upstream

Azure DevOps Server 2019 apporta aggiornamenti sostanziali alle origini upstream disponibili nei feed di Azure Artifacts:

• È possibile aggiungere nuget.org origini upstream ai feed esistenti creati nelle versioni precedenti di TFS. Cercare il banner sopra i pacchetti del feed per altre informazioni, incluse le modifiche del comportamento da tenere presenti prima dell'aggiornamento.
• È possibile aggiungere altri feed di Azure DevOps Server come origini upstream al feed, il che significa che è possibile usare pacchetti NuGet e npm da tali feed tramite il feed.

È stato introdotto anche un nuovo ruolo in Azure Artifacts: "Collaborator". Un collaboratore può salvare i pacchetti da un'origine upstream, ma non può pubblicare pacchetti direttamente nel feed ,ad esempio usando nuget publish. In questo modo è possibile limitare la pubblicazione dei pacchetti a un utente attendibile o al sistema di compilazione, consentendo ai tecnici di usare nuovi pacchetti dalle origini upstream.

Seguire i pacchetti

Abbiamo reso ancora più semplice configurare le notifiche con un nuovo pulsante Segui direttamente in ogni pacchetto. Il pulsante Segui è compatibile anche con le visualizzazioni di rilascio. Se si segue un pacchetto durante la visualizzazione, si otterranno solo gli aggiornamenti per le nuove versioni alzate di livello a tale visualizzazione.

Modificare le impostazioni del feed senza dover salvare manualmente

Alcune interazioni nella pagina delle impostazioni del feed sono state migliorate. Le modifiche apportate, ad esempio l'aggiunta di un upstream o un'autorizzazione, vengono salvate immediatamente. Ciò significa che non è necessario preoccuparsi di perdere le modifiche quando si passa da un pivot all'altro.

Simplify authentication using the new cross-platform Credential Provider for NuGet (Semplificare l'autenticazione con il nuovo provider di credenziali multipiattaforma)

L'interazione con i feed NuGet autenticati è stata notevolmente migliorata. Il nuovo provider di credenziali di Azure Artifacts basato su .NET Core funziona con msbuild, dotnet e nuget(.exe) in Windows, macOS e Linux. Ogni volta che si vogliono usare pacchetti da un feed di Azure Artifacts, il provider di credenziali acquisirà e archivierà automaticamente un token per conto del client NuGet in uso. Non è più necessario archiviare e gestire manualmente un token in un file di configurazione.

Per ottenere il nuovo provider, passare a GitHub e seguire le istruzioni per il client e la piattaforma.

Compress symbols when publishing to a file share (Comprimere i simboli durante la pubblicazione in una condivisione file)

L'attività Index & Publish Symbols è stata aggiornata per supportare la compressione dei simboli quando vengono pubblicati in una condivisione file.

Wiki

Pubblicare file markdown da un repository Git come wiki

Gli sviluppatori creano la documentazione per "API", "SDK" e "documentazione della Guida che illustra il codice" nei repository di codice. I lettori devono quindi esaminare il codice per trovare la documentazione corretta. Ora è possibile pubblicare semplicemente i file markdown dai repository di codice e ospitarli in Wiki.

Da Wiki, iniziare facendo clic su Pubblica codice come wiki. Successivamente, è possibile specificare una cartella in un repository Git che deve essere alzato di livello.

Dopo aver fatto clic su Pubblica, tutti i file markdown nella cartella selezionata verranno pubblicati come wiki. Verrà anche eseguito il mapping dell'head del ramo al wiki in modo che tutte le modifiche apportate al repository Git vengano riflesse immediatamente.

Per altre informazioni, vedere il post di blog della documentazione del prodotto.

Collegamento a intestazioni all'interno di una pagina

È ora possibile fare clic sull'icona del collegamento accanto a qualsiasi intestazione di sezione in una pagina wiki per generare un URL direttamente a tale sezione. È quindi possibile copiare l'URL e condividerlo con i membri del team per collegarli direttamente a tale sezione.

Allegare file e immagini in cartelle

Durante la modifica delle pagine wiki offline, può essere più semplice aggiungere file allegati e immagini nella stessa directory della pagina wiki. È ora possibile aggiungere un allegato o un'immagine in qualsiasi cartella del wiki e collegarla alla pagina.

Embed a video in wiki (Incorporare un video in un wiki)

È ora possibile incorporare video in una pagina wiki da Servizi online come Microsoft Stream e YouTube. È possibile aggiungere l'URL video incorporato usando la sintassi seguente:

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

Rename a wiki (Rinominare un wiki)

È ora possibile rinominare il wiki nell'interfaccia utente wiki e usare le API REST. Scegliere Rinomina wiki dal menu Altro per assegnare al wiki un nome memorabile.

Apri pagina nella nuova scheda

Ora è possibile fare clic con il pulsante destro del mouse su una pagina wiki e aprirlo in una nuova scheda oppure premere CTRL+sinistro clic su una pagina wiki per aprirlo in una nuova scheda.

Mantieni caratteri speciali nei titoli delle pagine Wiki

È ora possibile creare pagine wiki con caratteri speciali, : < > * ? | -ad esempio . Ora pagine con titoli come "Domande frequenti?" o "Guida di configurazione" può essere creato in Wiki. I caratteri seguenti vengono convertiti nelle stringhe con codifica UTF-8:

Carattere	Stringa codificata
:	%3A
<	%3C
>	%3E
*	%2A
?	%3F
|	%7C
-	%2D

Visualizzare i collegamenti interrotti

Tutti i collegamenti in un wiki che non sono collegati correttamente appariranno in un colore rosso distinto e icona di collegamento interrotto, dando un indizio visivo di tutti i collegamenti interrotti in una pagina wiki.

Correzione dei collegamenti interrotti durante lo spostamento delle pagine

I collegamenti di pagina interrotti sono una delle cause principali della scarsa qualità delle pagine in qualsiasi soluzione di documentazione. In precedenza in Wiki, quando si spostava una pagina all'interno della struttura ad albero o si rinominava una pagina, potrebbe potenzialmente interrompere i collegamenti alla pagina da altre pagine e elementi di lavoro. È ora possibile verificare la presenza e correggere i collegamenti prima che vengano interrotti.

Importante

Ricordarsi di usare la []() sintassi markdown per i collegamenti nelle pagine e il tipo di collegamento della pagina Wiki negli elementi di lavoro per consentire a Wiki di trovare e correggere questi collegamenti potenzialmente interrotti. Gli URL di testo normale e i collegamenti ipertestuali negli elementi di lavoro non verranno prelevati da questa funzionalità.

Quando si rinomina o si sposta una pagina, verrà richiesto di verificare la presenza di collegamenti assoluti o relativi interessati.

Verrà quindi visualizzato un elenco dei collegamenti pagina e degli elementi di lavoro interessati prima di eseguire un'azione.

Creare il sommario per le pagine wiki

A volte le pagine wiki possono diventare lunghe, con contenuto organizzato in diverse intestazioni. È ora possibile aggiungere un sommario a qualsiasi pagina con almeno un'intestazione usando la [[_TOC_]] sintassi .

È anche possibile inserire sommario facendo clic sul pulsante appropriato nel riquadro formato durante la modifica della pagina.

Per altre informazioni sull'uso di markdown in Azure DevOps, vedere la documentazione sulle linee guida per markdown.

Metadati di Surface per le pagine wiki e l'anteprima del codice usando tag YAML

L'aggiunta di metadati alla documentazione può aiutare i lettori e gli indici di ricerca a raccogliere e visualizzare contenuti significativi. In questo aggiornamento, tutti i file che contengono un blocco YAML all'inizio del file verranno trasformati in una tabella di metadati di una testa e una riga. Il blocco YAML deve assumere la forma di un set YAML valido tra linee tratteggiate triple. Supporta tutti i tipi di dati di base, l'elenco, l'oggetto come valore. La sintassi è supportata in Wiki e nell'anteprima del file di codice.

Esempio di tag YAML:

---
tag: post
title: Hello world
---

Esempio di tag YAML con elenco:

---
tags:
- post
- code
- web
title: Hello world
---

Pubblica codice come wiki con le autorizzazioni di Collaboratore

In precedenza, solo gli utenti che hanno l'autorizzazione Create Repository per un repository Git erano in grado di pubblicare il codice come wiki. In questo modo, gli amministratori del repository o gli autori hanno creato un collo di bottiglia per le richieste di pubblicazione di file markdown ospitati in repository Git come wiki. È ora possibile pubblicare il codice come wiki se si dispone solo dell'autorizzazione Contribute per il repository di codice.

Creazione di report

L'estensione del marketplace di Analisi per la creazione di report è ora disponibile

L'estensione Analytics Marketplace è ora disponibile per Azure DevOps Server. Analisi è il futuro della creazione di report per Azure DevOps e Azure DevOps Server. L'installazione dell'estensione Analytics fornisce widget avanzati, integrazione di Power BI e accesso OData.

Per altre informazioni, vedere Informazioni su Analisi e Roadmap per la creazione di report. Analisi è disponibile in anteprima pubblica. Attualmente contiene dati per boards e risultati di test automatizzati tramite pipeline. Vedere Dati disponibili nel servizio analisi.

Esaminare la cronologia di compilazione tramite un nuovo widget del dashboard di compilazione

È disponibile un widget della cronologia di compilazione nuovo e migliorato che è possibile aggiungere ai dashboard. Con questo widget è ora possibile visualizzare una cronologia delle compilazioni da un ramo specifico nel dashboard e configurarla in un progetto pubblico per i visitatori anonimi.

Importante

Se stai cercando informazioni dettagliate sulle compilazioni XAML, continua a usare il widget precedente e leggi la migrazione dalle compilazioni XAML alle nuove compilazioni. In caso contrario, è consigliabile passare al widget più recente.

---

Commenti

I commenti degli utenti sono molto apprezzati. È possibile segnalare un problema o fornire un'idea e monitorarla tramite Developer Community e ottenere consigli su Stack Overflow.

---

In alto