Note sulla versione di Azure DevOps Server 2019

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

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

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

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

---

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

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

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

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

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

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

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

Nota

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

Installare le patch

Importante

Sono stati rilasciati aggiornamenti all'agente di Azure Pipelines con patch 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 della 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	389BA66EEBC32622FB83402E2E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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

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

Requisiti della pipeline

Per usare il nuovo comportamento, è necessario impostare una variabile AZP_75787_ENABLE_NEW_LOGIC = true nelle pipeline che usano le attività interessate.

• In versione classica:

  Definire la variabile nella scheda della variabile nella pipeline.

• Esempio YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

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

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

Importante

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

Nota

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

Installare le patch

1. Scaricare e installare Azure DevOps Server 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 

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

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

• CVE-2023-36869: vulnerabilità di spoofing Azure DevOps Server.

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

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

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

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

Procedura 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. Può restituire un avviso simile a: Impossibile connettersi al server remoto. Non chiudere la finestra, perché l'aggiornamento esegue nuovi tentativi fino al completamento.

Nota

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

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

HASH SHA-256: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

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

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

• Correzione dell'errore dell'interfaccia utente della definizione di compilazione.

Azure DevOps Server 2019.0.1 Patch 10 Data di rilascio: 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

Installare

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 di Node.js) in base al computer.

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

npm install -g tfx-cli

4. Creare un token di accesso personale con privilegi di accesso completo e copiarlo. Questo token di accesso personale verrà usato quando si esegue il comando di accesso tfx .

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

~$ tfx login
Copyright Microsoft Corporation

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

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

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

Azure DevOps Server 2019.0.1 Patch 9 Data di rilascio: 8 dicembre 2020

È stata rilasciata una patch per Azure DevOps Server 2019.0.1 che risolve il codice seguente. Vedere il post di blog per altre informazioni.

• CVE-2020-1325: vulnerabilità spoofing Azure DevOps Server
• CVE-2020-17135: vulnerabilità spoofing Azure DevOps Server
• CVE-2020-17145: vulnerabilità spoofing Azure DevOps Server e Team Foundation Server
• Risolvere il problema con TFVC che non elabora tutti i risultati

Importante

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

Installazione generale delle patch

Se si ha 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 viene installato per c:\Program Files\Azure DevOps Server 2019 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 Azure PowerShell modulo Az Di Azure Powershell nel computer dell'agente privato.

2. Creare una pipeline con l'attività AzurePowerShellV4 . Nell'attività verrà visualizzato un solo errore di errore standard .

Installare

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 di Node.js) in base al computer.

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

npm install -g tfx-cli

4. Creare un token di accesso personale con privilegi di accesso completo e copiarlo. Questo token di accesso personale verrà usato quando si esegue il comando di accesso tfx .

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

~$ tfx login
Copyright Microsoft Corporation

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

6. Eseguire il comando seguente per caricare l'attività nel server. Il percorso del pacchetto estratto sarà D:\tasks (1)\AzurePowerShellv4.

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

Azure DevOps Server 2019.0.1 Data di rilascio 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.

Azure DevOps Server 2019.0.1 Data di rilascio 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 errata per gli utenti non autorizzati quando si seleziona Altra origine Git.
• Correzione dell'errore durante la modifica dell'ereditarietà su Attiva o Disattivata nella definizione di compilazione XAML.

Azure DevOps Server 2019.0.1 Data di rilascio 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

Azure DevOps Server 2019.0.1 Patch 5 Data di rilascio: 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 script tra siti
• CVE-2020-0758: elevazione dei privilegi
• CVE 2020-0815: elevazione dei privilegi

Azure DevOps Server 2019.0.1 Data di rilascio 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à scripting cross site (XSS) in Repos
• CVE-2019-1306 : vulnerabilità di esecuzione remota del codice in Wiki

---

Azure DevOps Server 2019.0.1 Data di rilascio 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.

---

Azure DevOps Server 2019.0.1 Data di rilascio 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 nella verifica di elementi di lavoro
• CVE-2019-1076 : vulnerabilità scripting cross site (XSS) nelle richieste pull

---

Azure DevOps Server data di rilascio 2019.0.1: 21 maggio 2019

Azure DevOps Server 2019.0.1 è un roll up delle correzioni di bug. Include tutte le correzioni nelle patch Azure DevOps Server 2019 rilasciate in precedenza. È possibile installare direttamente Azure DevOps Server 2019.0.1 o aggiornare 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 Developer Community.
• 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 elemento di lavoro in un altro campo elemento di lavoro in un progetto diverso può creare un'immagine interrotta.

Azure Repos

• "TF401019: GitRepositoryNotFoundException".

Azure Pipelines

• La scheda Analisi test ha un star (*) 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 avvio della bozza di versione stava creando una nuova versione, ma ora avvia la versione bozza.

Azure Test Plans

• Il filtro di 1 ora in 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 Developer Community.
• Usando l'API delete test case, i test case possono essere eliminati da altri progetti. Segnalato tramite Developer Community.
• Facendo clic su un collegamento all'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 diversi lavori pianificati per gli utenti in fusi orari diversi.
• Un blocco può essere inserito nell'inserimento dei dati di Analytics durante la manutenzione che può causare report non aggiornati.

Generale

• Gli elementi di spostamento a sinistra vengono compressi in Internet Explorer quando non è disponibile 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 è utilizzabile.
• 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 della ricerca.
• Sono presenti stringhe non localizzate nei risultati delle pagine di ricerca.

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 nell'elenco a discesa Versione della piattaforma di test.

---

Azure DevOps Server 2019 Patch 2 Data di rilascio: 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à scripting cross site (XSS) in Test Plans
• CVE-2019-0971 : vulnerabilità di diffusione di informazioni nell'API Repos
• CVE-2019-0979 : vulnerabilità scripting cross site (XSS) nell'hub utente

---

Azure DevOps Server 2019 Patch 1 Data di rilascio: 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 in Pipelines
• CVE-2019-0867 : vulnerabilità scripting cross site (XSS) in Pipelines
• CVE-2019-0868 : vulnerabilità scripting cross site (XSS) in Pipelines
• CVE-2019-0869: vulnerabilità di inserimento HTML in Pipelines
• CVE-2019-0870 : vulnerabilità scripting cross site (XSS) in Pipelines
• CVE-2019-0871 : vulnerabilità scripting cross site (XSS) in Pipelines
• CVE-2019-0874: vulnerabilità di scripting tra siti (XSS) in Pipelines
• CVE-2019-0875: vulnerabilità di elevazione dei privilegi in Boards

---

data di rilascio 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 commit e richieste pull di GitHub Enterprise a Azure Boards elementi di lavoro
• Configurare le compilazioni con YAML
• Le annotazioni delle schede includono bug e tipi di elementi di lavoro personalizzati
• Selezione ramo migliorata
• Modifiche agli artefatti e alle licenze della pipeline di distribuzione 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 il database Azure SQL
• Ereditarietà dei processi nelle nuove raccolte
• Nuovo hub elementi di lavoro
• Nuovi hub boards, backlog e sprint
• Nuovo hub query
• Standardizzare le descrizioni delle richieste pull usando i modelli
• Modificare 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 pagina Nuove versioni
• Visualizzare lo stato di avanzamento della versione
• Aggiornare localmente l'agente
• Esporre progressivamente le distribuzioni in fase e usando i controlli di rilascio
• Origini upstream
• Creare sommario per le pagine wiki

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

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

---

Generale

Annuncio di Azure DevOps Server

Il 10 settembre, Azure DevOps è stato annunciato come l'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 agli artefatti e alle licenze della pipeline di distribuzione 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 di base potranno ora usare gli artefatti. In secondo luogo, i clienti non dovranno più acquistare Release Management pipeline di distribuzione. Proprio come le pipeline di compilazione, Release Management pipeline di distribuzione sono ora incluse in Azure DevOps Server 2019.

Supporto per il database Azure SQL

Per semplificare l'esperienza di esecuzione di Azure DevOps 2019 in Azure, è stato abilitato il supporto per Azure SQL Database (per utilizzo generico S3 e versioni successive). In questo modo è possibile sfruttare funzionalità di backup estese e opzioni di ridimensionamento in base alle esigenze, riducendo al tempo stesso 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, vedere la documentazione .

Elemento di lavoro & 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.

Ereditarietà dei processi 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

Si comprende l'importanza della ricerca e si riporta 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 commenti e suggerimenti 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 un rapido sguardo alle informazioni cruciali, tra cui 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 nel codice, ma si vuole controllare rapidamente l'elemento di lavoro su cui si dovrebbe lavorare successivamente, è possibile semplicemente 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 corrente:

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 preferiti, i dashboard, le bacheche, i backlog, le query e i repository:

Boards

Collegare commit e richieste pull di GitHub Enterprise a Azure Boards elementi di lavoro

I team 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 avere ancora un flusso di lavoro che si integra con i flussi di lavoro per 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, il titolo della richiesta pull o la 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.

Nuovo hub elementi di lavoro

L'hub elementi di lavoro è il nuovo hub che fungerà da casa degli elementi di lavoro. In questo caso sono disponibili molte visualizzazioni elenco diverse degli elementi di lavoro con ambito. È 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. Di seguito sono riportate tutte le opzioni dell'elenco:

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 facendo semplicemente 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 sprint

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, ad esempio 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 bacheche 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. Alcune caratteristiche principali della nuova esperienza includono:

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

Per altre informazioni su questi interessanti aggiornamenti, vedere il blog di DevOps.

Spostare 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 elementi di lavoro in un altro progetto all'interno di una raccolta di progetti. Queste funzionalità richiedono che il data warehouse sia disabilitato. Se 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 sprint esistente direttamente dall'hub Sprints .
• Usare il nuovo riquadro Pianificazione nel backlog per trascinare e rilasciare elementi di lavoro in sprint futuri. Il riquadro Pianificazione include date sprint, conteggi degli elementi di lavoro e attività pianificate.
• 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 directory

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

• Continuare da dove è stato interrotto Questa nuova sezione fornisce un collegamento rapido direttamente all'ultimo (Board | Backlog | Sprint) sei stato acceso.
• Preferiti Tutte le bacheche preferite, gli sprint e i backlog in tutti i team.
• Mio Tutte le bacheche, i backlog e gli sprint per i team a cui si appartiene.
• Tutti Elenco completo di tutte le schede, backlog e sprint.

Menu Nuove opzioni di visualizzazione

I nuovi hub, inclusi Backlog, Boards e Sprint, hanno un nuovo menu Opzioni di visualizzazione . Si tratta di 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 scheda attività, per attivare il pannello laterale per il mapping e la pianificazione degli sprint o per esplorare i grafici dei dettagli di lavoro.

Per altre informazioni su questi interessanti aggiornamenti, il nuovo riquadro Profilo team e 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 intuitiva dell'elenco di controllo e l'interazione. 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 elementi 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 iterazione e esplorare ripetutamente le gerarchie durante lo spostamento degli elementi di lavoro. I controlli Percorso di area e iterazione ora includono 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 consegnato un elemento di lavoro.

Il funzionamento 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 è stata usata la @CurrentIteration macro nelle query precedenti, è possibile che i risultati possano 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 rilevante per la query. Con il parametro Team è possibile usare la @CurrentIteration macro nella stessa query, ma tra 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 concentrarsi su backlog, bacheche, piani, anche dashboard al lavoro per il team. Se si vuole tuttavia 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'utente usando il 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.

Aprire 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 ramo migliorata

Per la maggior parte delle esperienze in Azure Repos è necessario 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 di richiesta pull vengono ignorati

Per i team che usano richieste pull e criteri di ramo, possono verificarsi situazioni 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. È opportuno fidarsi degli sviluppatori di fare la cosa giusta e 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 agli utenti e ai team di ricevere avvisi di posta elettronica ogni volta che un criterio viene ignorato. Iniziare con il modello A pull request is created or updated and select Policy Bypass (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.

Consente di ignorare i criteri di ramo senza rinunciare alla protezione push

Esistono molti scenari in cui si ha la necessità occasionale di ignorare un criterio di ramo, ovvero il ripristino di una modifica che ha causato un'interruzione di compilazione, l'applicazione di un hotfix durante la notte e così via. In precedenza, è stata offerta un'autorizzazione ("Esenzione dall'applicazione dei criteri") per aiutare i team a gestire gli utenti a cui è stata concessa la possibilità di ignorare i criteri di ramo 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. Ignorare i criteri durante il completamento delle richieste pull. Gli utenti con questa autorizzazione potranno usare l'esperienza "Override" per le richieste pull.
2. Ignorare i criteri durante il push. Gli utenti con questa autorizzazione potranno eseguire il push direttamente nei rami in cui sono configurati i criteri necessari.

Concedendo la prima autorizzazione e negando il secondo, 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 precedentemente concessi Consenti per "Esenzione dall'imposizione dei criteri" verrà concesso Consenti per entrambe le nuove autorizzazioni, in modo che possano eseguire l'override del completamento nelle richieste pull e 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 con più commit richiedono 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 accodare 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 di richiesta pull, si è pensato che sarebbe 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.

Nell'ambito 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 include una funzionalità per semplificare l'aggiunta di 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: basta fare clic sull'azione "Personalizza questa visualizzazione" accanto all'intestazione della 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 da eseguire per ogni modifica, ad esempio il 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 e che questa funzionalità è stata aggiunta.

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

Modificare 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 specificare come destinazione un ramo diverso, è facile dimenticare di modificare il ramo di destinazione dall'impostazione predefinita. Con la nuova funzionalità per modificare il ramo di destinazione di una richiesta pull attiva, questa è ora una semplice azione. Basta 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 il "retarget" 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 di funzionalità, in modo da avere inizialmente come destinazione features/new-feature. I revisori possono quindi visualizzare solo le modifiche e lasciare i commenti appropriati.

Si consideri ora 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 mainoppure 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 in main, mantenendo tutto il contesto e i commenti. La modifica del ramo di destinazione crea anche un nuovo aggiornamento alla richiesta pull, semplificando la visualizzazione delle differenze precedenti prima della modifica del ramo di destinazione.

Gli autori di estensioni possono eseguire query sul contesto del repository corrente

Uno dei problemi per un autore di un'estensione del controllo della versione consiste nel 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 si seleziona un repository TFVC o si accede al servizio all'esterno delle pagine Azure Repos, verrà restituito null.

Ecco un'estensione di esempio che usa questo servizio.

Pipelines

Gestire le pipeline di compilazione usando la nuova pagina Compilazioni

Sono stati apportati diversi miglioramenti e la distribuzione di 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 compilazione e di completamento 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 nelle 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/rilascio eseguito nell'infrastruttura ospitata nel cloud gestita 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.
Compilazione	Compilazione	Istanza di una pipeline di compilazione in esecuzione o in esecuzione.
Fase	Processo	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.
Versione	Versione	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 in una versione.

Per altre informazioni, vedere la documentazione relativa ai concetti .

Gestire le pipeline di versione usando la pagina Nuove versioni

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

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 dettagli e azioni appropriati 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 versione, le versioni degli artefatti e i tag.

Gli ambienti vengono modellati in modo da facilitare la comprensione dello stato, insieme allo stato 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 delle approvazioni e dei controlli. Lo stato di avanzamento 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 che si blocca a destra o a sinistra 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.

Stato 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 viene aperta una visualizzazione contenente i log, con lo stato attivo.

È possibile fare clic nei log per immettere una visualizzazione evidenziata.

Impatto dell'aggiornamento a 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 computer Windows" versione 1.* e "PowerShell nei computer di destinazione" versione 1.*. Affinché le pipeline continuino a funzionare,

• È necessario passare all'attività "Copia file computer Windows" versione 2.* e specificare il nome fqdn 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 il nome fqdn completo del computer o del nome del computer seguito dalle porte di gestione remota Di 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 nella 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 le pipeline di compilazione basate su YAML in modo più semplice, è 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 del 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 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 viene modificato un componente upstream ,ad esempio una libreria, è necessario ricompilare e riconvalidare le dipendenze downstream. 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 in più fasi può 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 richiedono talvolta una versione più recente dell'agente pipelines. Se il 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 il 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 i Azure DevOps Server a Internet.

URL della nuova notifica di 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 finora sono stati compilati badge, si sono verificati alcuni problemi:

• L'URL non era 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 le notifiche 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 della notifica 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.

Aggiungere contatori di compilazione personalizzati alle compilazioni

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 variabili contatori 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 sul 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 .

Criteri di Azure le convalide di conformità e sicurezza in Pipeline

Vogliamo garantire stabilità e sicurezza del software nelle prime fasi del processo di sviluppo, mettendo insieme sviluppo, sicurezza e 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 sulla conformità e sulla sicurezza come parte del processo di rilascio, è stata migliorata l'esperienza di distribuzione del gruppo di risorse di Azure. A questo momento, 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 aggiunto anche 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.

Compilazione su piattaforme Linux/ARM e Windows a 32 bit

Azure Pipelines open source, l'agente 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 creare 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 di contesto, nella segnalazione dell'esecuzione di test interrotta e nel riepilogo del livello di esecuzione.

Visualizzare l'esecuzione di test in corso

I test, ad esempio l'integrazione e i test funzionali, possono essere eseguiti per molto tempo, quindi è importante visualizzare l'esecuzione dei test in qualsiasi momento. Con la visualizzazione test di In-Progress, 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 versione usando l'attività Test di Visual Studio in più fasi, 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 In-Progress test 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 In-Progress test precedente, è possibile visualizzare il riepilogo dettagliato del test insieme alle informazioni sui test non riuscite o interrotte in Test Plans. Il riepilogo dei test viene aggiornato a intervalli periodici con la possibilità di aggiornare la visualizzazione dei dettagli su richiesta, in base alla disponibilità dei 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 necessitano di spazio immobiliare sufficiente per visualizzare i dettagli durante il debug. Per avere un'esperienza di debug immersiva, è ora possibile espandere la visualizzazione di esecuzione del test o del test alla visualizzazione a 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

In passato, i team dovranno passare all'hub Esecuzioni per visualizzare la cronologia di un risultato del test. Con la nuova esperienza, la cronologia dei test viene portata direttamente nel contesto all'interno della scheda Test Plans 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 Test Plans. La funzionalità è attualmente disponibile sia per la pipeline di compilazione che per la versione usando l'attività di test di Visual Studio in più fasi o per 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.

Testare la tracciabilità e gli ambienti di rilascio in Cronologia test

Viene aggiunto il supporto per visualizzare la cronologia di un test automatizzato raggruppato in vari ambienti di rilascio in cui viene eseguito il test. Se si modellano gli ambienti di rilascio come pipeline di versione o ambienti di test e si eseguono test in tali ambienti, è possibile verificare se un test viene superato nell'ambiente di sviluppo, ma ha esito negativo nell'ambiente di integrazione. È possibile scoprire se passano 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 ha avuto esito negativo.

Esaminare i risultati dei test riepilogati

Durante l'esecuzione del test, un test potrebbe 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 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 del test ,ad esempio test totali, superati e così via, vengono calcolate usando il livello radice della gerarchia anziché ogni singola iterazione dei test.

Visualizzare l'analisi dei test in Pipeline

Tenere traccia della qualità dei test nel tempo e migliorare i materiali di 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 pipeline di compilazione e versione. Consente di migliorare l'efficienza della pipeline identificando problemi ripetitivi e di qualità 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 da ed 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'erano più attività senza agente nel processo, rendendo la definizione in blocco. 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 avvieno per le fasi dell'agente. Per altre informazioni, vedere la documentazione sulle fasi del server .

Esporre progressivamente le distribuzioni in fase 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 vengono tutti completati. 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 non 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, la versione procede dopo che è stato ricevuto un esempio riuscito per tutti i controlli. Anche se un gate non è corretto e il campione ricevuto correttamente è 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 è superiore alla durata minima configurata. Per altre informazioni, vedere la documentazione relativa al controllo della distribuzione del rilascio usando gates .

Distribuire automaticamente 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 verranno 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 in 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, in 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 funzionalità è disponibile per le attività di PowerShell, Cmd e Bash .

In questo modo si abilitano due scenari:

• Un'attività richiede una variabile di ambiente con distinzione tra maiuscole e minuscole nel nome della variabile. Nell'esempio precedente, ad esempio, 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 dei processi, inclusi i relativi argomenti.

Clonare 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 poche 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 clonate.

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 (PR) e ottenere tale feedback rapido prima di un'unione per un po'. È ora possibile configurare anche un trigger di richiesta pull per una versione. Lo stato della versione verrà pubblicato 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 della richiesta pull.

Creare una connessione al 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 che supporta ora 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.

Eseguire dal pacchetto supportato nelle distribuzioni di Servizio app di Azure

La versione Servizio app di Azure Deploy task (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 quindi i file da questa posizione.

Con Esegui da pacchetto non è più disponibile un passaggio di distribuzione che copia i singoli file in wwwroot. Si punta invece a un file ZIP e il file 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 di Servizio app di Azure.
• Si possono ridurre i tempi di avvio a freddo, in particolare per le funzioni di JavaScript con grandi alberi del pacchetto npm.

Distribuire contenitori Linux con l'attività Distribuzione server app

La versione 4.* dell'attività di distribuzione Servizio app di 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 funzionalità è supportata nella versione esistente di servizio app'attività Distribuisci.
2. Immagine del contenitore personalizzata: È stata migliorata l'attività distribuisci 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 xcode 10 appena rilasciata

In combinazione con la versione di Apple di Xcode 10, è ora possibile impostare i progetti da compilare o testare 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 sostegno della comunità 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 la distribuzione di 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à Helm Tool Installer 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 la distribuzione continua in Database di Azure per MySQL

È ora possibile eseguire la distribuzione continua in Database di Azure per MySQL: il 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é 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.

Attività di PowerShell in 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.*): viene fornita con 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 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 strumenti Go per installare una o più versioni di Go Tool in tempo reale. Questa attività acquisisce una versione specifica di Go Tool 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 a 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 (con estensione 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 a un interprete Python da usare.

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

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

Test Plans

Client test Runner (Azure Test Plans) per eseguire test manuali per le applicazioni desktop

È ora possibile usare il client Test Runner (Azure Test Plans) per eseguire test manuali per le applicazioni desktop. Ciò consente di passare da Microsoft Test Manager a Azure Test Plans. Fare riferimento alle nostre indicazioni 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 video audio. 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 (Azure Test Plans) richiede un download one-time e l'installazione del runner. Selezionare Esegui per l'applicazione desktop , come illustrato di seguito.

Artifacts

Origini upstream

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

• È 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 al comportamento da tenere presente prima dell'aggiornamento.
• È possibile aggiungere altri feed 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 anche introdotto un nuovo ruolo negli artefatti di Azure: "Collaboratore". Un collaboratore può salvare i pacchetti da un'origine upstream, ma non può pubblicare pacchetti direttamente nel feed, ad esempio usando la pubblicazione nuget. Ciò consente di limitare la pubblicazione del pacchetto a un utente attendibile o al sistema di compilazione, consentendo ai tecnici di usare nuovi pacchetti dalle origini upstream.

Seguire i pacchetti

È stato reso ancora più semplice configurare le notifiche con un nuovo pulsante Segui direttamente su ogni pacchetto. Il pulsante Segui è compatibile anche con le visualizzazioni della versione. Se si segue un pacchetto esaminandolo tramite una visualizzazione, si otterranno solo gli aggiornamenti per le nuove versioni che vengono promosse 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 modifiche quando si passa tra i pivot delle impostazioni.

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 è molto meglio. Il nuovo provider di credenziali Azure Artifacts basato su .NET Core funziona con msbuild, dotnet e nuget(.exe) in Windows, macOS e Linux. Ogni volta che si desidera usare i pacchetti da un feed di Elementi di Azure, il provider di credenziali acquisisce automaticamente e archivia un token per conto del client NuGet usato. 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 i simboli di compressione quando vengono pubblicati in una condivisione file.

Wiki

Pubblicare i file markdown da un repository Git come wiki

Gli sviluppatori creano la documentazione per "API", "SDK" e "documentazione della Guida che spiega il codice" nei repository di codice. I lettori devono quindi analizzare 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. È quindi possibile specificare una cartella in un repository Git che deve essere promosso.

Dopo aver fatto clic su Pubblica, tutti i file markdown nella cartella selezionata verranno pubblicati come wiki. Verrà anche mappato il capo 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 sulla documentazione del prodotto .

Collegamento alle 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 in tale sezione. È quindi possibile copiare tale URL e condividerlo con i membri del team per collegarli direttamente a tale sezione.

Collegare file e immagini nelle cartelle

Durante la modifica delle pagine wiki offline, è possibile aggiungere più facilmente allegati e immagini file 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 puoi incorporare video in una pagina wiki da Servizi online, ad esempio 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. Dal menu Altro fare clic su Rinomina wiki per assegnare al wiki un nome memorabile.

Aprire la pagina nella nuova scheda

È ora possibile fare clic con il pulsante destro del mouse su una pagina wiki e aprirla in una nuova scheda oppure premere CTRL + sinistra fare clic su una pagina wiki per aprirla in una nuova scheda.

Conservare i caratteri speciali nei titoli della pagina Wiki

È ora possibile creare pagine wiki con caratteri speciali, : < > * ? | -ad esempio . Ora le pagine con titoli come "Domande frequenti?" o "Guida di configurazione" può essere creata in Wiki. I caratteri seguenti vengono convertiti nelle stringhe codificate 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 verranno visualizzati in un colore rosso distinto e un'icona di collegamento interrotta, fornendo un indizio visivo di tutti i collegamenti interrotti in una pagina wiki.

Correzione dei collegamenti interrotti durante lo spostamento di pagine

I collegamenti di pagina interrotti sono una delle cause principali della scarsa qualità della pagina in qualsiasi soluzione di documentazione. In precedenza in Wiki, quando si sposta una pagina all'interno della struttura ad albero o si è rinominata una pagina, potrebbe potenzialmente interrompere i collegamenti alla pagina da altre pagine e elementi di lavoro. Ora, è possibile verificare e correggere i collegamenti prima di essere 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 raccolti da questa funzionalità.

Quando si rinomina o si sposta una pagina, viene 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 l'azione.

Creare un sommario per le pagine wiki

A volte le pagine wiki possono ottenere molto tempo, con contenuto organizzato in diverse intestazioni. È ora possibile aggiungere un sommario a qualsiasi pagina con almeno un titolo usando la [[_TOC_]] sintassi.

È anche possibile inserire il 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 relativa al markdown .

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

L'aggiunta di metadati alla documentazione consente ai lettori e agli indici di ricerca di raccogliere e visualizzare contenuti significativi. In questo aggiornamento, qualsiasi file contenente un blocco YAML all'inizio del file verrà trasformato in una tabella di metadati di una testa e una riga. Il blocco YAML deve assumere la forma di set YAML valido tra linee con trattini 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
---

Pubblicare codice come wiki con autorizzazioni Di contributo

In precedenza, solo gli utenti che hanno l'autorizzazione Create Repository in un repository Git sono stati in grado di pubblicare codice come wiki. Ciò ha reso gli amministratori del repository o i creatori un collo di bottiglia per le richieste di pubblicazione di file markdown ospitati in git repos come wiki. È ora possibile pubblicare codice come wiki se si dispone solo dell'autorizzazione Di contributo per il repository di codice.

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 offre widget avanzati, integrazione di Power BI e accesso OData.

Per altre informazioni, vedere Informazioni su Analisi e roadmap per i report. L'analisi è disponibile in anteprima pubblica. Attualmente contiene dati per le schede e i risultati di test automatizzati tramite pipeline. Vedere Dati disponibili nel servizio analisi.

Analizzare 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 si cercano informazioni dettagliate sulle build XAML, continuare a usare il widget meno recente e leggere la migrazione dalle build XAML alle nuove build. In caso contrario, è consigliabile passare al widget più recente.

---

Commenti e suggerimenti

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

---

Inizio pagina