Note sulla versione di Azure DevOps Server 2019 Update 1

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 Update 1.2 Patch 1 Data di rilascio: 12 luglio 2022

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

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

Azure DevOps Server 2019 Update 1.2 Data di rilascio: 17 maggio 2022

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

Nota

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

Questa versione include correzioni per quanto segue:

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

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

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

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

Procedura di installazione

  1. Aggiornare il server con patch 13.
  2. Controllare il valore del Registro di sistema in HKLM:\Software\Elasticsearch\Version. Se il valore del Registro di sistema non è presente, aggiungere un valore stringa e impostare Version su 5.4.1 (Name = Version, Value = 5.4.1).
  3. Eseguire il comando 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 13.
  2. Controllare il valore del Registro di sistema in HKLM:\Software\Elasticsearch\Version. Se il valore del Registro di sistema non è presente, aggiungere un valore stringa e impostare Version su 5.4.1 (Name = Version, Value = 5.4.1).
  3. Copiare il contenuto della cartella denominata zip, che si trova 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: DB762E391F9DF8E71E58D6FAA169CA44DFBE996AE6567B55F772CBA9E3DA2AB3

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

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

  • Correzione della macro dell'elemento di lavoro per le query con "Contiene parole". In precedenza, le query restituivano risultati non corretti per i valori che conteneva un'interruzione di riga.
  • Problema di localizzazione per gli stati di layout degli elementi di lavoro personalizzati.
  • Problema di localizzazione nel modello di notifica tramite posta elettronica.
  • Problema con la valutazione delle regole NOTSAMEAS quando sono state definite più regole NOTSAMEAS per un campo.

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

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

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

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

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

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

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

  • Correzione del problema relativo all'importazione dei dati. L'importazione dei dati richiedeva molto tempo per i clienti che hanno molti test case non aggiornati. Ciò è dovuto a riferimenti che hanno aumentato le dimensioni della tbl_testCaseReferences tabella. Con questa patch sono stati rimossi riferimenti a test case non aggiornati per velocizzare il processo di importazione dei dati.

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

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

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

Installazione generale delle patch

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

Verifica dell'installazione

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

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

Installazione 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: D:\tasks\AzureResourceGroupDeploymentV2.

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

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

npm install -g tfx-cli
  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 Update 1.1 Patch 7 Data di rilascio: 12 gennaio 2021

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

  • I dettagli dell'esecuzione dei test non visualizzano i dettagli dei passaggi di test per i dati di test migrati tramite la migrazione di OpsHub
  • Eccezione sull'inizializzatore per 'Microsoft.TeamFoundation.TestManagement.Server.TCMLogger'
  • Le compilazioni non gestite vengono eliminate immediatamente dopo la migrazione a Azure DevOps Server 2020
  • Correzione dell'eccezione del provider di dati

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

È stata rilasciata una patch per Azure DevOps Server 2019 Update 1.1 che corregge quanto segue. 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 Services
  • Risolvere il problema con controllo della versione di Team Foundation non elaborare tutti i risultati

Importante

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

Installazione generale delle patch

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

Verifica dell'installazione

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

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

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 .

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 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
  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 di accesso tfx .

  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\AzurePowerShellv4.
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

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

È stata rilasciata una patch per Azure DevOps Server 2019 Update 1.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 Update 1.1 Patch 4 Data di rilascio: 14 luglio 2020

È stata rilasciata una patch per Azure DevOps Server 2019 Update 1.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 Attiva o Disattivata nella definizione di compilazione XAML.

Azure DevOps Server 2019 Update 1.1 Patch 3 Release Date: 9 giugno 2020

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

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

Azure DevOps Server 2019 Update 1.1 Patch 2 Release Date: 14 aprile 2020

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

  • I commit SVN non attivano la pipeline

  • Aggiunta del supporto per SHA2 in SSH in Azure DevOps

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

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


Azure DevOps Server 2019 Update 1.1 RTW Release Date: 10 dicembre 2019

Azure DevOps Server 2019 Update 1.1 è un roll up delle correzioni di bug e degli aggiornamenti della sicurezza. Include tutte le correzioni nelle patch Azure DevOps Server 2019 Update 1 rilasciate in precedenza. È possibile installare direttamente Azure DevOps Server 2019 Update 1.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 Update 1.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

  • Quando si crea un nuovo elemento di lavoro dal backlog del prodotto, il campo Titolo non viene inizializzato con il valore predefinito nel modello di processo.
  • Lentezza e timeout quando si usano Azure Boards.
  • Il valore Revisionato per valore non è corretto nei collegamenti all'elemento di lavoro.

Azure Pipelines

Azure Test Plans

  • La modifica dei campi in Test Plans è lenta.
  • In un test case, quando si apre da Boards (anziché da Test Plans), i dettagli del passaggio condiviso non vengono aperti.

Generale

Amministrazione

  • Utilizzo elevato della memoria.
  • I server con configurazioni del servizio di bilanciamento del carico hanno dovuto aggiungere in modo esplicito l'origine pubblica alla voce del Registro di sistema AllowedOrigins.
  • I clienti che installano in SQL Azure non visualizzano la finestra di dialogo Completa versione di valutazione.
  • L'installazione delle estensioni specifica l'errore "Messaggio di errore Mancante contributo (ms.vss-dashboards-web.widget-sdk-version-2)".
  • Quando si configura La ricerca elastica, si verifica un errore: "L'utente non è autorizzato".
  • Errori di indicizzazione e query in Ricerca elastica durante l'aggiornamento da TFS 2018 Update 2 o versione successiva.
  • Il passaggio "Create Warehouse" ha esito negativo quando si configura Azure DevOps Server.

Questa versione include l'aggiornamento seguente:

  • Supporto per SQL Server 2019.

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

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

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

data di rilascio Azure DevOps Server 2019 Update 1: 20 agosto 2019

Nota

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


Data di rilascio RC2: 23 luglio 2019

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


Data di rilascio RC1: 2 luglio 2019

Riepilogo delle novità di Azure DevOps Server 2019 Update 1

Azure DevOps Server 2019 Update 1 introduce molte nuove funzionalità. Tra le caratteristiche principali:

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


Generale

Tema scuro

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

Tema scuro

Boards

Nuovo processo di base

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

Il nuovo processo Basic offre tre tipi di elemento di lavoro (Epics, Issues e Tasks) per pianificare e tenere traccia del lavoro. È consigliabile usare Problemi per tenere traccia di elementi come storie utente, bug e funzionalità durante l'uso di Epics per raggruppare i problemi in unità di lavoro più grandi. Durante l'avanzamento del lavoro, spostare gli elementi lungo un semplice flusso di lavoro di stato To Do, Doing e Done.

processo di base

Per iniziare a usare il nuovo progetto, vedere la documentazione tenere traccia dei problemi e delle attività .

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

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

di stato dell'ordine di statoordine

L'abilitazione delle funzionalità non è più disponibile

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

abilitazione

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

Organizzare i materiali di riferimento con allegati degli elementi di lavoro più avanzati

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

Allegati degli elementi di lavoro allegati agli

Condividere la bacheca del team usando un badge

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

Breve video che mostra come condividere le bacheche del team usando il badge.

Se il file README è basato su Markdown, è sufficiente copiare il markdown di esempio dalla pagina delle impostazioni della notifica di stato e incollarlo nel file.

Screenshot che mostra il badge in un file README in GitHub.

Query per il lavoro rispetto all'inizio del giorno, della settimana, del mese o dell'anno

Anche se i team si concentrano spesso sul lavoro nel contesto delle novità successive o basate su iterazioni sprint, spesso è interessante esaminare il lavoro attraverso l'obiettivo del calendario per segnalare tutto il lavoro che è accaduto lo scorso mese o nel primo trimestre dell'anno. È ora possibile usare il nuovo set di macro @StartOf seguente insieme a qualsiasi campo basato su data per eseguire query in base all'inizio del giorno, della settimana, del mese o dell'anno:

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

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

Screenshot che mostra la query relativa all'inizio del giorno, della settimana, del mese o dell'anno.

Modificare ed eliminare i commenti di discussione

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

Screenshot che mostra i commenti di discussione.

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

Screenshot che mostra come eliminare i commenti di discussione.

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

Esportare i risultati della query in un file CSV

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

Breve video che mostra come esportare i risultati delle query.

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

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

Screenshot che mostra una richiesta pull in GitHub.

Accettare ed eseguire problemi in GitHub durante la pianificazione in Azure Boards

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

Screenshot che mostra che è possibile collegare elementi di lavoro in Azure Boards con problemi correlati in GitHub.

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

Screenshot che mostra come collegare manualmente in Azure Boards con l'URL del problema di GitHub.

Visualizzare rapidamente l'attività GitHub collegata dalla scheda Kanban

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

Screenshot che mostra come visualizzare l'attività GitHub collegata dalla scheda Kanban.

Repos

Bozze di richieste pull

Per evitare che le richieste pull vengano completate prima che siano pronte e per semplificare la creazione di un lavoro in corso che potrebbe non coinvolgere tutti, è ora supportato il progetto di richieste pull.

È possibile creare richieste pull bozza selezionando Crea come bozza dall'elenco a discesa Crea durante la creazione di una richiesta pull.

Creare una bozza di richiesta pull

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

Screenshot di una richiesta pull che mostra che si tratta di una bozza.

Le richieste pull bozza non includono revisori o eseguono compilazioni per impostazione predefinita, ma consentono di aggiungere manualmente revisori ed eseguire compilazioni. Per alzare di livello la richiesta pull a una normale richiesta pull, è sufficiente fare clic sul pulsante Pubblica dalla pagina dei dettagli della richiesta pull.

Rieseguire la compilazione scaduta per le richieste pull completate automaticamente

Azure Repos ora accoderanno automaticamente le compilazioni scadute attivate da un criterio di richiesta pull. Questo vale per le richieste pull che hanno superato tutti gli altri criteri e sono impostate sul completamento automatico.

In precedenza, quando le richieste pull avevano criteri come i revisori richiesti, il processo di approvazione potrebbe richiedere troppo tempo e una compilazione associata potrebbe scadere prima che un revisore abbia approvato la richiesta pull. Se la richiesta pull è stata impostata sul completamento automatico, rimarrà bloccata fino a quando un utente accodò manualmente la compilazione scaduta. Con questa modifica, la compilazione verrà accodata automaticamente in modo che la richiesta pull possa essere completata automaticamente dopo una compilazione riuscita.

Nota

Questa automazione accoderà solo fino a cinque compilazioni scadute per ogni richiesta pull e tenterà di accodare di nuovo ogni compilazione una sola volta.

Visualizzare solo il file sinistro o destro in una richiesta pull

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

Screenshot delle opzioni diff side-by-side con il cursore che si posiziona sul pulsante Mostra contenuto modificato.

Nuovi tipi di merge per il completamento delle richieste pull

Sono ora disponibili altre opzioni quando si uniscono le modifiche da una richiesta pull al ramo di destinazione. È stato aggiunto il supporto per due delle funzionalità più richieste nella Developer Community: unione fast-forward e unione semi-lineare (denominata anche "Rebase e Merge").

Queste nuove opzioni saranno ora disponibili nella finestra di dialogo Completa richiesta pull :

Screenshot che mostra i nuovi tipi di merge per il completamento delle richieste pull.

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

Screenshot della sezione Limita tipi di unione.

Nota

I criteri esistenti vengono ancora applicati. Ad esempio, se il ramo dispone attualmente di un criterio "solo merge di squash", sarà necessario modificare tale criterio per usare le nuove strategie di merge.

Durante il completamento della richiesta pull non è possibile eseguire il rebasing in alcune situazioni:

  • Se un criterio nel ramo di destinazione impedisce l'uso di strategie di ribase, sarà necessaria l'autorizzazione "Override branch policies".
  • Se il ramo di origine della richiesta pull include criteri, non sarà possibile ribaserlo. La ribasing modificherà il ramo di origine senza eseguire il processo di approvazione dei criteri.
  • Se è stata usata l'estensione dei conflitti di merge per risolvere i conflitti di merge. Le risoluzioni dei conflitti applicate a un'unione a tre vie raramente hanno esito positivo (o addirittura valido) quando si ribasano tutti i commit in una richiesta pull una alla volta.

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

Filtrare in base al ramo di destinazione nelle richieste pull

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

Per semplificare la ricerca delle richieste pull, è stata aggiunta un'opzione di filtro per consentire la ricerca di richieste pull tramite il ramo di destinazione.

Screenshot delle opzioni di filtro delle richieste pull di Azure Pipelines.

È anche possibile usare il filtro del ramo di destinazione per personalizzare la visualizzazione richieste pull nella scheda Mine .

Screenshot della scheda Personalizza richiesta pull nella scheda Mine.

Consenti alle estensioni di aggiungere l'evidenziazione della sintassi e il completamento automatico

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

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

Un esempio di estensione che illustra questa funzionalità è disponibile qui.

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

Punto di estensione per la creazione del repository

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

Screenshot che mostra l'estensione per la creazione del repository.

Supporto migliorato per la codifica

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

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

Screenshot che mostra un avviso che indica che sono stati aggiunti caratteri non ASCII. Il commit codifica il file come Unicode.

Go get command support in Azure Repos

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

Pipelines

Editor Web con IntelliSense per le pipeline YAML

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

Screenshot che mostra gli errori di sintassi evidenziati.

Assistente attività per la modifica di file YAML

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

Breve video che illustra come usare l'Assistente attività per modificare i file YAML.

Attivare pipeline YAML con tag

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

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

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

Dichiarare le risorse del contenitore inline

In precedenza, è necessario dichiarare le risorse del contenitore nelle pipeline YAML, quindi farvi riferimento in base al nome. È ora disponibile una sintassi inline per i casi in cui non si farà riferimento più volte al contenitore.

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

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

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

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

Scegliere la directory del codice estratto nelle pipeline YAML

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

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

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

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

Nuove attività Servizio app di Azure ottimizzate per YAML

Sono ora supportate quattro nuove attività che offrono un modo semplice e potente per distribuire i servizi app Azure tenendo presente gli sviluppatori moderni. Queste attività hanno una sintassi YAML ottimizzata che semplifica e intuitivo la creazione di distribuzioni in AppService di Azure, tra cui WebApps, FunctionApps, WebApps for Containers e FunctionApp for Containers in entrambe le piattaforme Windows e Linux.

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

Modifiche alle autorizzazioni predefinite per i nuovi progetti

Fino ad ora, i collaboratori del progetto non potevano creare pipeline a meno che non abbiano esplicitamente l'autorizzazione "Crea definizione di compilazione". Per i nuovi progetti, i membri del team possono creare e aggiornare facilmente le pipeline. Questa modifica ridurrà l'attrito per i nuovi clienti che eseguono l'onboarding in Azure Pipelines. È sempre possibile aggiornare le autorizzazioni predefinite per il gruppo Collaboratori e limitare l'accesso.

Gestire le versioni di GitHub usando le pipeline

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

Ecco il file YAML semplice per l'attività:

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

Screenshot della finestra di dialogo Versione gitHub (anteprima).

Una versione gitHub di esempio creata con questa attività:

Screenshot di una versione gitHub di esempio creata con questa attività.

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

Screenshot del file dirs.proj della soluzione di compilazione con una riga del log evidenziata e l'opzione Copia collegamento a questa selezione evidenziata.

Miglioramenti all'autorizzazione delle risorse

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

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

Screenshot che mostra un riepilogo della pipeline con errore di autorizzazione.

Nuovi punti di contributo dell'estensione nella scheda Test pipeline

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

I due punti di contributo sono:

  1. Pulsante Azione personalizzata sulla barra degli strumenti

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

    Screenshot dell'opzione Azione personalizzata.

  2. Scheda Dettagli personalizzati nel riquadro dei dettagli

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

Eseguire una sola volta l'agente

Se si usa un'infrastruttura come Istanze di Azure Container per eseguire agenti privati elastici, spesso si vuole che ogni agente accetti un solo processo prima di uscire. Fino ad ora, questo non è stato facile perché è stato necessario terminare l'agente (probabilmente causando un errore) o accettare il rischio che un agente possa ricevere un altro processo prima di arrestarlo. Con questo aggiornamento è stato aggiunto il flag --once alla configurazione dell'agente. Quando si configura l'agente in questo modo, verrà accettato un solo processo e quindi si arresterà.

Aggiornamento dell'interfaccia utente del pool di agenti

La pagina di gestione dei pool di agenti nelle impostazioni del progetto è stata aggiornata con una nuova interfaccia utente. Ora è possibile visualizzare facilmente tutti i processi in esecuzione in un pool. Inoltre, è possibile imparare perché un processo non è in esecuzione.

Screenshot che mostra un aggiornamento dell'esperienza utente del pool di agenti (UX) di agenti

Distribuire in destinazioni non riuscite in un gruppo di distribuzione

Per impostazione predefinita, Azure Pipelines viene usato per eseguire di nuovo tutti i processi quando si ridistribuisce un'esecuzione precedentemente non riuscita. È ora possibile eseguire l'override di questo comportamento configurando l'opzione di distribuzione durante la distribuzione. Selezionando l'opzione Tutti i processi e limite alle destinazioni non riuscite in un gruppo di distribuzione , la rieseguimento eseguirà tutti i processi e ignorerà le distribuzioni alle destinazioni già aggiornate.

Screenshot che mostra l'opzione Distribuisci selezionata, un errore di test e la sezione Opzione di distribuzione evidenziata.

Ridistribuire automaticamente in caso di errore

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

Screenshot che mostra la finestra di dialogo Condizioni post-distribuzione con la sezione Trigger di ridistribuimento automatico evidenziata.

Hook del servizio Grafana annotazioni

È ora supportato un nuovo hook del servizio che consente di aggiungere annotazioni Grafana per gli eventi Deployment Completed a un dashboard di Grafana. Ciò consente di correlare le distribuzioni con le modifiche apportate alle metriche dell'applicazione o dell'infrastruttura visualizzate in un dashboard di Grafana.

Screenshot del dashboard di Grafana che mostra le modifiche apportate alle metriche.

Eseguire query nelle attività degli avvisi di Monitoraggio di Azure

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

Screenshot che mostra l'anteprima degli avvisi di Monitoraggio di Azure per query.

Input inline del file spec nell'attività Distribuisci in Kubernetes

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

Screenshot che mostra la funzionalità di configurazione inline.

Attività Del programma di installazione dell'interfaccia della riga di comando di Docker

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

Screenshot che mostra l'interfaccia DockerCLI installata.

Ripristinare le pipeline di versione eliminate

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

Screenshot che mostra l'opzione Ripristina per le pipeline.

Notifiche in caso di errore di una richiesta di creazione del rilascio

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

Con questo aggiornamento è stata aggiunta una nuova sottoscrizione di notifica alla categoria Versione . Questa notifica invierà un messaggio di posta elettronica quando una richiesta di creazione di una versione non riesce. Uno scenario di esempio in cui può essere utile è quando una richiesta di creazione di una versione ha esito negativo perché una versione dell'artefatto non è disponibile. Per informazioni su come gestire le notifiche, vedere la documentazione qui.

Screenshot che mostra la Creazione guidata nuova sottoscrizione con la categoria Release evidenziata e l'opzione A request for release creation failed evidenziata.

Pianificare le versioni in caso di modifica dell'origine o della pipeline

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

Screenshot della sezione Trigger di versione pianificata con l'opzione Solo pianificare versioni se l'origine o la pipeline è stata modificata evidenziata.

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

In precedenza, i valori delle variabili necessari durante la creazione del rilascio devono essere immessi dall'utente senza alcuna assistenza o suggerimenti. Sono stati aggiunti punti di contributo alla finestra di dialogo Crea una nuova versione per supportare le estensioni che consentiranno di popolare il valore di una variabile durante la creazione della versione.

Screenshot della finestra di dialogo Crea una nuova versione.

Pubblicare in code di sessione bus di servizio di Azure

È stata estesa l'attività di compilazione del processo senza agente per includere la possibilità di pubblicare messaggi nelle code di sessione. Questa opzione è stata aggiunta all'attività Pubblica in bus di servizio di Azure.

Screenshot dell'attività Pubblica in bus di servizio di Azure.

Nuova opzione di sottoscrizione di Azure nella connessione al servizio Kubernetes

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

Con questo aggiornamento è stata aggiunta un'opzione di autenticazione al modulo di connessione al servizio Kubernetes. È ora possibile selezionare Sottoscrizione di Azure per autenticare la connessione. In questo modo è facile eseguire la distribuzione in spazi dei nomi specifici configurando connessioni Kubernetes con la sottoscrizione di Azure e il nome del cluster.

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

Screenshot della finestra di dialogo Aggiungi una connessione al servizio Kubernetes con l'opzione Sottoscrizione di Azure evidenziata.

Connessione al servizio Registro Azure Container nel servizio Registro Docker

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

Screenshot che mostra come aggiungere una connessione al servizio Docker.

Cercare in base al nome della cartella nelle definizioni di versione

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

Screenshot che mostra le definizioni di versione archiviate nelle cartelle.

Attività del programma di installazione dello strumento Duffle nella pipeline di compilazione e versione

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

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

Screenshot del programma di installazione dello strumento Duffle.

Attività del manifesto Kubernetes

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

  • Sostituzione artefatto: l'azione di distribuzione esegue come input un elenco di immagini del contenitore che possono essere specificate insieme ai tag o ai digest. Questa operazione viene sostituita nella versione non modello dei file manifesto prima di applicarla al cluster per assicurarsi che la versione corretta dell'immagine venga estratta dai nodi del cluster.

  • Stabilità del manifesto: lo stato dell'implementazione viene controllato per gli oggetti Kubernetes distribuiti per incorporare i controlli di stabilità durante il calcolo dello stato dell'attività come esito positivo/negativo.

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

  • Manifesto bake: l'azione di bake dell'attività consente di creare grafici Helm nei file manifesto kubernetes in modo che possano essere applicati al cluster.

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

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

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

Aggiornamenti all'attività Docker

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

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

Programma di installazione dello strumento Kubectl

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

Screenshot che mostra il programma di installazione dello strumento Kubectl.

Miglioramenti all'integrazione di ServiceNow

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

Screenshot che mostra la funzionalità di gestione delle modifiche di ServiceNow.

Supporto per Red Hat Enterprise Linux 6

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

Supporto per il modulo Az di Azure PowerShell

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

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

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

Nota

Se si usano agenti privati, è necessario installare il modulo Az nel computer agente.

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

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

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

Screenshot della finestra di dialogo Azure SQL Distribuzione database con l'opzione a discesa Tipo di autenticazione evidenziata.

Pubblicare artefatti di compilazione con percorsi di file lunghi

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

Ignorare l'integrazione continua (CI) per un commit

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

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

Test Plans

Widget Test result trend (Advanced)

Il widget Test result trend (Advanced) offre visibilità quasi in tempo reale sui dati di test per più compilazioni e versioni. Il widget Trend dei risultati test (Avanzato) visualizza una tendenza dei risultati dei test per le pipeline o tra pipeline. È possibile usarlo per tenere traccia del conteggio giornaliero dei test, della frequenza di superamento e della durata del test. Il rilevamento della qualità dei test nel tempo e il miglioramento del collaterale dei test è fondamentale per mantenere una pipeline DevOps integra.

Screenshot del widget Test Result Trend (Advanced).

Il widget Test result trend (Advanced) consente di trovare outlier nei risultati dei test e rispondere alle domande come: i test richiedono più tempo per l'esecuzione del solito? Quale file di test o pipeline influisce sulla velocità complessiva del passaggio? Quali sono i test a esecuzione prolungata?

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

  • Visualizza una tendenza di frequenza di passaggio e conteggio dei risultati dei test o della durata del test
  • Presenta i risultati dei test basati su più pipeline di compilazione o pipeline di rilascio
  • Usa le opzioni di creazione di grafici combinati per visualizzare due metriche sulla stessa tendenza
  • Filtra il conteggio dei test nel tempo per risultato del test
  • Filtra tutti i risultati del test per ramo o test
  • Esegue lo stack delle metriche in base agli attributi di test, ad esempio Priorità o Ambiente
  • Raggruppare i dati nei file di test, nei proprietari o nelle pipeline

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

Condividere i risultati dell'esecuzione del test tramite URL

È possibile configurare i test automatizzati da eseguire come parte di una compilazione o di una versione. I risultati dei test pubblicati possono essere visualizzati nella scheda Test nella compilazione o nel riepilogo della versione. Con questo aggiornamento è stata aggiunta una funzionalità URL risultati copia , in modo da poter condividere i risultati di una singola esecuzione di test con altri utenti del team.

I livelli di condivisione includono:

  • Livello di esecuzione
  • Livello di risultato
  • Scheda singola selezionata all'interno dell'esecuzione del test
  • La condivisione è anche compatibile con qualsiasi scheda di estensione configurata

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

Artifacts

Pacchetti NuGet con numeri di versione di SemVer 2.0.0

In precedenza, Gli artefatti di Azure non supportavano i pacchetti NuGet con i numeri di versione di SemVer 2.0.0 (in genere, i numeri di versione che contengono la parte dei metadati di compilazione della versione, che è significata da un +). È ora possibile salvare i pacchetti da nuget.org che contengono metadati di compilazione e eseguire il push dei propri pacchetti con metadati di compilazione. Per il criterio SemVer e NuGet.org, i metadati di compilazione non possono essere usati per ordinare i pacchetti. Non è quindi possibile pubblicare entrambi 1.0.0+build1 gli elementi e 1.0.0+build2 in Elementi di Azure (o nuget.org), poiché queste versioni verranno considerate equivalenti e quindi soggette ai vincoli di non modificabilità.

Informazioni sulla provenienza sui pacchetti

Con questo aggiornamento, è stato reso più semplice comprendere la provenienza dei pacchetti: chi o quali sono stati pubblicati e il commit del codice sorgente da cui provengono. Queste informazioni vengono popolate automaticamente per tutti i pacchetti pubblicati usando le attività NuGet, npm, Maven e Twine Authentication (per Python) in Azure Pipelines.

Statistiche sull'utilizzo dei pacchetti

Fino a questo momento, Gli artefatti di Azure non hanno fornito un modo per misurare l'utilizzo o la popolarità dei pacchetti. Con questo aggiornamento è stato aggiunto un conteggio dei download e degli utenti alle pagine dei dettagli del pacchetto e del pacchetto. È possibile visualizzare le statistiche sul lato destro di una pagina.

Screenshot delle statistiche sull'utilizzo del pacchetto.

Supporto per i pacchetti Python

Gli artefatti di Azure possono ora ospitare pacchetti Python: entrambi i pacchetti che si producono e i pacchetti upstream salvati dal pyPI pubblico. Per altre informazioni, vedere il post di blog dell'annuncio e la documentazione.

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

Screenshot che mostra tutti i pacchetti ospitati nello stesso feed.

Origini upstream per Maven

Le origini upstream sono ora disponibili per i feed Maven. Ciò include il repository Maven Central primario e i feed di Artefatti di Azure. Per aggiungere maven upstream a un feed esistente, visitare Impostazioni feed, selezionare il pivot origini upstream e quindi selezionare Aggiungi origine upstream.

Screenshot che mostra l'opzione Aggiungi origine upstream.

Fino ad ora, molte attività di compilazione correlate agli artefatti non hanno fornito supporto completo per l'infrastruttura proxy di Azure Pipelines, che ha portato a problemi usando le attività degli agenti locali. Con questo aggiornamento è stato aggiunto il supporto per i proxy alle attività seguenti:

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

Tutti i tipi di pacchetto artefatti supportati nelle versioni

Fino a questo momento, solo i pacchetti NuGet sono stati supportati nel tipo di artefatto di Artefatti di Azure nelle versioni di Pipelines. Con questo aggiornamento, sono supportati tutti i tipi di pacchetto di Elementi di Azure , Maven, npm e Python.

Visualizzazioni degli artefatti supportate nelle versioni

In precedenza, il tipo di artefatto di Azure Artifacts potrebbe attivare solo quando sono state pubblicate nuove versioni del pacchetto nel feed. A questo punto, è stato aggiunto anche il supporto per le visualizzazioni, quindi è possibile attivare le versioni quando i pacchetti già presenti nel feed vengono promossi a una visualizzazione.

I criteri di conservazione possono ignorare i pacchetti scaricati di recente

Fino a questo momento, i feed di Artefatti di Azure hanno offerto criteri di conservazione di base che iniziano a eliminare le versioni precedenti del pacchetto quando è stato raggiunto un "numero massimo di versioni per pacchetto". Con questo aggiornamento è stata aggiunta la possibilità di ignorare i pacchetti scaricati di recente quando si esegue questa pulizia. Per abilitare, modificare il feed e selezionare la casella di controllo Ignora pacchetti scaricati di recente .

Delegare chi può gestire i feed

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

Wiki

Modelli markdown per formule e video

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

Screenshot che mostra il menu di scelta rapida espanso con le opzioni seguenti: Sommario, Video, Tag YAML e Formule.

Incorpora Azure Boards risultati della query in Wiki

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

Screenshot dei risultati delle query Azure Boards incorporati visualizzati nel wiki.

I risultati della query possono essere aggiunti in due passaggi:

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

Screenshot che mostra il menu di scelta rapida espanso con l'opzione Risultati query chiamata.

  1. Selezionare la query necessaria e fare clic sul pulsante "Inserisci".

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

Screenshot della finestra di dialogo Risultati query.

Carattere monospaced per l'editor Wiki Markdown

Con l'introduzione dei tipi di carattere monospaced per l'editor wiki Markdown, la leggibilità non è più una sfida. L'origine Markdown è pulita e facile da leggere. Questa funzionalità è stata prioritaria in base a questo ticket di suggerimento.

Screenshot del wiki con carattere monospaced.

Fino a questo momento, i collegamenti alla pagina Wiki condivisa si sono interrotti se la pagina collegata è stata rinominata o spostata. Sono stati ora introdotti collegamenti permanenti aggiungendo id pagina all'URL. Ciò garantisce che i collegamenti condivisi rimangano intatti man mano che il wiki cambia nel tempo.

Questa funzionalità è stata assegnata in ordine di priorità in base a questo ticket di suggerimento.

Visualizzare lo stato dell'elemento di lavoro nelle pagine Wiki

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

Screenshot che mostra le menzioni avanzate degli elementi di lavoro.

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

@mention utenti e gruppi

È ora @mention possibile usare utenti e gruppi in una pagina wiki. Questo rende i documenti come la pagina di contatto di un team, documenti di indicazioni e documenti di conoscenza più completi. L'immagine seguente è un esempio che mostra una retrospettiva sprint con attività e la persona responsabile.

Screenshot che mostra come appare quando si <span class=@mention utenti e gruppi." />

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

Screenshot che mostra le autosuggestions visualizzate quando si inizia a digitare un <span class=@mention." />

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

Notifiche nelle pagine wiki

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

Screenshot di una pagina wiki di Azure DevOps con l'opzione Segui evidenziata.

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

Supporto per i tag HTML

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

  1. È ora possibile creare sezioni compressi all'interno delle pagine wiki usando i dettagli e i tag di riepilogo . È possibile aggiungere l'attributo aperto per mantenere i dettagli espansi per impostazione predefinita.

    Screenshot che mostra le sezioni collapible create con i dettagli e i tag di riepilogo.

    Per altre informazioni sul tag dei dettagli , vedere la documentazione qui.

    Questa impostazione è stata assegnata in ordine di priorità in base a questo ticket di suggerimento.

    Nota

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

Creazione e modifica di tabelle migliorate

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

  1. Creare una tabella dalla griglia

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

    Screenshot che mostra una pagina wiki vuota con l'opzione Formato tabella selezionata.

    Questa funzionalità è stata prioritaria in base ai ticket di suggerimento seguenti:

  2. Migliore leggibilità delle tabelle

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

    Screenshot di una pagina Wiki con l'opzione Ritorno a capo automatico e la barra di scorrimento orizzontale evidenziata.

  3. Formattazione automatica delle tabelle markdown

    Non è più necessario aggiungere spazi per allineare le colonne markdown. Con il pulsante Formatta tabelle , le tabelle markdown vengono formattate automaticamente aggiungendo spazi alle celle per allineare le colonne. Se si dispone di tabelle di grandi dimensioni, usarla con disabilitare il ritorno a capo automatico per semplificare la lettura delle tabelle.

    Screenshot di una pagina Wiki con l'opzione Format tables evidenziata.

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

Creazione di report

L'estensione di Analisi non è più necessaria per usare Analytics

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

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

Ecco come i clienti possono abilitare Analytics:

  1. Passare a Impostazioni raccolta progetti:

Screenshot che mostra dove trovare l'impostazione Analisi.

  1. Fare clic su Abilita analisi

Screenshot che mostra l'opzione Abilita analisi.

Ecco fatto! Le esperienze basate sull'analisi verranno attivate per la raccolta.

Le nuove raccolte create nell'aggiornamento 1 e Azure DevOps Server raccolte 2019 con l'estensione Analytics installata che sono state aggiornate avranno Analytics abilitato per impostazione predefinita.

Per altre informazioni su Analytics e sulle esperienze abilitate:


Commenti e suggerimenti

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


Inizio pagina