Note sulla versione di Azure DevOps Server 2019

Developer CommunityRequisiti | | di sistemaCondizioni | di licenza DevOpsHash di BlogSHA-1 |

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

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

L'aggiornamento diretto a Azure DevOps Server 2020 è supportato da Azure DevOps Server 2019 o Team Foundation Server 2015 o versione successiva. Se la distribuzione 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 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 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.

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

Installazione

  1. Estrarre il pacchetto AzureResourceGroupDeploymentV2.zip in una nuova cartella del computer. Ad esempio: AzureResourceGroupDeploymentV2.

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

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

npm install -g tfx-cli
  1. Creare un token di accesso personale con privilegi di accesso completo e copiarlo. Questo token di accesso personale verrà usato quando si esegue il comando tfx login .

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

  1. Eseguire il comando seguente per caricare l'attività nel server. Usare il percorso del file .zip estratto dal passaggio 1.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

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

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

  • CVE-2020-1325: vulnerabilità di spoofing Azure DevOps Server
  • CVE-2020-17135: vulnerabilità di spoofing Azure DevOps Server
  • CVE-2020-17145: vulnerabilità di spoofing Azure DevOps Server e Team Foundation Server
  • Correzione del problema relativo all'elaborazione di tutti i risultati di TFVC

Importante

Prima di installare questa patch, leggere le istruzioni complete fornite di seguito.

Installazione generale delle patch

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

Verifica dell'installazione

  • Opzione 1: eseguire devops2019.0.1patch9.exe CheckInstall, devops2019.0.1patch9.exe è il file scaricato dal collegamento precedente. L'output del comando indica che la patch è stata installata o che non è installata.

  • Opzione 2: Controllare la versione del file seguente: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll. Azure DevOps Server 2019 è installato in c:\Program Files\Azure DevOps Server 2019 per impostazione predefinita. Dopo aver installato Azure DevOps Server 2019.0.1 Patch 9, la versione sarà 17.143.30723.4 .

Installazione dell'attività AzurePowerShellV4

Nota

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

Prerequisiti

  1. Installare Azure PowerShell modulo Az azure Powershell nel computer dell'agente privato.

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

Installazione

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

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

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

npm install -g tfx-cli
  1. Creare un token di accesso personale con privilegi di accesso completo e copiarlo. Questo token di accesso personale verrà usato quando si esegue il comando tfx login .

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

  1. 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 Patch 8 Data di rilascio: 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 Patch 7 Data di rilascio: 14 luglio 2020

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

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

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

Azure DevOps Server 2019.0.1 Patch 3 Data di rilascio: 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 Patch 2 Data di rilascio: 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 Patch 1 Data di rilascio: 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 2019.0.1 Data di rilascio: 21 maggio 2019

Azure DevOps Server 2019.0.1 è un rollup di 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 eseguire l'aggiornamento da Azure DevOps Server 2019 o Team Foundation Server 2012 o versione successiva.

Nota

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

Questa versione include correzioni per i bug seguenti:

Azure Boards

  • "I criteri di campo per questo piano hanno un errore." durante la configurazione di un piano. Segnalato tramite 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 a 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 una stella (*) che indica l'anteprima, anche se questa funzionalità non è in anteprima.
  • Nella scheda Versioni l'azione per gestire la sicurezza viene ora visualizzata a tutti gli utenti indipendentemente dal fatto che possano modificare o meno le autorizzazioni.
  • Nelle pagine di destinazione Delle versioni, l'azione di 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 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.

Screenshot of the Execution options section showing the Test platform version dropdown list selected with the Latest Visual Studio 2019 option selected.


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à xss (Cross site scripting) 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:


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:

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


Generale

Annuncio di Azure DevOps Server

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

Nuova esperienza di spostamento

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

New nav

Modifiche alle licenze Artifacts e pipeline di distribuzione Release Management

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

Supporto per database SQL di Azure

Per semplificare l'esperienza di esecuzione Azure DevOps 2019 in Azure, è stato abilitato il supporto per database SQL di Azure (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 .

API SOAP del modello a oggetti client di test degli elementi & di lavoro 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.

Process inheritance

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:

Default search box

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

Expanded search box

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 in basso 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:

My work flyout

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:

My work flyout PR

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:

My work flyout favorites

Boards

Teams che usano GitHub Enterprise per il codice e vogliono funzionalità avanzate di gestione dei progetti possono ora integrare i repository con Azure Boards. Connettendo GitHub e Azure Boards, è possibile ottenere tutte le funzionalità come backlog, bacheche, strumenti di pianificazione dello sprint, più tipi di elementi 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. ​

Screenshot of Azure DevOps with the Development section called out.

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.

Teams che usano Azure Pipelines per compilare il codice in GitHub vedranno anche gli elementi di lavoro collegati ai commit 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:

Work items hub

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:

Work items hub list

Nuovi Boards, backlog e hub Sprints

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

  • L'hub Backlogs è ora la casa dei backlog per un progetto. Un backlog è un elenco di lavoro con priorità per il team. I backlog forniscono strumenti di pianificazione, ad esempio gerarchia degli elementi di lavoro, previsione e nuova esperienza di pianificazione dello sprint.
  • Il nuovo hub Boards è la casa di tutti i Boards Kanban per un progetto. Boards vengono usati 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 è la casa delle funzionalità usate per pianificare ed eseguire un incremento del lavoro. Ogni sprint contiene un backlog sprint, un taskboard e una vista per gestire e impostare la capacità per il team.

Boards hub

Nuovo hub query

Il nuovo hub query semplifica molte delle funzionalità delle query esistenti dall'hub precedente con un aspetto più moderno e offre nuove funzionalità per semplificare l'accesso alle query importanti per l'utente. Alcune evidenziazioni della nuova esperienza includono:

  • Pagine directory con l'ultima modifica delle informazioni e la possibilità di cercare query
  • Breadcrumb 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 aggiornamenti interessanti, 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. Con il data warehouse disabilitato, è possibile usare il servizio Analisi per supportare le esigenze di creazione di report. Per altre informazioni sulla disabilitazione del data warehouse, vedere Disabilitare il data warehouse e il cubo.

Funzionalità di pianificazione sprint

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

  • Creare lo sprint successivo o sottoscrivere una pianificazione sprint esistente direttamente dall'hub Sprints .
  • Usare il nuovo riquadro Pianificazione nel backlog per trascinare e rilasciare elementi di lavoro negli sprint futuri. Il riquadro Pianificazione include date sprint, conteggi degli elementi di lavoro e sforzo pianificato.
  • Aggiungere i requisiti all'inizio di Taskboard o usare la creazione rapida per aggiungere alla parte superiore, inferiore o riga di scelta nel backlog sprint.
  • Usare i filtri per l'assegnazione, il tipo di elemento di lavoro, lo stato e i tag per personalizzare le visualizzazioni alle proprie esigenze.

Sprint planning

Nuove pagine directory

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

  • Continua dove hai lasciato Questa nuova sezione fornisce un collegamento rapido direttamente all'ultimo (scheda | Backlog | Sprint) sei stato su.
  • Preferiti Tutte le schede, gli sprint e i backlog preferiti in tutti i team.
  • Mio Tutte le schede, i backlog e gli sprint per i team a cui si appartiene.
  • Tutti Elenco completo di tutte le tue schede, backlog e sprint.

Directory pages

Menu Nuove opzioni di visualizzazione

I nuovi hub, inclusi backlog, Boards e Sprint, hanno un nuovo menu Opzioni di visualizzazione. Questa è una nuova home 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 Group By in una taskboard, per attivare il pannello laterale per il mapping e pianificare gli sprint o per esplorare i grafici dei dettagli di lavoro.

View options

Altre informazioni su questi aggiornamenti interessanti, nuovo riquadro profilo team e Preferiti nel nostro blog di DevOps.

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

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

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

Annotation settings

Quando le annotazioni per l'elemento di lavoro sono abilitate, i conteggi per tale tipo di elemento di lavoro vengono inclusi nella scheda come elenco di controllo separato.

Annotation work item

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

Annotation quick create

Spostare il lavoro usando aree e iterazioni suggerite

Può essere comune lavorare nella stessa area o iterazione e esplorare ripetutamente le gerarchie quando si spostano gli elementi di lavoro. I controlli Percorso area e iterazione includono ora un elenco di valori usati di recente come suggerimenti, consentendo l'accesso rapido per impostare e spostarsi.

Area drop down list

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

Iteration drop down list

Eseguire query nell'intera pianificazione dell'iterazione con +/- @CurrentIteration

La @CurrentIteration macro che consente al team di tenere traccia del lavoro in base alla pianificazione dell'iterazione ora supporta 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 sul blog di Microsoft DevOps.

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

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

Team parameter

Eseguire query nel percorso area di un team con la nuova @TeamAreas macro

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

team areas macro in query editor

Query per campi di testo 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 nei collegamenti e nelle esperienze di 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 è stato eseguito di recente l'accesso, nonché un punto di ingresso per cercare un elemento di lavoro specifico in base all'ID o al titolo.

Work item linking

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 scavare nei 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 di rami migliorata

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

Branch picker

Ricevere notifiche quando vengono ignorati i criteri di richiesta pull

Per i team che usano richieste pull (PRS) e criteri di ramo, potrebbero verificarsi occasioni in cui le persone devono eseguire l'override e ignorare tali criteri, ad esempio quando si distribuisce un hotfix a un problema di produzione al centro della notte. È consigliabile fidarsi degli sviluppatori di fare la cosa giusta e usare la funzionalità di override in modo spasimo. Allo stesso tempo, i team necessitano di un modo per verificare che tali overridi dei criteri vengano usati 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 la richiesta pull viene creato o aggiornato e selezionare Ignora criteri dall'elenco dei filtri. Selezionare Criteri ignorati come valore e si riceverà una notifica in qualsiasi momento in cui viene completata una richiesta di notifica e i criteri vengono ignorati.

Bypass policy notification

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- ripristinando una modifica che ha causato un'interruzione di compilazione, applicando un hotfix al centro della notte e così via. In precedenza è stata offerta un'autorizzazione ("esentata dall'imposizione dei criteri") per aiutare i team a gestire gli utenti che hanno concesso la possibilità di ignorare i criteri di ramo durante il completamento di una richiesta pull. Tuttavia, tale autorizzazione ha concesso anche la possibilità di eseguire il push direttamente nel ramo, ignorando completamente il processo di richiesta richiesta.

Per migliorare questa esperienza, è stata suddivisa l'autorizzazione precedente per offrire più controllo ai team che concedeno 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 che hanno i criteri necessari configurati.

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

Nota

Questa modifica non introduce modifiche al comportamento. Gli utenti che in precedenza avevano concesso Consenti per "esentare dall'applicazione dei criteri" verranno concessi Consenti per entrambe le nuove autorizzazioni, in modo da poter eseguire l'override del completamento in PRS e eseguire il push direttamente nei rami con i criteri.

Per altre informazioni, vedere la documentazione Imposta autorizzazioni ramo .

Descrivere rapidamente le richieste pull usando i messaggi di commit

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

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

Creare richieste pull senza un team predefinito come revisore

Quando è stata avviata per la prima volta l'esperienza pull della richiesta pull, si è pensato che sarebbe opportuno assegnare tutte le richieste al contesto del team selezionato durante la creazione della richiesta di richiesta. 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 di richiesta.

Nell'ambito delle nuove modifiche di spostamento, abbiamo preso l'opportunità di modificare questa associazione predefinita con i team. Si noteranno due modifiche:

  1. Quando si crea una richiesta di richiesta di richiesta, nessun revisore viene aggiunto per impostazione predefinita. L'elenco revisori dispone di una funzionalità per semplificare l'aggiunta di singoli utenti e gruppi aggiunti di recente alle richieste. I criteri di revisori necessari possono anche aiutare i team che vogliono assicurarsi che i revisori specifici vengano aggiunti per esaminare il codice.
  2. L'hub richieste pull ha una nuova sezione personalizzabile. Per impostazione predefinita, questa sezione mostra le RICHIESTE "Assegnate ai miei team", fornendo funzionalità equivalenti come la sezione precedente. Tuttavia, se si appartiene a più team, questa sezione mostrerà le RICHIESTE assegnate a uno qualsiasi 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 modelli

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

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

Add template for PR

I modelli specifici del ramo sono supportati anche se si vuole applicare un modello diverso per una richiesta di richiesta richiesta in una cartella specifica di ramo o 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 tutti i file PR in tali rami.

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

Modificare il ramo di destinazione di una richiesta pull

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

Change target branch

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 di richiesta di richiesta di destinazione di un ramo di funzionalità che contiene alcune funzionalità che dipendono dalle modifiche. Si desidera esaminare le modifiche dipendenti in isolamento da altre modifiche nel ramo di funzionalità, in modo che inizialmente si destinazione features/new-feature. I revisori possono quindi visualizzare solo le modifiche e lasciare i commenti appropriati.

Si consideri ora cosa succederebbe se il ramo di funzionalità aveva anche un'attività di richiesta e fu unito prima main delle modifiche? In precedenza, è necessario abbandonare le modifiche e creare una nuova richiesta di richiesta in o unire la richiesta pr in mainfeatures/new-featuree quindi creare un'altra richiesta richiesta da features/new-feature a main. Con questa nuova azione per aggiornare il ramo di destinazione, è sufficiente modificare il ramo di destinazione della richiesta di richiesta features/new-feature da in main, mantenendo tutti i commenti e il contesto. La modifica del ramo di destinazione crea anche un nuovo aggiornamento alla richiesta di richiesta, che semplifica l'analisi delle versioni precedenti prima della modifica del ramo di destinazione.

Target branch update

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

Una delle sfide 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. Per risolvere questo problema, è stato aggiunto VersionControlRepositoryService come servizio accessibile dall'estensione. In questo modo, un autore di estensioni può eseguire query per informazioni sul contesto del repository Git corrente all'interno dell'interfaccia utente Web. Attualmente ha un metodo, getCurrentGitRepository().

  • Se viene selezionato un repository Git, viene restituito un oggetto GitRepository con dati di base sul repository (nome, ID e URL)
  • Se viene selezionato un repository TFVC o il servizio viene eseguito 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 Build

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

New Builds page

Gestire i messaggi di posta elettronica di compilazione e di completamento della distribuzione migliori usando la formattazione migliorata

I messaggi di posta elettronica di compilazione e di completamento della distribuzione sono stati aggiornati per essere più filtrabili dalle 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 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, indicare la differenza tra un pool di agenti e una coda dell'agente.

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 in esecuzione nell'infrastruttura ospitata dal cloud gestito da Microsoft.
Agente privato Agente self-hosted Agente di compilazione/rilascio in esecuzione in un computer fornito e gestito dall'utente.
Pool di agenti Pool di agenti Set di macchine agente a livello di organizzazione che possono eseguire build o versioni.
Coda agente Pool di agenti Set di macchine 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 dei passaggi di compilazione per un'applicazione.
Compilare Compilare 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 di passaggi di rilascio end-to-end 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 simultanee 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 ai servizi esterni per eseguire attività in una compilazione o versione.

Per altre informazioni, vedere la documentazione Sui concetti .

Gestire le pipeline di rilascio usando la nuova pagina Versioni

Per la pagina di destinazione della versione è disponibile una nuova esperienza utente completamente riprogettata. Vedere un elenco delle pipeline di rilascio rilasciate spesso a sinistra. È anche possibile cercare le pipeline e selezionarle preferite.

Release landing page

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

Release folders

Visualizzare lo stato di avanzamento della versione

La nuova visualizzazione dello stato di avanzamento della versione offre aggiornamenti live dello stato di avanzamento della distribuzione e l'accesso con un clic per ulteriori dettagli. La nuova visualizzazione visualizza la pipeline di rilascio, rendendo più semplice comprendere le operazioni e i dettagli e le azioni appropriati in fasi diverse della versione.

Release Pipeline view

Pipeline, dettagli della versione e ambienti

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

Gli ambienti vengono modellati in modo da comprendere lo stato, insieme allo stato dettagliato. A qualsiasi punto, è possibile accedere ai log facendo clic sul collegamento di stato all'interno dell'ambiente.

Environments

Pre-distribuzione e post-distribuzione

Se le condizioni di pre-distribuzione o post-distribuzione sono state impostate per un ambiente, è indicato nell'ambiente con la presenza delle approvazioni e dei cancelli. Lo stato delle approvazioni e dei cancelli si presenta anche nello stato dell'ambiente. È possibile eseguire l'azione o visualizzare altri dettagli facendo clic sull'icona della condizione dell'ambiente in sospeso sul lato destro o sinistro dell'ambiente.

Release environment actions

Commit e elementi di lavoro

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

Release commits and work items

Avanzamento e log della distribuzione

Gli ambienti mostrano gli aggiornamenti live per le distribuzioni in corso, tra cui il numero di fasi e le 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 sui log per immettere una visualizzazione incentrata.

Release log details

Impatto dell'aggiornamento a Azure DevOps Server 2019 sulle attività: Windows Copia file di computer 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. In questo modo gli utenti dell'attività 'Windows Copia file di computer' versione 1.* e 'PowerShell on Target Machines' versione 1.*. Per continuare a funzionare le pipeline,

  • È necessario passare all'attività 'Windows Copia file computer' 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 dalla Windows porte di gestione remota (http/https). Ad esempio, targetMachine:5985 o targetMachine:5986

Risultati di test ed estendibilità

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

Release test results

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 più facilmente, è 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) per essere utilizzabile in tutte le pipeline di tale progetto. Se si vuole controllare più strettamente le risorse, è possibile disabilitare il modello di autorizzazione predefinito (vedere la figura seguente). Quando si esegue questa operazione, 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 alla risorsa al file YAML.

YAML

I prodotti di grandi dimensioni hanno diversi componenti dipendenti tra loro. Questi componenti vengono spesso compilati in modo indipendente. Quando un componente upstream (una libreria, ad esempio) cambia, le dipendenze downstream devono essere ricompilate e riconvalidate. Teams in genere gestire queste dipendenze manualmente.

È ora possibile attivare una compilazione al completamento di un'altra compilazione. Artifacts prodotto da una compilazione upstream può essere scaricato e usato nella compilazione successiva e è anche possibile ottenere dati da queste variabili: Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.TriggeredBy.BuildDefinitionName. Per altre informazioni, vedere la documentazione dei trigger di compilazione .

Setup build chaining

Tenere presente che in alcuni casi, una singola compilazione a più fasi potrebbe soddisfare le proprie esigenze. Tuttavia, un trigger di completamento della compilazione è utile se i requisiti includono impostazioni di configurazione, opzioni o un team diverso per il proprio 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 sul disco locale anziché da Internet. Ciò offre flessibilità e controllo sulle versioni dell'agente disponibili, senza dover esporre il Azure DevOps Server a Internet.

NUOVO URL di notifica dello stato di compilazione

Creare badge incorporati nella home page di un repository è un modo comune per mostrare l'integrità del repository. Anche se sono stati compilati badge fino ad ora, sono stati riscontrati alcuni problemi:

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

A questo punto viene implementata 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 di notifica di stato selezionando l'azione menu Notifica stato nella nuova pagina Compilazioni.

Per la compatibilità con le versioni precedenti, continuerà a rispettare anche gli URL di badge di compilazione precedenti.

Aggiungere contatori di compilazione personalizzati alle compilazioni

I contatori di compilazione offrono un modo per numerare e etichettare in modo univoco le compilazioni. In precedenza, è possibile usare la variabile speciale $(rev:r) per eseguire questa operazione. È ora possibile definire le proprie variabili di contatore 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 una 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 compilazione e viene reimpostata automaticamente ogni volta che è presente un nuovo prefisso nel numero di compilazione.
  • È 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 convalida della conformità e della sicurezza in Pipelines

Vogliamo garantire stabilità e sicurezza del software all'inizio del processo di sviluppo, portando 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 per la conformità e la sicurezza nell'ambito del processo di rilascio, è stata migliorata l'esperienza di distribuzione del gruppo di risorse di Azure. Ora, 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.

Azure Policy

Inoltre, è stato aggiunto Criteri di Azure modello di definizione 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.

Azure Policy template

Build on Linux/ARM e Windows piattaforme a 32 bit

Il Azure Pipelines open source, l'agente multipiattaforma è sempre stato supportato in Windows, macOS e Linux a 64 bit. Con questa versione vengono introdotti due nuove piattaforme supportate: Linux/ARM e Windows/32 bit. Queste nuove piattaforme offrono la possibilità di compilare in modo meno comune, ma non meno importante, piattaforme come Raspberry Pi, un computer Linux/ARM.

Esperienze migliorate per i test in Pipelines

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

New Test hub

Visualizzare l'esecuzione di test in corso

I test, ad esempio l'integrazione e i test funzionali, possono essere eseguiti per molto tempo, pertanto è importante visualizzare l'esecuzione dei test in qualsiasi momento. Con la visualizzazione test In-Progress, non è più necessario attendere il completamento dell'esecuzione del test per conoscere il risultato del test. I risultati sono disponibili in tempo quasi reale durante l'esecuzione, consentendo di eseguire azioni più velocemente. È possibile eseguire il debug di un errore o di 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à Vs Test in più agenti, usando l'attività Pubblica risultati dei test o pubblicando i risultati dei test usando 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 stato di rilascio, segnalando il numero totale di test e il numero di errori di test in un determinato momento.

In-progress test view

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

Detailed test summary

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

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

Full page debugging

Visualizzare la cronologia dei test nel contesto

Storicamente, i team devono passare all'hub Esecuzioni per visualizzare la cronologia di un risultato di test. Con la nuova esperienza, la cronologia dei test viene visualizzata nel contesto all'interno della scheda Test Plans per la compilazione e la versione. 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, seguite rispettivamente da altri rami e ambienti per la compilazione e la versione.

In-context test history

Visualizzare i test interrotti

L'esecuzione del test può interrompere a causa di più motivi, ad esempio codice di test non valido, origine in fase di test e problemi ambientali. Indipendentemente dal motivo dell'interruzione, è importante diagnosticare il comportamento e identificare la causa radice. È ora possibile visualizzare i test e le esecuzioni di test interrotti, 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 VS nella fase multi agent o la pubblicazione dei risultati dei test usando api. In futuro si prevede di estendere questa esperienza per l'esecuzione di test usando Single Agent.

View aborted tests

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

Si aggiunge il supporto per la visualizzazione della cronologia di un test automatizzato raggruppato da vari ambienti di rilascio in cui viene eseguito il test. Se si modellano gli ambienti di rilascio come pipeline di rilascio o ambienti di test e si eseguono test in tali ambienti, è possibile scoprire se un test passa nell'ambiente di sviluppo, ma non riesce nell'ambiente di integrazione. Potresti scoprire se passa nelle impostazioni locali inglesi, ma non riesce 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, verrà inoltre trovato il rilascio dopo il quale 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 che vengono eseguiti a causa di errori, test costituiti 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 presentati come gerarchia nella scheda Test in una versione. Di seguito è descritto un esempio.

In precedenza è stata introdotta la possibilità di eseguire di nuovo test non riusciti nell'attività VS Test . Tuttavia, è stato segnalato solo l'ultimo tentativo di un test, che ha limitato in qualche modo l'utilità di questa funzionalità. Questa funzionalità è ora 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 .

Test summary debug

Nota

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

Visualizzare l'analisi dei test in Pipelines

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

È possibile raggruppare i risultati dei test in base a vari elementi, identificare i test chiave per i file di ramo o di test o 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 la versione, visualizzare l'anteprima seguente:

Test analytics

Per altre informazioni, vedere la documentazione.

Semplificare le definizioni con più attività senza agente

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

Esporre progressivamente le distribuzioni e le fasi usando i cancelli di rilascio

Usando i cancelli di rilascio, è possibile specificare criteri di integrità dell'applicazione che devono essere soddisfatti prima che una versione venga promossa all'ambiente successivo. Tutte le porte specificate vengono valutate periodicamente prima o dopo qualsiasi distribuzione, fino a quando non sono tutte riuscite. Quattro tipi di cancelli sono disponibili fuori dalla scatola e è possibile aggiungere altri cancelli dal Marketplace. Sarà possibile controllare che tutti i criteri necessari per una distribuzione siano stati soddisfatti. Per altre informazioni, vedere la documentazione relativa alle attività di controllo per la versione.

Release gates panel

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

I cancelli di rilascio consentono la valutazione automatica dei criteri di integrità prima che una versione venga promossa all'ambiente successivo. Per impostazione predefinita, il rilascio viene eseguito dopo la ricezione di un campione riuscito per tutti i cancelli. Anche se un gate non è errato e il campione riuscito ricevuto è rumore, il rilascio procede. 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, la versione garantisce che le valutazioni consecutive dei cancelli abbiano esito positivo prima di consentire la promozione. Il tempo totale per la valutazione dipende dal "tempo tra la rivalutazione" e in genere sarà maggiore della durata minima configurata. Per altre informazioni, vedere il controllo Distribuzione versione usando la documentazione di gate.

Gates hold setting

Distribuire automaticamente in nuove destinazioni in un gruppo di distribuzione

In precedenza, quando sono state aggiunte nuove destinazioni a un gruppo di distribuzione, è stata 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 dei gruppi di distribuzione .

Deployment groups

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.

build tag trigger

Impostare una variabile in fase di rilascio

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

Release variable

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.

Release variable in release

Passare le variabili di ambiente alle attività

Gli autori di attività CI/CD possono impostare una nuova proprietà, showEnvironmentVariables, nell'oggetto task.json per passare le variabili di ambiente alle attività. Quando si esegue questa operazione, viene eseguito il rendering di un controllo aggiuntivo nell'attività nell'editor di compilazione. Questa operazione è disponibile per le attività di PowerShell, Cmd e Bash .

Pass environment variables

Ciò consente 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 di 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.

Clone variable group

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 .

Ignore gates

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 nuovamente nel repository di codice e può essere visualizzato direttamente nella pagina della richiesta pull. Ciò è utile se si desidera eseguire test funzionali o manuali aggiuntivi come parte del flusso di lavoro della richiesta pull.

PR trigger in Release

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.

Connect with service principal

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

Xcode 10

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 .

helm tasks

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 PowerShell remote Windows migliorate

Sono disponibili attività basate su PowerShell nuove e migliorate Windows remote. 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.

branch filters

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 per un interprete Python da usare.

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

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

Test Plans

Client test Runner (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 linee guida riportate qui. Usando il client Test Runner, è possibile eseguire i test manuali e registrare i risultati del 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 e un'installazione monouso del runner. Selezionare Esegui per l'applicazione desktop come illustrato di seguito.

Azure Test Runner

Azure Test Runner install

Artifacts

Origini upstream

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

  • È possibile aggiungere nuget.org origini upstream ai feed esistenti creati nelle versioni precedenti di TFS. Cercare il banner sopra i pacchetti del feed per altre informazioni, incluse le modifiche 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.

Abbiamo anche introdotto un nuovo ruolo in Azure Artifacts: "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 di NuGet autenticati è molto meglio. Il nuovo provider Azure Artifacts di credenziali 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 Azure Artifacts, il provider di credenziali acquisisce automaticamente e archivia un token per conto del client NuGet in uso. Non è più necessario archiviare e gestire manualmente un token in un file di configurazione.

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

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

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

Compress symbols

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.

public code as wiki action

Da Wiki, iniziare facendo clic su Pubblica codice come wiki. È quindi possibile specificare una cartella in un repository Git che deve essere promosso.

publish pages dialog

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 .

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

Wiki heading URL

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.

Wiki image in git repo folder

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

Embed video in wiki

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.

Rename wiki

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.

Wiki new tab

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

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.

Wiki broken links

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.

Move page dialog

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

Move page links

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.

Wiki table of contents

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

Insert wiki TOC

Per altre informazioni sull'uso di markdown in Azure DevOps, vedere la documentazione sulle linee guida per il 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
---

YAML table

Esempio di tag YAML con elenco:

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

YAML table with list

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 nel 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. L'analisi è il futuro della creazione di report per Azure DevOps e Azure DevOps Server. L'installazione dell'estensione Analytics offre widget avanzati, Power BI integrazione 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 Boards e risultati di test automatizzati tramite Pipelines. 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