Note sulla versione di Team Foundation Server 2018 Update 2
Developer Community | Requisiti di sistema e compatibilità | Condizioni di licenza | Blog TFS DevOps | Hash SHA-1 | | Ultime note sulla versione di Visual Studio 2019
Nota
Se si accede a questa pagina da una versione che non è in lingua inglese e si vuole visualizzare il contenuto più aggiornato, visitare la pagina delle Note sulla versione in inglese. È possibile cambiare la lingua di questa pagina facendo clic sull'icona del globo nel piè di pagina e selezionando la lingua desiderata.
In questo articolo sono disponibili informazioni relative alla versione più recente di Team Foundation Server 2018. Fare clic sul pulsante per continuare.
Per altre informazioni su Team Foundation Server 2018, vedere la pagina e requisiti di compatibilità di Team Foundation Server . Visitare la pagina visualstudio.com/downloads per scaricare altri prodotti TFS 2018.
L'aggiornamento diretto a Team Foundation Server 2018 Update 2 è supportato da TFS 2012 e versioni successive. Se si ha una distribuzione di TFS in TFS 2010 o versioni precedenti, è necessario eseguire alcuni passaggi intermedi prima dell'aggiornamento a TFS 2018 Update 2. Vedere il grafico seguente e la pagina di installazione di TFS per altre informazioni.
Importante
Non è necessario eseguire l'aggiornamento a TFS 2018 RTM prima dell'aggiornamento a TFS 2018 Update 2.
: 7 maggio 2018
È ora possibile eseguire l'aggiornamento a TFS 2018 Update 2 e continuare a connettere i controller XAML ed eseguire compilazioni XAML. Quando è stato rimosso il supporto per la compilazione XAML in TFS 2018 RTW e in Update 1, alcuni utenti non erano in grado di eseguire l'aggiornamento a causa della presenza di compilazioni XAML legacy ed è stato necessario sbloccarli. Anche se TFS 2018 Update 2 supporta le compilazioni XAML per le compilazioni legacy, la compilazione XAML è deprecata e non sono previsti ulteriori investimenti, quindi è consigliabile passare a un formato di definizione di compilazione più recente.
Riepilogo delle novità in TFS 2018 Update 2
In Team Foundation Server 2018 Update 2 è stato aggiunto molto nuovo valore. Tra le caratteristiche principali:
- Visualizzazione del commit di merge della richiesta pull
- Possibilità per i revisori di usare le etichette di richiesta pull
- Aggiunta di una menzione per una richiesta pull
- Le notifiche con commenti sulle richieste pull includono il contesto del thread
- Estendibilità dello stato della richiesta pull
- Filtro per tag e campi personalizzati nelle notifiche relative alla gestione degli elementi di lavoro
- Opzioni modernizzate per le colonne
- Aggiunto il supporto per l'operatore Not In query
- Query for @MyRecentActivity and @RecentMentions
- Applicazione di filtri ai piani
- Attività di controllo per la versione
- Compilazione con integrazione continua da GitHub Enterprise
- Miglioramenti alle compilazioni multifase
- Possibilità di ignorare le compilazioni pianificate se non è cambiato nulla nel repository
- Uso semplificato dei pacchetti pubblici grazie alle origini upstream
- Criteri di conservazione nei feed di TFS
- Applicazione di filtri per la gestione dei pacchetti
- Ricerca nel wiki
- Riferimento agli elementi di lavoro nel wiki
- Visualizzare in anteprima il contenuto durante la modifica delle pagine wiki
- Incollare il contenuto avanzato del wiki come HTML
- Schede del profilo
- Avatar rotondi
Dettagli delle novità in TFS 2018 Update 2
Sono disponibili informazioni dettagliate sulle funzionalità di ogni area:
Codice
Ottenere un collegamento permanente al codice
Quando si visualizza un file in genere la versione appare in corrispondenza dell'estremità del ramo selezionato. La versione del file in corrispondenza dell'estremità può cambiare con i nuovi commit. Se si copia un collegamento da questa visualizzazione, i collegamenti possono risultare non aggiornati perché l'URL include solo il nome del ramo, non l'agente integrità sistema di commit. È ora possibile passare facilmente alla visualizzazione File per aggiornare l'URL in modo che faccia riferimento al commit anziché al ramo. Se si preme il tasto "y", la visualizzazione passa al commit all'estremità del ramo corrente. È quindi possibile copiare i collegamenti permanenti.
Usare l'API per ripristinare un repository eliminato di recente
A volte si possono commettere degli errori quando si puliscono i repository più datati nel controllo del codice sorgente. Se un repository Git viene eliminato entro gli ultimi 30 giorni, può essere recuperato usando l'API REST. Per altre informazioni, vedere la documentazione relativa alle operazioni di elenco e ripristino.
SSH: supporto di crittografie e chiavi aggiuntive e crittografie obsolete deprecate
Per migliorare la sicurezza e la compatibilità, è stato aggiornato l'elenco delle modalità di crittografia supportate per SSH. Sono state aggiunte due crittografie nuove e tre sono state deprecate, in conformità alle indicazioni di OpenSSH. Le crittografie deprecate continuano a funzionare in questa versione. Verranno rimosse in futuro non appena diminuisce l'utilizzo.
Aggiunte:
- AES128 CTR
- AES256 CTR
Deprecate:
- AES128
- AES192
- AES256
Evitare le sovrascritture e proteggere le prestazioni con le impostazioni repository
In questo aggiornamento sono disponibili due nuove impostazioni repository che consentono di eseguire Git senza problemi.
Imposizione maiuscole/minuscole fa passare il server dalla modalità di distinzione tra maiuscole e minuscole predefinita, in cui "File.txt" e "file.txt" si riferiscono allo stesso file, a una modalità compatibile con Windows e macOS in cui "File.txt" e "file.txt" sono lo stesso file. Questa impostazione interessa file, cartelle, rami e tag. Impedisce inoltre ai collaboratori di introdurre accidentalmente differenze dovute solo all'uso di maiuscole o minuscole. L'abilitazione dell' imposizione di maiuscole/minuscole è consigliata se la maggior parte dei collaboratori usa Windows o macOS.
Limite dimensioni file consente di evitare che i file nuovi o aggiornati superino un limite impostato per le dimensioni. Più numerosi sono i file di grandi dimensioni nella cronologia di un repository Git, peggiori diventano le prestazioni delle operazioni di clonazione e recupero. Questa impostazione impedisce la l'introduzione accidentale di questi file.
Funzionalità di filtro ottimizzata per i commit con più di 1000 file modificati
La ricerca di un file nei commit o nelle richieste pull in cui sono stati modificati più di 1000 file non era efficiente: per trovare il file era necessario fare clic più volte sul collegamento Carica altro. Ora, quando si filtra il contenuto nella visualizzazione struttura ad albero, la ricerca del file viene eseguita in tutti i file nel commit anziché solo nei primi 1000 file caricati. Le prestazioni della pagina dei dettagli del commit risultano migliori anche se sono presenti più di 1000 file modificati.
Trovare commit persi a causa di un push forzato
È possibile eseguire un push forzato Git e aggiornare un riferimento remoto anche se non è un predecessore del riferimento locale. Ciò può causare la perdita di commit per altri utenti e può essere molto difficile identificare la causa principale. Nella nuova visualizzazione i push forzati sono stati messi in evidenza in modo da consentire la risoluzione dei problemi correlati ai commit mancanti.
Se si fa clic sul tag del push forzato viene visualizzato il commit rimosso.
Cronologia disponibile per Segnala errore
La visualizzazione Segnala errore è molto utile per identificare l'ultima persona che ha modificato una riga di codice. Tuttavia, a volte è necessario sapere chi ha apportato la modifica precedente a una riga di codice. Per questo è stata introdotta l'opzione Visualizza la segnalazione errore prima di questo commit. Come suggerisce il nome, questa funzionalità consente di tornare indietro nel tempo fino alla versione del file precedente alla versione in cui è stata modificata una determinata riga e visualizzare le informazioni relative alla segnalazione della modifica per quella versione. È possibile continuare a tornare indietro nel tempo esaminando ogni versione del file in cui è stata modificata la riga di codice selezionata.
Attivare e disattivare il ritorno a capo automatico e gli spazi nelle visualizzazioni delle differenze
Nel visualizzatore delle differenze dei file sono disponibili due nuove funzionalità: Attiva/Disattiva ritorno a capo automatico e Attiva/Disattiva spazio vuoto. La prima consente di applicare l'impostazione del ritorno a capo automatico in una visualizzazione delle differenze. Risulta particolarmente utile per la revisione di richieste pull che contengono file senza interruzioni di riga frequenti, ad esempio i file markdown. L'opzione di attivazione e disattivazione dello spazio vuoto è utile quando cambiano solo gli spazi vuoti in una riga o un file. Attivare e disattivare questa impostazione consente di visualizzare ed evidenziare nelle differenze i caratteri di spazio vuoto, ad esempio punti per gli spazi, frecce per le tabulazioni e così via.
Per gestire queste impostazioni, fare clic sull'icona a forma di ingranaggio delle preferenze per l'editor nell'editor delle richieste pull o nella visualizzazione delle differenze. Nella visualizzazione File selezionare l'opzione Preferenze utente dal menu di scelta rapida.
Selezionare le diverse funzionalità dell'editor tra cui Mostra spazi vuoti e controlla differenze, Abilita ritorno a capo automatico, Abilita riduzione del codice e Mostra mini mappa.
La riduzione del codice, detta "struttura" in alcuni editor, viene abilitata anche per la visualizzazione Web. Se la riduzione del codice è abilitata, fare clic su segni meno per comprimere le sezioni del codice o sui segni più per espandere le sezioni compresse. Il riquadro comandi F1 espone anche le opzioni per la riduzione di vari livelli di rientro in un intero file, semplificando la lettura e la revisione dei file di grandi dimensioni.
Tenere traccia dei push del codice a un repository Git per build e versioni
Ora è possibile visualizzare lo stato di build e versioni dei commit di merge nella pagina Push. Facendo clic sullo stato accanto al push, verrà visualizzata la build o versione specifica in cui è incluso il push in modo da poter verificare se l'esito è positivo o analizzare l'errore.
Rendering del markdown nelle notifiche di posta elettronica
Il markdown è molto utile per l'aggiunta di formattazione avanzata, collegamenti e immagini nelle descrizioni e nei commenti delle richieste pull. Nelle notifiche di posta elettronica per le richieste pull ora è visualizzato il markdown sottoposto a rendering anziché il contenuto non elaborato e questo migliora la leggibilità.
Il rendering delle immagini inline non viene ancora eseguito inline (appaiono solo come collegamenti), ma nel backlog è previsto di aggiungere questa azione in futuro.
Eseguire i comandi di TFVC direttamente da Esplora risorse
L'estensione della shell di Windows TFVC, che offre un'esperienza lightweight di controllo della versione integrata in Esplora File di Windows, supporta ora TFS 2018. Questo strumento consente di accedere facilmente a molti comandi di TFVC direttamente nel menu di scelta rapida di Esplora risorse.
Incluso in precedenza in TFS Power Tools, lo strumento è stato rilasciato come strumento autonomo in Visual Studio Marketplace.
Decidere chi può contribuire alle richieste pull
In precedenza chiunque fosse in grado di visualizzare un repository Git poteva usarne le richieste pull. È stata aggiunta una nuova autorizzazione, Aggiunta di contributi alle richieste pull, che controlla l'accesso alla creazione delle richieste pull e all'inserimento dei relativi commenti. Per impostazione predefinita, questa nuova autorizzazione viene concessa a tutti gli utenti e i gruppi che in precedenza avevano l'autorizzazione Lettura. L'introduzione di questa nuova autorizzazione offre un livello superiore di flessibilità e controllo agli amministratori. Se il gruppo Lettori deve necessariamente essere di sola lettura, è possibile negare l'autorizzazione Aggiunta di contributi alle richieste pull.
Per altre informazioni, vedere la guida introduttiva all'impostazione delle autorizzazioni del repository.
Le notifiche con commenti sulle richieste pull includono il contesto del thread
In molti casi le risposte ai commenti delle richieste pull sono piuttosto brevi, si limitano a confermare che è stata o verrà apportata una modifica. Questo non è un problema quando si visualizzano i commenti nella visualizzazione Web, ma se si legge un commento in una notifica via posta elettronica, il contesto del commento originale viene perso. Un semplice "Verrà risolto" non ha alcun significato.
Ora, ogni volta che si risponde a un commento di richiesta pull, i messaggi di posta elettronica con i commenti includono le risposte precedenti nel corpo del messaggio. In questo modo i partecipanti al thread possono esaminare il contesto completo del commento direttamente dalla posta in arrivo, senza dover aprire la visualizzazione Web.
Impostazioni per il completamento degli elementi di lavoro
Per la funzionalità che consente di completare gli elementi di lavoro quando si completano le richieste pull è ora disponibile una nuova impostazione del repository che controlla il comportamento predefinito. La nuova impostazione Memorizzare le preferenze degli utenti per il completamento degli elementi di lavoro con le richieste pull è abilitata per impostazione predefinita e rispetta l'ultimo stato dell'utente per completare le future richieste pull nel repository. Se la nuova impostazione è disabilitata, l'opzione Completa gli elementi di lavoro collegati dopo il merge viene disabilitata per impostazione predefinita per tutte le richieste pull nel repository. Gli utenti possono comunque scegliere di effettuare la transizione degli elementi di lavoro collegati durante il completamento delle richieste pull, ma dovranno acconsentire esplicitamente ogni volta.
Estendibilità dello stato della richiesta pull
L'uso dei criteri ramo può essere un ottimo modo per migliorare la qualità del codice. Questi criteri, tuttavia, sono stati limitati alle sole integrazioni native di Team Foundation Server. Usando la nuova API di stato della richiesta pull e i criteri ramo corrispondenti, i servizi di terze parti possono partecipare al flusso di lavoro della richiesta pull proprio come le funzionalità native di Team Foundation Server.
Quando un servizio esegue un post nell'API di stato per una richiesta pull, viene visualizzato immediatamente nella visualizzazione dei dettagli della richiesta pull in una nuova sezione Stato. La sezione stato mostra la descrizione e crea un collegamento all'URL fornito dal servizio. Le voci di stato supportano anche un menu azione (...) estendibile per le nuove azioni aggiunte alle estensioni Web.
Il solo stato non blocca il completamento di una richiesta pull, che è dove vengono inseriti i criteri. Dopo che lo stato della richiesta pull è stato pullicato, è possibile configurare i criteri. Dall'esperienza dei criteri ramo sono disponibili nuovi criteri per richiedere l'approvazione di servizi esterni. Selezionare + Aggiungi servizio per avviare il processo.
Nella finestra di dialogo selezionare il servizio che pubblica lo stato dall'elenco e selezionare le opzioni per i criteri desiderate.
Quando i criteri sono attivi, lo stato viene mostrato nella sezione Criteri in Obbligatorio o Facoltativo secondo le esigenze e il completamento della richiesta pull viene applicata correttamente.
Per altre informazioni sull'API di stato e per provarla, consultare la documentazione e gli esempi.
Hook del servizio richiesta pull ed eventi di merge
Le estensioni che usano gli hook del servizio richiesta pull includono ora più dettagli e opzioni di filtro per gli eventi di merge. Ogni volta che si tenta di eseguire un merge, l'evento viene generato indipendentemente dall'esito positivo o negativo dell'operazione. Quando un tentativo di merge genera un errore, vengono inclusi i dettagli relativi al motivo dell'errore.
Messaggi di errore ottimizzati per il completamento degli elementi di lavoro con una richiesta pull
Quando si tenta di completare gli elementi di lavoro con una richiesta pull, la transizione dell'elemento di lavoro associato allo stato completato può non essere possibile. Ad esempio, può essere necessario un campo specifico che richiede l'input dell'utente per consentire la transizione dello stato. L'esperienza è stata migliorata in modo da informare l'utente quando qualcosa blocca la transizione dell'elemento di lavoro, consentendo di intervenire per apportare le modifiche necessarie.
Aggiunta di una menzione per una richiesta pull
È ora possibile menzionare le richieste pull nei commenti delle richieste e nelle discussioni relative agli elementi di lavoro. La procedura di aggiunta di una menzione per una richiesta pull è simile a quella usata per un elemento di lavoro, ma prevede l'uso di un punto esclamativo ! anziché un di segno hash #.
Ogni volta che si vuole menzionare una richiesta pull, basta immettere un ! per visualizzare un'esperienza interattiva che consente di selezionare una richiesta pull da un elenco di richieste recenti. Immettere le parole chiave per filtrare l'elenco di suggerimenti oppure immettere l'ID della richiesta pull da menzionare. Dopo l'aggiunta della menzione, la richiesta pull viene visualizzata inline con l'ID e il titolo completo e viene collegata alla pagina dei dettagli della richiesta.
Consentire ai revisori di usare le etichette di richiesta pull
A volte è importante comunicare ai revisori informazioni aggiuntive su una richiesta pull. La richiesta pull può essere un lavoro in corso o un hotfix per una versione futura, quindi si aggiunge altro testo nel titolo, ad esempio un prefisso "[WIP]" o "DO NOT MERGE". Le etichette ora consentono di contrassegnare le richieste pull con informazioni aggiuntive che possono essere usate per comunicare informazioni importanti e ottimizzare l'organizzazione delle richieste pull.
I commenti della richiesta pull seguono i file rinominati
In alcuni casi i file vengono rinominati o spostati mentre è attiva una richiesta pull. In precedenza, se erano presenti commenti sui file rinominati, non apparivano nella visualizzazione più recente del codice. Il rilevamento dei commenti è stato ottimizzato in modo da seguire le ridenominazioni, visualizzando commenti sulla versione più recente dei file rinominati o spostati.
Visualizzare il commit di merge della richiesta pull
Le visualizzazioni delle differenze tra le richieste pull sono molto utili per evidenziare le modifiche introdotte nel ramo di origine. Tuttavia, a causa delle modifiche apportate al ramo di destinazione le differenze possono essere visualizzate in modo diverso dal previsto. Ora è disponibile un nuovo comando che consente di visualizzare le differenze del commit di merge di "anteprima" per la richiesta pull: Visualizza commit di merge. Il commit di merge viene creato per verificare la presenza di conflitti di merge ed essere usato con una build di richiesta pull e riflette l'aspetto che ha il commit di merge al termine della richiesta pull. Quando il ramo di destinazione contiene modifiche non evidenziate nelle differenze, la visualizzazione delle differenze del commit di merge può essere utile per vedere le modifiche più recenti nei rami di origine e di destinazione.
Un altro comando che risulta utile in combinazione con il comando Visualizza commit di merge è Riavvia merge (disponibile nello stesso menu di comandi). Se il ramo di destinazione è stato modificato dal momento in cui è stata creata la richiesta pull, l'esecuzione di questo comando crea un nuovo commit di merge di anteprima, aggiornando la visualizzazione delle differenze del commit di merge.
Revisori usati di recente
Se il codice viene spesso rivisto dalle stesse persone, sarà più facile che mai aggiungere i revisori. Quando si aggiungono i revisori alle richieste pull, un elenco dei revisori aggiunti di recente viene automaticamente visualizzato quando lo stato attivo si trova nella casella di input dei revisori: non è necessario eseguire la ricerca in base al nome. Selezionarli come si farebbe con qualsiasi revisore.
Visualizzare i criteri rimanenti per il completamento automatico della richiesta pull
Il completamento automatico è una funzionalità utile per i team che usano criteri dei rami, ma quando si usano criteri facoltativi può non essere chiara la causa che impedisce il completamento di una richiesta pull. Ora, quando si imposta il completamento automatico per una richiesta pull, nella casella del callout appare l'elenco esatto dei criteri che impediscono il completamento. Man mano che ogni requisito viene soddisfatto, gli elementi vengono rimossi dall'elenco finché non vi sono altri requisiti e la richiesta pull viene sottoposta a merge.
Discutere matematiche nelle richieste pull
Può essere necessario includere un'equazione o un'espressione matematica nei commenti della richiesta pull. Ora è possibile includere funzioni KaTeX nei commenti, usando l'inserimento di commenti sia inline che in blocco. Per altre informazioni, vedere l'elenco delle funzioni supportate.
Suggerimenti di richieste pull per i fork
Ogni volta che un ramo a tema viene aggiornato in un repository, viene visualizzato un "suggerimento" per la creazione di una nuova richiesta pull per il ramo. Questa opzione è molto utile per la creazione di nuove richieste pull ed è stata abilitata anche per gli utenti che lavorano con un repository di tipo fork. Se si aggiorna un ramo in un fork, la volta successiva che si visita l'hub Codice per il fork o il repository upstream, verrà visualizzato il suggerimento per creare una richiesta pull. Se si seleziona il collegamento "Crea una richiesta pull", si verrà indirizzati all'esperienza di creazione della richiesta pull, con i rami e i repository di origine e di destinazione già selezionati.
Filtri dei percorsi per i criteri di richiesta pull
Spesso un unico repository contiene codice compilato da più pipeline di integrazione continua (CI) per convalidare la build ed eseguire i test. I criteri di compilazione integrata ora supportano un'opzione di filtro dei percorsi che semplifica la configurazione di più compilazioni di richieste pull che possono essere richieste e attivate automaticamente per ogni richiesta pull. Specificare un percorso per ogni compilazione da richiedere e impostare le opzioni relative a trigger e requisito in base alle esigenze.
Oltre alla compilazione, l'opzione di filtro dei percorsi è disponibile anche per i criteri di stato. Ciò consente a tutti i criteri personalizzati o di terze parti di configurare l'applicazione dei criteri per percorsi specifici.
Lavoro
Tasti di scelta rapida nel form elementi di lavoro
È possibile assegnare un elemento di lavoro a se stessi (ALT + i), passare alla discussione (CTRL + ALT + d) e copiare un collegamento rapido all'elemento di lavoro (MAIUSC + ALT + c) usando i tasti di scelta rapida. Per l'elenco completo dei nuovi tasti di scelta rapida, digitare "?" con un form elemento di lavoro aperto oppure vedere la tabella seguente.
Opzioni modernizzate per le colonne
La finestra di dialogo Opzioni colonne usata per configurare le colonne della griglia elemento di lavoro negli hub Backlog, Queries e Test hub è stata aggiornata per consentire l'uso di una nuova struttura di pannelli. È possibile eseguire una ricerca per trovare un campo, trascinare e rilasciare le colonne per riordinarle o rimuovere le colonne esistenti che non sono più necessarie.
Ultima esecuzione di una query in base alle informazioni
Man mano che l'albero delle query condivise del progetto cresce, può essere difficile determinare se una query non viene più usata e può essere eliminata. Per agevolare la gestione delle query condivise, sono state aggiunte due nuove parti di metadati alle API REST di query, l'autore dell'ultima esecuzione e la data dell'ultima esecuzione, in modo che sia possibile scrivere script di pulizia per eliminare le query non aggiornate.
Tag HTML rimossi nelle griglie elemento di lavoro
In base ai commenti e suggerimenti dei clienti, è stato aggiornato il comportamento dei campi di testo multilinea nelle visualizzazioni dei risultati delle query degli elementi di lavoro sul Web, in Excel e nell'IDE di Visual Studio per rimuovere la formattazione HTML. Se aggiunti come colonna alla query, i campi di testo multilinea ora vengono visualizzati come testo normale. Di seguito è riportato un esempio di una funzionalità con HTML nella descrizione.
In precedenza i risultati della query avrebbero avuto questo aspetto: <div><b><u>Customer Value</u>...
Aggiunto il supporto per l'operatore Not In query
I campi che supportano l'operatore query "In" ora supportano "Not In". Si possono scrivere query per elementi di lavoro "non in" un elenco di ID, "non in" un elenco di stati e altro ancora, tutto senza dover creare molte clausole "Or" nidificate.
Query per @MyRecentActivity e @RecentMentions
Abbiamo introdotto due nuove macro di query per il campo ID per semplificare la ricerca degli elementi di lavoro che possono essere importanti per l'utente. Vedere gli elementi menzionati negli ultimi 30 giorni usando @RecentMentions o esaminare gli elementi di lavoro visualizzati o modificati di recente usando @MyRecentActivity.
Filtro per tag e campi personalizzati nelle notifiche relative alla gestione degli elementi di lavoro
Le notifiche possono ora essere definite usando condizioni per tag e campi personalizzati, non solo quando vengono modificati, ma anche quando sono soddisfatti determinati valori. È così disponibile un set di notifiche più completo da impostare per gli elementi di lavoro.
Verifica delle menzioni dalla pagina Elementi di lavoro personali
È stato aggiunto un nuovo pivot Con menzione sotto la pagina Elementi di lavoro personali. All'interno di questo pivot è possibile esaminare gli elementi di lavoro in cui si è stati menzionati negli ultimi 30 giorni. Con questa nuova visualizzazione è possibile intervenire rapidamente sugli elementi che richiedono l'input dell'utente ed essere sempre aggiornati riguardo alle conversazioni più pertinenti.
Questo stesso pivot è disponibile anche sui dispositivi mobili, favorendo la coerenza tra l'esperienza desktop e quella mobile.
Applicazione di filtri ai piani
L'estensione Piani di recapito ora usa il componente di filtro comune ed è coerente con le applicazioni di filtri di griglia a elementi di lavoro e lavagne. Il controllo dei filtri offre una migliore usabilità e un'interfaccia coerente a tutti i membri del team.
Navigazione nei piani aggiornati
Molti utenti usano i preferiti per accedere rapidamente al contenuto di un piano o un set di piani che ritengono particolarmente importante. Per prima cosa, l'hub Plans è stato aggiornato in modo che sia possibile passare al piano visitato più di recente anziché alla pagina della directory. Secondo, quando si è nel piano, è possibile usare il selettore dei preferiti per passare rapidamente a un altro piano o usare la barra di navigazione per tornare alla pagina della directory.
Espandere e comprimere requisiti e persone sulla lavagna delle attività
È ora possibile espandere o comprimere tutti gli elementi presenti sulla lavagna delle attività sprint con un semplice clic.
Concedere l'autorizzazione bypassrule a utenti specifici
Spesso, durante la migrazione degli elementi di lavoro da un'altra origine, le organizzazioni vogliono conservare tutte le proprietà originali dell'elemento di lavoro. Ad esempio, può essere necessario creare un bug che mantiene la data di creazione originale e viene creato in base ai valori del sistema in cui ha avuto origine.
L'API di aggiornamento di un elemento di lavoro ha un flag bypassrule che consente di abilitare tale scenario. In precedenza l'identità che ha effettuato la richiesta API doveva essere un membro del gruppo Project Collection Administrators. È stata aggiunta un'autorizzazione a livello di progetto per eseguire l'API con il flag bypassrule.
Compilare e rilasciare
Compilazioni XAML
In Team Fouldation Server 2015 è stato introdotto un sistema di compilazione multipiattaforma basata sul Web. Le compilazioni XAML non sono supportate in TFS 2018 RTW o Update 1, ma sono state nuovamente abilitate in TFS 2018 Update 2. È consigliabile eseguire la migrazione alle compilazioni XAML.
Quando si esegue l'aggiornamento a TFS 2018 Update 2:
Se sono disponibili dati di compilazioni XAML nella raccolta di progetti team, un avviso segnala la deprecazione delle funzionalità di compilazione XAML.
È necessario usare Visual Studio o Team Explorer 2017 per modificare le definizioni di compilazione XAML o per accodare nuove compilazioni XAML.
Se è necessario creare nuovi agenti di compilazione XAML, devono essere installati usando il programma di installazione dell'agente di compilazione TFS 2015.
Per una spiegazione di questo piano di deprecazione della compilazione XAML, vedere il post di blog relativo all'evoluzione delle funzionalità di automazione della compilazione TFS/Team Services.
Miglioramenti alle compilazioni multifase
È stato possibile usare le fasi per organizzare i passaggi della compilazione e impostare come destinazione diversi agenti che usano richieste diverse per ogni fase. Sono state aggiunte numerose funzionalità per compilare le fasi in modo che ora sia possibile:
Specificare una coda agente diversa per ogni fase. Ciò significa che è possibile, ad esempio:
- Eseguire una fase di una compilazione su un agente macOS e un'altra fase su un agente Windows. Per una dimostrazione dell'utilità di questo tipo di utilizzo, vedere questo video su Connect(); 2017: CI/CD DevOps Pipeline for mobile apps and services (Pipeline CI/CD DevOps per servizi e app per dispositivi mobili).
- Eseguire le istruzioni di compilazione in un pool di agenti di compilazione e testare i passaggi in un pool di agenti di test.
Eseguire test più rapidamente grazie all'esecuzione in parallelo. Qualsiasi fase con parallelismo configurato come "Multi-agent" che contiene un'attività "VSTest" ora parallelizza automaticamente l'esecuzione dei test per il numero di agenti configurati.
Consentire o negare agli script di accedere al token OAuth ad ogni fase. Ciò significa, ad esempio, che ora è possibile consentire agli script in esecuzione nella fase di compilazione di comunicare con Visual Studio Team Services attraverso le API REST e nella stessa definizione di compilazione bloccare gli script in esecuzione nella fase di test.
Eseguire una fase solo in determinate condizioni. Ad esempio, è possibile configurare una fase per l'esecuzione solo quando vengono completate le fasi precedenti o si compila codice nel ramo principale.
Per altre informazioni, vedere Phases in Build and Release Management (Fasi nella gestione di compilazioni e rilasci).
Ignorare le compilazioni pianificate se non è cambiato nulla nel repository
A grande richiesta è ora possibile specificare che una compilazione pianificata non venga eseguita se non è cambiato nulla nel codice. È possibile controllare questo comportamento applicando l'opzione alla pianificazione. Per impostazione predefinita, non verrà pianificata una nuova compilazione se l'ultima compilazione pianificata (della stessa pianificazione) è trascorsa e non sono state archiviate ulteriori modifiche nel repository.
Compilazione con integrazione continua da GitHub Enterprise
Ora è disponibile una migliore integrazione per l'esecuzione di compilazioni con integrazione continua (CI) se si usa GitHub Enterprise per il controllo della versione. In precedenza, era solo possibile eseguire il polling per le modifiche del codice usando il connettore GIT esterno, che può aumentare il carico sui server e causare ritardi prima dell'attivazione delle compilazioni. Ora, con il supporto ufficiale GitHub Enterprise, le compilazioni CI del team vengono immediatamente attivate. Inoltre, la connessione può essere configurata usando vari metodi di autenticazione, ad esempio LDAP o gli account predefiniti.
I file protetti possono essere scaricati negli agenti durante la compilazione o il rilascio
La nuova attività Scarica file protetto supporta il download (nei computer agente) dei file crittografati dalla libreria dei file protetti di VSTS. Quando viene scaricato, il file viene decrittografato e archiviato nel disco dell'agente. Al termine della compilazione o del rilascio, il file viene eliminato dall'agente. In questo modo in fase di compilazione o di rilascio è possibile usare file riservati, ad esempio i certificati o le chiavi private, che altrimenti sono crittografati e archiviati in modo sicuro in VSTS. Per altre informazioni, vedere la documentazione relativa alla protezione dei file.
Possibilità di installare i profili di provisioning Apple dai repository di origine
L'attività Installa profilo di provisioning Apple supporta già l'installazione (su computer agente) dei profili di provisioning archiviati nella libreria dei file protetti di VSTS. I profili di provisioning vengono usati da Xcode per firmare e inserire nei pacchetti le app Apple, ad esempio per iOS, macOS, tvOS e watchOS. Ora i profili di provisioning si possono installare dai repository di codice sorgente. Anche se è consigliabile usare la libreria di file protetti per garantire una maggiore protezione dei file, questo miglioramento riguarda i profili di provisioning già archiviati nel controllo del codice sorgente.
Tracciare le origini di GitHub alle build con i tag di compilazione
Le compilazioni eseguite da GitHub o GitHub Enterprise sono sempre collegate al relativo commit. È altrettanto importante essere in grado di tracciare un commit in modo da poter risalire alle compilazioni che lo hanno generato. Ora questo è possibile abilitando l'aggiunta di tag all'origine in TFS. Quando si sceglie il repository GitHub in una definizione di compilazione, selezionare i tipi di compilazione a cui si vuole aggiungere un tag e il formato del tag.
Osservare quindi come vengono visualizzati i tag di compilazione nel repository GitHub o GitHub Enterprise.
Possibilità di installare Java Development Kit (JDK) specifici durante le compilazioni e i rilasci
Per la compilazione di determinati progetti Java, possono essere necessari JDK specifici che non sono disponibili nei computer agente. I progetti, ad esempio, possono richiedere versioni diverse o precedenti di JDK IBM, Oracle o open source. L'attività Programma di installazione strumento Java scarica e installa il JDK necessario dal progetto durante una compilazione o un rilascio. La variabile di ambiente JAVA_HOME viene impostata di conseguenza per la durata della compilazione o del rilascio. Sono disponibili JDK specifici per il programma di installazione dello strumento Java usando una condivisione file, un repository di codice sorgente o l'archiviazione BLOB di Azure.
Ottimizzata la configurazione della build con Xcode
L'attività Xcode è stata aggiornata con una nuova versione principale (4.*) che migliora la configurazione di compilazione, test e creazione di pacchetti di Xcode. Se il progetto Xcode ha un unico schema condiviso, viene usato automaticamente. È stata aggiunta un'ulteriore guida in linea. Le funzionalità deprecate, ad esempio la creazione di pacchetti xcrun, sono state rimosse dalle proprietà dell'attività Xcode. Le definizioni esistenti di build e versione devono essere modificate in modo da usare la versione 4.* più recente dell'attività Xcode. Per le nuove definizioni, se sono necessarie funzionalità deprecate della versione precedente dell'attività Xcode, è possibile selezionare tale versione nella propria definizione.
Attività di controllo per la versione
Il monitoraggio continuo è parte integrante delle pipeline DevOps. Garantire l'integrità dell'app in una versione dopo la distribuzione è essenziale quanto il successo del processo di distribuzione. Le aziende hanno adottato vari strumenti per il rilevamento automatico dello stato dell'applicazione nell'ambiente di produzione e per tenere traccia degli imprevisti segnalati dai clienti. Finora i responsabili dell'approvazione dovevano monitorare manualmente l'integrità delle app di tutti i sistemi prima di promuovere il rilascio. Tuttavia, la gestione del rilascio ora consente di integrare il monitoraggio continuo nelle pipeline di versione. Usare questa opzione per garantire che il sistema esegua ripetutamente query su tutti i segnali di integrità dell'app finché non indicano tutti contemporaneamente un esito positivo, prima di procedere con il rilascio.
Iniziare con la definizione di attività di controllo precedenti e successive alla distribuzione nella definizione di versione. Ogni attività di controllo consente di monitorare uno o più segnali di integrità corrispondenti a un sistema di monitoraggio dell'app. Sono disponibili attività di controllo predefinite per gli avvisi di Monitoraggio di Azure (Application Insights) e per gli elementi di lavoro. È possibile integrare le attività con altri sistemi grazie alla flessibilità offerta dalle funzioni di Azure.
Durante la fase di esecuzione, in Rilascio vengono avviati il campionamento di tutte le attività di controllo e la raccolta dei relativi segnali di integrità. Il campionamento viene ripetuto a ogni intervallo fino a quando i segnali raccolti da tutti i controlli nello stesso intervallo hanno esito positivo.
I primi campioni generati dai sistemi di monitoraggio possono non essere accurati, poiché non sono disponibili informazioni sufficienti per la nuova distribuzione. L'opzione "Ritardo prima della valutazione" garantisce che il rilascio non proceda durante questo periodo, anche se tutti i campioni hanno esito positivo.
Durante il campionamento delle attività di controllo non vengono usati né agenti né pipeline. Per altre informazioni, vedere la documentazione relativa alle attività di controllo per la versione.
Distribuzione selettiva in base all'artefatto che attiva una versione
È possibile aggiungere più origini artefatto a una definizione di versione e configurarle per attivare una versione. Una nuova versione viene creata quando è disponibile una nuova build per una delle origini. Lo stesso processo di distribuzione viene eseguito indipendentemente dall'origine che ha attivato la versione. È ora possibile personalizzare il processo di distribuzione in base all'origine di attivazione. Per le versioni attivate automaticamente, la variabile di versione Release.TriggeringArtifact.Alias viene ora popolata per identificare l'origine artefatto che ha attivato la versione. Questo elemento può essere usato in condizioni di attività, condizioni di fase e parametri di attività per modificare dinamicamente il processo. Ad esempio, nel caso in cui sia solo necessario distribuire gli artefatti modificati nei vari ambienti.
Gestire la protezione specifica di un'entità
Per la protezione basata sui ruoli, in precedenza i ruoli di accesso di protezione venivano impostati per un utente o un gruppo a livello di hub per i gruppi di distribuzione, i gruppi di variabili, le code agente e gli endpoint servizio. Ora è possibile attivare e disattivare l'ereditarietà per una particolare entità in modo da poter configurare la protezione nel modo più adeguato.
Approvare più ambienti
La gestione delle approvazioni per le versioni ora è più semplice. Per le pipeline con lo stesso responsabile approvazione per più ambienti con distribuzione in parallelo, il responsabile attualmente deve agire separatamente per ogni approvazione. Con questa funzionalità è ora possibile completare più approvazioni in sospeso nello stesso momento.
Estendibilità del modello versione
I modelli versione consentono di creare una baseline da cui partire per definire un processo di rilascio. In precedenza, i nuovi modelli potevano essere caricati nell'account, ma ora gli autori possono includere i modelli versione nelle proprie estensioni. È disponibile un esempio nel repository GitHub.
Fasi e attività di rilascio condizionale
Analogamente alle attività di compilazione condizionale, è ora possibile eseguire un'attività o una fase solo se sono soddisfatte determinate condizioni. Ciò può essere utile nella modellazione di scenari di ripristino dello stato precedente.
Se le condizioni predefinite non soddisfano le proprie esigenze o è necessario un controllo con granularità più fine sui tempi di esecuzione dell'attività o della fase, è possibile specificare condizioni personalizzate. Esprimere la condizione come set di funzioni nidificato. L'agente valuta la funzione più interna e procede verso l'esterno. Il risultato finale è un valore booleano che determina se l'attività deve essere eseguita.
Cronologia delle richieste per gli endpoint servizio
Gli endpoint servizio consentono alla connessione ai servizi esterni e remoti di eseguire attività per una compilazione o una distribuzione. Gli endpoint sono configurati nell'ambito del progetto e condivisi tra più definizioni di compilazione e versione. I proprietari degli endpoint servizio ora possono ottenere una visualizzazione consolidata di compilazioni e distribuzioni usando un endpoint, che contribuisce a migliorare il controllo e la governance.
Le proprietà predefinite per i tipi di artefatti Git e GitHub sono ora modificabili
È ora possibile modificare le proprietà predefinite dei tipi di artefatti Git e GitHub anche dopo il collegamento degli artefatti. Questo è particolarmente utile negli scenari in cui il ramo per la versione stabile dell'artefatto è stato modificato e i futuri rilasci con recapito continuo devono usare questo ramo per ottenere le versioni più recenti dell'artefatto.
Distribuire manualmente in blocco gli ambienti dalla visualizzazione versione
Ora è possibile attivare manualmente un'azione di distribuzione in più ambienti di una versione allo stesso tempo. Ciò consente di selezionare più ambienti in una versione con configurazioni o implementazioni non riuscite ed eseguire di nuovo la distribuzione a tutti gli ambienti in un'unica operazione.
Supporto pipeline Jenkins a più rami e supporta e collegamento dei processi organizzati in cartelle
L'uso dei progetti da Jenkins è stato ulteriormente ottimizzato.
In primo luogo, ora è possibile usare i progetti di pipeline Jenkins a più rami come origini artefatto in una definizione di versione.
Secondo, mentre in precedenza i progetti Jenkins si potevano collegare come artefatti solo dalla cartella radice di un server Jenkins, ora possono essere usati quando sono organizzati a livello di cartella. L'elenco dei progetti Jenkins, insieme ai percorsi di cartella, sono visualizzati nell'elenco delle origini da cui si seleziona il progetto da usare come origine artefatto.
Uso del Registro Azure Container o Hub Docker come origine artefatto
Questa funzionalità consente alle versioni di usare le immagini archiviate in un registro dell'Hub Docker o un Registro Azure Container. Si tratta del primo passo verso il supporto per diversi scenari, ad esempio l'implementazione di nuove modifiche area per area usando la funzionalità di replica geografica del Registro Azure Container o la distribuzione in un ambiente, ad esempio la produzione, da un registro contenitori che include immagini solo per l'ambiente di produzione.
È ora possibile configurare l'Hub Docker o il Registro Azure Container come artefatto di prima classe nell'esperienza + Aggiungi dell'artefatto di una definizione di versione. Per il momento la versione deve essere attivata manualmente o da un altro artefatto ma si prevede di aggiungere presto un trigger basato sul push di una nuova immagine al registro.
Versioni predefinite degli artefatti
Sono ora disponibili diverse opzioni versione predefinite quando si collegano artefatti di controllo della versione a una definizione di versione. È possibile configurare un commit o un insieme di modifiche specifico o semplicemente configurare la versione più recente da selezionare dal ramo predefinito. Di solito la configurazione si esegue per la versione più recente, ma risulta particolarmente utile in alcuni ambienti in cui è necessario specificare la versione finale di un artefatto per tutte le distribuzioni continue future.
Miglioramenti del ramo dei trigger di versione
È ora possibile configurare un filtro dei trigger di versione basato sul ramo predefinito specificato nella definizione di compilazione. Ciò è particolarmente utile se il ramo di compilazione predefinito cambia ad ogni sprint ed è necessario aggiornare i filtri dei trigger di versione in tutte le definizioni di versione. Ora è sufficiente modificare il ramo predefinito nella definizione di compilazione e tutte le definizioni di versione usano automaticamente questo ramo. Ad esempio, se il team crea rami della versione per ogni payload di versione sprint, aggiornarlo nella definizione di compilazione in modo che punti a un nuovo ramo della versione sprint e la versione lo seleziona automaticamente.
Trigger di versione per un artefatto di gestione pacchetti
Ora è possibile impostare un trigger per un artefatto di gestione pacchetti in una definizione di versione in modo che venga creata automaticamente una nuova versione quando viene pubblicata una nuova versione del pacchetto. Per altre informazioni, vedere la documentazione relativa all'uso dei trigger nella gestione del rilascio.
Definire ambienti specifici come ambito di un gruppo di variabili
In precedenza, quando si aggiungeva un gruppo di variabili a una definizione di versione, le variabili del gruppo erano disponibili per tutti gli ambienti della versione. A questo punto, si ha la flessibilità necessaria per possibile definire l'ambito dei gruppi di variabili per ambienti specifici. Questo rende i gruppi disponibili per un ambiente ma non per altri ambienti della stessa versione. Ciò è molto utile quando si usa un servizio esterno, ad esempio un servizio di posta elettronica SMTP, che varia da un ambiente all'altro.
Rilascio automatico dal Registro Azure Container e Hub Docker
Quando si distribuiscono app incluse in contenitori, l'immagine del contenitore viene prima inserita con push in un registro contenitori. Completato il push, l'immagine del contenitore può essere distribuita a un'app Web per contenitori o a un cluster Kubernetes. È ora possibile abilitare la creazione automatica delle versioni per gli aggiornamenti delle immagini memorizzate nell'Hub Docker o nel Registro Azure Container aggiungendole come origine artefatto.
Specificare una versione predefinita per gli artefatti Jenkins
Quando una versione con più artefatti viene attivata automaticamente, le versioni predefinite salvate nella definizione di versione vengono selezionate per tutti gli artefatti. In precedenza, gli artefatti Jenkins non avevano un'impostazione di versione predefinita e pertanto non era possibile impostare un trigger di distribuzione continua per una versione con Jenkins come artefatto secondario.
Ora è possibile specificare una versione predefinita per gli artefatti Jenkins, con le opzioni con cui si ha più dimestichezza:
- Ultima versione
- Specifica durante la creazione della versione
- Versione specifica
Contributo di attività di controllo per la versione dalle estensioni
Le attività di controllo per la versione consentono di aggiungere approvazioni basate sulle informazioni alle pipeline di versione. Un set di segnali di integrità vengono raccolti ripetutamente prima o dopo la distribuzione per determinare se il rilascio deve passare o meno alla fase successiva. Viene messo a disposizione un set di controlli predefiniti e "Richiama funzione di Azure" è stato finora consigliato come mezzo per l'integrazione con altri servizi. La route per l'integrazione con altri servizi viene semplificata e vengono aggiunte attività di controllo attraverso le estensioni del Marketplace. È ora possibile contribuire alle attività di controllo personalizzate e offrire agli autori delle definizioni di versione un'esperienza avanzata per configurare tali attività.
Sono disponibili altre informazioni sulla creazione di attività di controllo.
Distribuzioni su larga scala in macchine virtuali usando i gruppi di distribuzione
I gruppi di distribuzione, che supportano la distribuzione affidabile e predefinita su più computer, sono ora una funzionalità disponibile a livello generale. Con i gruppi di distribuzione è possibile orchestrare le distribuzioni su più server ed eseguire aggiornamenti in sequenza, assicurando la disponibilità elevata dell'applicazione. È anche possibile effettuare le distribuzioni in server locali o in macchine virtuali in Azure o in qualsiasi cloud e avere la tracciabilità completa delle versioni degli artefatti distribuiti fino al livello del server.
La funzionalità di distribuzione basata su agenti si basa sugli stessi agenti di compilazione e distribuzione già disponibili. È possibile usare il catalogo attività completo nei computer di destinazione nella fase Gruppo di destinazione. Dal punto di vista dell'estendibilità, è anche possibile usare le API REST per i gruppi di distribuzione e le destinazioni per l'accesso a livello di codice.
Pacchetto
Uso semplificato dei pacchetti pubblici con le origini upstream
Sono ora disponibili origini upstream per nuget.org e npmjs.com. I vantaggi includono la possibilità di gestire (rimuovere dall'elenco, deprecare, annullare la pubblicazione, eliminare e così via) i pacchetti salvati dalle origini upstream nonché il salvataggio garantito di ogni pacchetto upstream in uso.
Criteri di conservazione nei feed di TFS
Finora i feed per i pacchetti TFS non offrivano alcun modo per pulire automaticamente le versioni precedenti e non usate dei pacchetti. Per chi pubblica pacchetti di frequente ciò può comportare una maggiore lentezza delle query sui feed in Gestione pacchetti NuGet e in altri client finché non vengono eliminate manualmente alcune versioni.
Sono stati ora abilitati criteri di conservazione per i feed di TFS. I criteri di conservazione eliminano automaticamente la versione meno recente di un pacchetto quando viene raggiunta la soglia di conservazione. I pacchetti promossi a visualizzazioni vengono conservati per un periodo illimitato, offrendo la possibilità di proteggere le versioni usate nell'ambiente di produzione o ampiamente in tutta l'organizzazione.
Per abilitare i criteri di conservazione, modificare il feed e immettere un valore in Numero massimo di versioni per pacchetto nella sezione Criteri di conservazione.
Applicazione di filtri per la gestione dei pacchetti
La pagina Pacchetti è stata aggiornata in modo da usare il layout di pagina standard, il controllo della barra dei comandi e la nuova barra del filtro standard.
Condividere i pacchetti usando una notifica
Nella community open source è diffuso l'uso di una notifica per collegarsi alla versione più recente del pacchetto nel file Leggimi del repository. È ora possibile creare le notifiche per i pacchetti presenti nei feed. Selezionare l'opzione Abilitare le notifiche pacchetto nelle impostazioni del feed, selezionare un pacchetto e quindi fare clic su Crea notifica. È possibile copiare l'URL della notifica direttamente o copiare il Markdown pregenerato che collega la notifica alla pagina dei dettagli del pacchetto.
Le versioni precedenti del pacchetto ora sono un elenco a pagina intera
Gli utenti hanno inviato una grande quantità di commenti e suggerimenti sull'esperienza di Gestione pacchetti aggiornata, in cui l'elenco delle versioni precedenti del pacchetto è stato spostato in un selettore di navigazione nella pagina dei dettagli del pacchetto. È stato aggiunto un nuovo pivot Versioni che offre maggiori informazioni sulle versioni precedenti e rende più semplice copiare il numero di versione o ottenere un collegamento a una versione precedente.
Visualizzare la qualità di una versione pacchetto nell'elenco di pacchetti
Nell'elenco di pacchetti ora appaiono le visualizzazioni di ogni versione pacchetto di cui è possibile determinare rapidamente la qualità. Per altre informazioni, vedere la documentazione relativa alle visualizzazioni versione .
Gulp, Yarn e supporto feed con autenticazione
L'attività npm oggi funziona perfettamente con i feed npm autenticati (in Gestione pacchetti o registri esterni come npm Enterprise e Artifactory), ma finora è stato difficile usare uno strumento di esecuzione attività, ad esempio Gulp, o un client npm alternativo, ad esempio Yarn, a meno che l'attività non supportasse anche i feed con autenticazione. È stata aggiunta una nuova attività di compilazione npm Authenticate, che aggiunge le credenziali al file NPMRC in modo che le attività successive possano usare correttamente i feed con autenticazione.
Le autorizzazioni predefinite del feed per il pacchetto ora includono Amministratori progetto
In precedenza, se un utente creava un feed veniva automaticamente impostato come unico proprietario del feed, con possibili conseguenze negative a livello di amministrazione nelle organizzazioni di grandi dimensioni, se tale utente passava a un altro team o lasciava l'organizzazione. Per rimuovere questo singolo punto di guasto, il processo di creazione di un feed ora usa il contesto del progetto corrente dell'utente per ottenere il gruppo Amministratori progetto e trasformarlo a sua volta in un proprietario del feed. Come con qualsiasi autorizzazione, è possibile rimuovere il gruppo e personalizzare ulteriormente le autorizzazioni del feed usando la finestra di dialogo delle impostazioni del feed.
Riciclare e ripristinare i pacchetti
L'eliminazione dei pacchetti non usati consente di mantenere pulito l'elenco dei pacchetti, ma in alcuni casi viene eseguita per errore. Ora è possibile ripristinare i pacchetti eliminati dal Cestino. I pacchetti eliminati rimangono nel Cestino 30 giorni, un tempo più che sufficiente per eseguire il ripristino, se necessario.
Collegare i pacchetti da qualsiasi posizione
Benché in passato fosse possibile condividere l'URL a un pacchetto incluso nell'hub Packages, spesso era difficile usarlo poiché era necessario includere un progetto nell'URL e questa operazione non riguardava necessariamente tutti coloro che usavano il collegamento. Con questo aggiornamento, è ora possibile condividere i pacchetti usando un URL che seleziona automaticamente un progetto a cui ha accesso il destinatario.
Il formato URL è: 'https://< TFSserverURL>/_packaging?feed=feed>=<feed&package=<package>&version=version>&protocolType<=<NuGet|Npm|Maven>&_a=package'
Tutti i parametri tranne '<TFSserverURL>' sono facoltativi, ma se si specifica un pacchetto, è necessario specificare il tipo di protocollo.Test
L'attività Test di Visual Studio non ha bisogno di Visual Studio completo
L'attività Test di Visual Studio in fase di compilazione o rilascio richiede Visual Studio nell'agente per eseguire i test. Anziché installare Visual Studio per eseguire i test negli ambienti di produzione o distribuire semplicemente i test in più agenti, usare la nuova attività Programma di installazione della piattaforma di test di Visual Studio. Questa attività acquisisce la piattaforma di test da nuget.org e la aggiunge alla cache degli strumenti. L'attività di programma di installazione soddisfa la richiesta di vstest e una successiva attività Test di Visual Studio presente nella definizione può essere eseguita senza che sia necessaria un'installazione completa di Visual Studio nell'agente.
Aggiungere l'attività di programma di installazione nella definizione dal catalogo delle attività.
Configurare l'attività Test di Visual Studio successiva in modo da usare i bit acquisiti usando il programma di installazione.
Nota
Limitazioni attualmente il pacchetto della piattaforma di test in NuGet non supporta l'esecuzione di test codificati dell'interfaccia utente. L'abilitazione del supporto per i test codificati dell'interfaccia utente è nel backlog. Il pacchetto di piattaforma di test di NuGet è multipiattaforma, ma l'attività VSTest attualmente non supporta l'esecuzione dei test di base di .NET. Per eseguire i test di base di .NET, usare l'attività "punto net".
Deprecate le attività Esegui test funzionali e Distribuisci agente di test
L'anno scorso è stato avviato un processo di unificazione degli agenti in build, versione e test. L'obiettivo era risolvere diversi punti deboli associati all'uso delle attività Distribuisci agente di test ed Esegui test funzionali di Gestione remota Windows. Ora è possibile usare l'attività Test di Visual Studio (VSTest) per tutte le esigenze di test, tra cui:
- Unit test
- Test funzionali (interfaccia utente/non interfaccia utente)
- Test basati su MSTest
- Test basati su framework di terze parti
- Specifica dei test basati su assembly o esecuzione di test con piano di test o gruppo di test
- Esecuzione di test in un solo agente e distribuzione di test in più agenti
L'approccio con agenti unificati consente inoltre agli amministratori di gestire tutti i computer usati per CI/CD in modo uniforme.
Sono stati messi a punto diversi aspetti cruciali per abilitare questa funzionalità, tra cui:
- Gli agenti possono essere configurati per i test dell'interfaccia utente
- Il programma di installazione della piattaforma di test di Visual Studio consente l'esecuzione dell'attività VSTest senza che sia necessario installare prima Visual Studio
- Le definizioni di compilazione e di versione possono essere entrambe create con più fasi e sono in grado di usare diverse code agente per ogni fase
- I test case automatizzati possono essere eseguiti dall'hub di test usando l'attività VSTest
Avendo a disposizione tutti gli elementi elencati sopra, ora è possibile deprecare queste due attività. Anche se le definizioni esistenti che usano le attività deprecate continueranno a funzionare, si consiglia di passare all'uso di VSTest per sfruttare i vantaggi offerti dai continui miglioramenti apportati nel tempo.
Filtrare i risultati dei test di grandi dimensioni
Nel tempo le risorse usate per i test si accumulano e le applicazioni di grandi dimensioni possono facilmente arrivare a includere migliaia di test. I team cercano di individuare i modi migliori per spostarsi tra set di risultati dei test di grandi dimensioni per essere produttivi e allo stesso tempo identificare gli errori dei test, le cause radice associate o la proprietà dei problemi. A tale scopo, sono stati aggiunti tre nuovi filtri nella scheda Test in Compilazione e versione: Nome test, Contenitore (DLL) e Proprietario (proprietario del contenitore).
Il filtro Risultato esistente, inoltre, offre ora la possibilità di filtrare per più risultati. I vari criteri di filtro sono per natural cumulativi. Quando un utente vuole visualizzare il risultato del test per una modifica di cui è appena stato eseguito il commit, può filtrare in base a Contenitore (nome della DLL), Proprietario (proprietario della DLL), Nome test o in base a tutti questi criteri, per ottenere risultati rilevanti.
Identificare i test non attendibili
A volte i test non sono affidabili, hanno esito negativo durante un'esecuzione e passano a quella successiva senza alcuna modifica. I test non attendibili possono causare frustrazione e scarsa fiducia nell'efficacia dei test, gli errori vengono ignorati e i bug non vengono risolti. Con questo aggiornamento è stata sviluppata la prima parte di una soluzione che consente di affrontare il problema dei test non affidabili. È ora possibile configurare l'attività Test di Visual Studio in modo da eseguire nuovamente i test non superati. I risultati del test indicano quindi quali test inizialmente non sono riusciti e successivamente sono stati di nuovo eseguiti. Il supporto per la nuova esecuzione dei test ordinati e basati sui dati sarà disponibile più avanti.
L'attività Test di Visual Studio può essere configurata in modo da controllare il numero massimo di tentativi per eseguire di nuovo i test non superati e una percentuale di soglia per gli errori (ad esempio, rieseguire i test solo se meno del 20% di tutti i test non è riuscito) per evitare di eseguire di nuovo i test in caso di errori molto diffusi.
Nella scheda Test in Compilazione e versione è possibile filtrare i risultati del test con risultato "Superati dopo nuova esecuzione" per identificare i test che hanno avuto un comportamento non affidabile durante l'esecuzione. In questo modo attualmente viene visualizzato l'ultimo tentativo per ogni test superato con la nuova esecuzione. Anche la visualizzazione di riepilogo è stata modificata e ora appare "Superati dopo nuova esecuzione (n/m)" in Totale test, dove n è il numero di test superati con la nuova esecuzione e m è il numero totale di test superati. Una visualizzazione gerarchica di tutti i tentativi sarà disponibile tra pochi sprint.
Visualizzare in anteprima i miglioramenti e il supporto per diversi tipi di log generati dall'attività Test di Visual Studio
L'attività VSTest è stata ottimizzata in modo da pubblicare i log generati da tipi diversi di istruzioni di registrazione corrispondenti all'output standard e all'errore standard per i test non superati. Anche l'esperienza di anteprima è stata migliorata in modo da supportare la visualizzazione dei formati di testo e file di log, con funzionalità di ricerca nei file di log.
Wiki
Ricerca nel wiki
È possibile eseguire la ricerca delle pagine wiki preferite in base al titolo o al contenuto insieme al codice e agli elementi di lavoro. Altre informazioni sulla ricerca nel wiki sono disponibili nel blog Microsoft DevOps.
Stampa delle pagine wiki
Il wiki può essere usato per una varietà di contenuti. In alcuni casi può essere utile stampare il contenuto dal wiki per leggerlo nel tempo libero, aggiungere commenti usando carta e penna o persino condividere una copia PDF offline con le persone esterne al progetto di Visual Studio Team Services. Ora è sufficiente fare clic sul menu di scelta rapida di una pagina e selezionare Stampa pagina.
Nota
Attualmente questa funzionalità non è supportata in Firefox.
Contribuire facilmente alle pagine wiki usando i tasti di scelta rapida
È ora possibile usare i tasti di scelta rapida per eseguire azioni di visualizzazione e modifica comuni nel wiki ancora più rapidamente usando solo la tastiera.
Mentre si visualizza una pagina, è possibile aggiungere, modificare o creare una pagina secondaria, ad esempio:
Mentre si modifica una pagina è possibile salvare, salvare e chiudere o semplicemente chiudere rapidamente la pagina.
Questi tasti si aggiungono alle scelte rapide di modifica standard, ad esempio CTRL+B per il grassetto, CTRL+I per il corsivo, CTRL+K per il collegamento e così via. Per altre informazioni, vedere l'elenco completo dei tasti di scelta rapida.
Rendering avanzato del markdown nel markdown del repository di codice
È ora possibile creare file README.MD complessi nei repository di codice. Il rendering del markdown dei file MD nei repository di codice ora supporta tag HTML, blocco tra virgolette, Emoji, ridimensionamento delle immagini e formule matematiche. Esiste parità per il rendering del markdown nei file wiki e MD nel codice.
Il wiki supporta le formule matematiche
Se l'applicazione gestisce formule matematiche ed equazioni, è ora possibile inserirle nel wiki usando il formato LaTex.
Riferimento agli elementi di lavoro nel wiki
È ora possibile fare riferimento a elementi di lavoro nelle pagine wiki premendo il tasto "#" per ottenere un elenco degli elementi di lavoro usati più di recente e selezionando l'elemento di lavoro che interessa. Questo è particolarmente utile quando si scrivono note sulla versione, epiche, specifiche o altre pagine che richiedono il riferimento a un elemento di lavoro.
Collegare elementi di lavoro e pagine wiki
È ora possibile collegare un elemento di lavoro a una pagina wiki e viceversa. È possibile collegare gli elementi di lavoro al wiki per creare pagine di epiche, note sulla versione e contenuto di pianificazione utili per tenere traccia degli elementi di lavoro associati a una pagina wiki e convalidare la percentuale di pagine di epiche completata.
Gli elementi di lavoro collegati vengono quindi visualizzati nella pagina wiki.
Aggiungere un collegamento a una pagina wiki da un elemento di lavoro usando il nuovo tipo di collegamento "Pagina wiki".
CTRL+S per salvare la pagina wiki
Gli utenti chiedevano un modo più rapido e semplice per salvare una pagina wiki. Ora possono semplicemente usare i tasti di scelta rapida Ctrl+S per salvare una pagina con un messaggio di revisione predefinito e continuare ad apportare modifiche. Per aggiungere un messaggio di revisione personalizzato, fare clic sulla freccia di espansione accanto al pulsante di salvataggio.
Incollare il contenuto avanzato del wiki come HTML
È ora possibile incollare testo RTF nell'editor di markdown del wiki da tutte le applicazioni basate su browser, ad esempio Confluence, OneNote, SharePoint e MediaWiki. Questo è particolarmente utile per gli utenti che hanno creato contenuto avanzato, ad esempio tabelle complesse, e vogliono visualizzarlo nel wiki. È sufficiente copiare il contenuto e incollarlo come HTML.
Spostare una pagina del wiki usando la tastiera
In precedenza, gli utenti del wiki non potevano riordinare le pagine né assegnare nuovi elementi padre usando la tastiera e questo influiva negativamente sugli utenti che preferiscono eseguire le operazioni dalla tastiera. Ora è possibile riordinare le pagine usando i comandi CTRL+Freccia SU o CTRL+Freccia GIÙ. È anche possibile riassegnare elementi padre alle pagine facendo clic su Sposta pagina nel menu di scelta rapida di una pagina e selezionare la nuova pagina padre da spostare.
Filtrare l'evidenziazione del testo
Applicando un filtro al riquadro di spostamento del wiki viene visualizzata l'intera gerarchia delle pagine. Ad esempio, se si filtra una pagina intitolata "foobar", il riquadro di spostamento filtrato visualizza anche tutte le pagine padre. Ciò può provocare confusione sul perché le pagine non intitolate "foobar" appaiono nel set filtrato di risultati. Ora il filtro del contenuto nel wiki evidenzia il testo da cercare in modo da sapere con precisione quali titoli vengono filtrati e quali no.
Un comportamento simile si può notare anche in tutti i riquadri di spostamento nel codice. Ad esempio, nel riquadro di spostamento tra i file in richieste pull, commit, insiemi di modifiche e shelveset.
Visualizzare in anteprima il contenuto durante la modifica delle pagine wiki
I dati indicano che gli utenti quasi sempre visualizzano più volte in anteprima una pagina wiki mentre modificano il contenuto. Per ogni modifica della pagina, gli utenti fanno clic su Anteprima in media 1 o 2 volte. Questo comporta un'esperienza di modifica lenta e non ottimale, che può richiedere molto tempo soprattutto per chi non ha familiarità con il markdown. Ora è possibile visualizzare l'anteprima della pagina durante la modifica.
Generale
Schede del profilo
Esistono più aree in TFS in cui vengono visualizzate informazioni associate a un utente specifico, che includono, tra l'altro, richieste pull create da un singolo utente ed elementi di lavoro assegnati a un singolo utente. Tuttavia, le informazioni sull'utente sono limitate e non consentono di ottenere il contesto completo. La nuova scheda del profilo sostituisce la scheda già esistente in TFS. La scheda del profilo aggiornata consente di interagire con altri utenti e ottenere altre informazioni sugli stessi all'interno dell'account TFS. Attraverso le integrazioni con il client di posta elettronica e messaggistica immediata predefinito, gli utenti di Active Directory possono inviare messaggi di posta elettronica e avviare le chat direttamente dalla scheda del profilo. Gli utenti di Active Directory possono anche visualizzare la gerarchia dell'organizzazione all'interno della scheda del profilo. Le schede del profilo possono essere attivate dalla home page del progetto, dalle sezioni di membri del team, controllo della versione, elementi di lavoro e wiki facendo clic sull'icona della scheda contatto, sull'immagine del profilo o sui nomi degli utenti nei commenti.
Avatar rotondi
Gli avatar rotondi sono ora disponibili. Tutte le immagini del profilo nel servizio vengono ora visualizzate in una forma circolare anziché quadrata. Ad esempio, di seguito è riportata la richiesta pull effettiva per questa modifica (notare gli avatar rotondi, non quadrati).
Tag del progetto
È ora possibile aggiungere ai progetti le parole chiave importanti (tag). I tag possono essere facilmente aggiunti ed eliminati direttamente dalla home page del progetto (dagli amministratori), consentendo agli utenti di acquisire rapidamente più informazioni sulle finalità e l'ambito del progetto. Sono previste altre modalità di utilizzo dei tag di progetto. Attendere le relative comunicazioni nel prossimo futuro.
Riordinare i gruppi preferiti
È ora possibile riordinare i gruppi nella pagina Preferiti dell'account usando le frecce SU e GIÙ in ogni intestazione di gruppo.
Feedback e suggerimenti
Le opinioni dei nostri clienti sono molto importanti per noi. È possibile segnalare un problema e tenerne traccia tramite la community degli sviluppatori per suggerimenti sull'overflow dello stack.