Note sulla versione di Team Foundation Server 2018
Developer Community Requisiti | disistema e condizioni | di licenza di compatibilità | TFS DevOps | Blog SHA-1 Hashes | Latest Visual Studio 2019 Releases Notes (Note sulle versioni più recenti 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.
Questo articolo contiene informazioni relative a Team Foundation Server 2018. Fare clic sul pulsante per continuare.
Per altre informazioni su Team Foundation Server 2018, vedere la pagina ). Visitare la pagina visualstudio.com/downloads per scaricare altri prodotti TFS 2018.
Vedere la pagina di installazione di TFS per altre informazioni.
di rilascio delle note sulla versione: 15 novembre 2017
Riepilogo delle novità in TFS 2018
In Team Foundation Server 2018 sono state aggiunte numerose nuove funzionalità. Tra le caratteristiche principali:
- Sono stati apportati miglioramenti alla Creazione guidata progetto e Gestione modelli di processo sul Web.
- Ora è possibile personalizzare l'intestazione del form elemento di lavoro.
- È stato ottimizzato il form elemento di lavoro per dispositivi mobili.
- È stato aggiunto il supporto per i fork Git.
- È possibile gestire grandi repository Git con GVFS.
- È possibile visualizzare, filtrare, eliminare e impostare la sicurezza dei tag Git.
- Sono state aggiunte alla modifica del codice Web mini mappe dei file, corrispondenza tra parentesi graffe e attivazione/disattivazione degli spazi vuoti.
- Sono stati apportati numerosi miglioramenti alle richieste pull.
- È disponibile una nuova esperienza Wiki migliorata.
- È stato aggiunto il supporto per i pacchetti Maven.
- È possibile importare ed esportare e sospendere le definizioni di compilazione.
- La nuova versione dell'Editor di definizione prevede il consenso esplicito per impostazione predefinita.
- Sono supportate distribuzioni di macchine virtuali.
- È stata migliorata la tracciabilità del testing esplorativo.
- È stata aggiunta l'organizzazione dei test in batch.
- Ora è possibile visualizzare un widget dei grafici per piani di test e gruppi di test.
Video delle novità in TFS 2018
Compilazione XAML
In origine la compilazione XAML era inclusa tra le funzionalità rimosse da TFS 2018 RTW e Update 1. Tuttavia un numero eccessivo di clienti non riusciva a eseguire l'aggiornamento o doveva contattare il supporto tecnico per abilitare nuovamente la funzionalità dopo l'aggiornamento. In TFS 2018 Update 2 la compilazione XAML è abilitata, ma è stata deprecata. Ciò significa che la compilazione XAML non verrà sviluppata ulteriormente e che Microsoft Test Manager (MTM) non supporta più l'uso delle compilazioni XAML. È consigliabile passare a uno dei formati di definizione di compilazione più recenti. È possibile continuare a connettere i controller XAML ed eseguire compilazioni XAML con TFS 2018 Update 2. Altre informazioni
Funzionalità rimosse in TFS 2018 RTW
- È stato rimosso il supporto per Centro Lab e flussi di test automatizzati in Microsoft Test Manager.
- È stata sospesa l'estensione TFS per SharePoint.
- È stata rimossa la funzionalità Chat team.
Dettagli delle novità in TFS 2018
Rilevamento elementi di lavoro
Creazione guidata progetto sul Web
È stata migliorata l'esperienza per la creazione di un progetto team da Accesso Web. È ora inclusa la maggior parte delle funzionalità disponibili quando si crea un progetto team nel client di Visual Studio. Il vantaggio di usare l'interfaccia Web è che non è necessaria una versione corrispondente di Visual Studio. La differenza tra l'uso di Visual Studio o della versione Web consiste nel fatto che la versione Web non esegue il provisioning dei report in SSRS. Se si utilizza la versione Web della creazione del progetto team, è possibile eseguire il comando tfsconfig a livello applicazione per eseguire il provisioning o aggiornare i report SSRS.
Gestione modelli di processo sul Web
Con TFS 2018 è possibile utilizzare l'accesso Web per caricare i modelli di processo. L'interfaccia Web offre un'esperienza più semplice perché non è necessario installare la versione corretta di Visual Studio per interagire con i modelli di processo. Nell'aggiornamento 4 di Visual Studio 2017 e nei precedenti viene ancora visualizzata la finestra di dialogo Gestione modelli di processo anche se è consigliabile utilizzare l'interfaccia web. A partire dall'aggiornamento 5 di Visual Studio 2017 l'utente viene reindirizzato automaticamente al Web.
Personalizzare l'intestazione del modulo dell'elemento di lavoro
Ora è possibile personalizzare l'area dell'intestazione del form elemento di lavoro sostituendo i controlli esistenti o nascondendo i controlli che non sono rilevanti per il processo. Questa funzionalità consente di sostituire il percorso Area con un campo Team personalizzato, di nascondere Iterazione se i team sono più propensi all'uso di Kanban e di sostituire Motivo con un campo personalizzato. Il campo Stato non può essere nascosto o sostituito.
Suggerimento
Per altre informazioni vedere la documentazione per gli elementi WebLayout e Control.
Modulo dell'elemento di lavoro per dispositivi mobili
È disponibile un'esperienza end-to-end completa che include un aspetto ottimizzato per gli elementi di lavoro (Figura 1) . Offre un modo semplice per interagire con gli elementi assegnati, che l'utente sta seguendo o ha visitato o modificato di recente dal telefono.
Oltre all'aspetto gradevole, questa esperienza supporta controlli ottimizzati per tutti i tipi di campo (Figura 2) .
Con la nuova navigazione mobile (figura 3) gli utenti possono raggiungere qualsiasi altra parte di TFS pronta per dispositivi mobili e tornare al sito desktop completo nel caso in cui debbano interagire con altri hub.
Filtraggio di backlog, bacheche Kanban, sprint e query
Tutte le esperienze di griglia di rilevamento degli elementi di lavoro (query, backlog, lavagne Kanban, backlog sprint e gestione di test case) fanno ora uso del componente di filtro comune e coerente (Figura 4) . Oltre ad applicare un filtro di parole chiave sulle colonne visualizzate e selezionare tag, è anche possibile filtrare tipi di elementi di lavoro, stati e assegnazioni per ottenere rapidamente gli elementi di lavoro cercati.
Espandere per visualizzare i campi vuoti in una scheda Kanban
Oggi è possibile aggiungere campi aggiuntivi a una scheda e quindi nascondere i campi vuoti(Figura 5) nelle impostazioni della scheda per rimuovere il disordine non necessario dalla scheda. Lo svantaggio di questa funzionalità è il fatto che se si desidera aggiornare un campo che è stato nascosto, è necessario aprire il form elemento di lavoro. Con la nuova opzione di espansione disponibile nelle schede Kanban, è possibile nascondere i campi vuoti sulla bacheca e utilizzare l'accesso con un solo clic per aggiornare un campo specifico in una scheda. È sufficiente passare il mouse sulla scheda e cercare la freccia di espansione rivolta verso il basso nella parte inferiore della scheda per aggiornare il campo nascosto.
Fare clic sulla freccia giù nella parte inferiore della scheda per aggiornare il campo (figura 6).
Blocco del salvataggio dell'elemento di lavoro con le estensioni
Controlli personalizzati, gruppi e pagine del form elemento di lavoro possono ora bloccare il salvataggio dell'elemento di lavoro per convalidare i dati e assicurare che l'utente compili eventuali informazioni obbligatorie prima di salvare il form elemento di lavoro.
Aggiunta inline ai piani di recapito
Le nuove idee sulle funzionalità possono arrivare in qualsiasi momento, quindi è stato più semplice aggiungere nuove funzionalità direttamente ai piani di recapito(figura 7). È sufficiente fare clic sul pulsante Nuovo elemento visualizzato al passaggio del mouse, immettere un nome e premere INVIO. Viene creata una nuova funzionalità con il percorso di area e il percorso di iterazione previsti.
Controllo della versione
Fork
TFS 2018 offre il supporto dei fork Git (Figura 8) . Un fork è una copia lato server di un repository. Tramite i fork, è possibile consentire a un'ampia varietà di utenti di contribuire al repository senza dare loro accesso di commit diretto. Gli utenti eseguono invece il commit del lavoro nel proprio fork del repository. In questo modo, si ha la possibilità di esaminare le modifiche in una richiesta pull prima di accettarle nel repository centrale.
GVFS
Ora è supportato Git Virtual File System (GVFS). GVFS consente ai repository Git di scalare fino a milioni di file mediante la virtualizzazione e l'ottimizzazione della modalità di gestione del file system in Git.
Creare una cartella in un repository tramite il Web
Ora è possibile creare cartelle tramite il Web nei repository di Git e del controllo della versione di Team Foundation (figura 9) . Questa impostazione sostituisce l'estensione Folder Management (Gestione cartelle), che verrà gradualmente deprecata.
Per creare una cartella, fare clic su Nuova > cartella nella barra dei comandi o nel menu di scelta rapida:
Per il controllo della versione di Team Foundation sarà necessario specificare un nome della cartella e quindi archiviarla. Per Git, poiché le cartelle vuote non sono consentite, sarà anche necessario specificare un nome di file, eventualmente modificare il file e quindi eseguirne il commit.
Per Git è stata anche migliorata la finestra di dialogo Nuovo file(Figura 10) che ora accetta i caratteri barra rovesciata per la creazione delle sottocartelle.
Mini mappa file
Durante la visualizzazione o la modifica di codice è ora possibile visualizzare una mini mappa di un file, per avere una panoramica rapida del codice (Figura 11) . Per attivare la mini mappa, aprire il riquadro comandi (F1 o clic con il pulsante destro del mouse) e selezionare Toggle Minimap (Attiva/disattiva mini mappa).
Corrispondenza tra parentesi graffe
Durante la modifica o la visualizzazione di un file ora sono disponibili linee guida sul lato sinistro per semplificare la corrispondenza tra le parentesi graffe (Figura 12) .
Visualizzare e nascondere gli spazi
Ora è possibile visualizzare e nascondere gli spazi durante la visualizzazione o la modifica di un file. È in corso lo sviluppo di una funzionalità che consente di attivare e disattivare gli spazi durante il controllo delle differenze (diffing). Per visualizzare gli spazi (Figura 13) , aprire Riquadro comandi premendo F1 o facendo clic con il pulsante destro del mouse e selezionare Attiva/Disattiva spazio vuoto, che consente di distinguere tra spazi e tabulazioni.
Impostazione per disattivare la modifica Web per i repository TFVC
I team che utilizzano TFVC spesso utilizzano i criteri di archiviazione in Visual Studio per garantire la qualità del codice. Poiché tuttavia i criteri di archiviazione sono applicati sul client, il codice modificato sul Web non è soggetto agli stessi criteri.
Più persone hanno chiesto di poter disabilitare la modifica Web per proteggersi dalle modifiche che escludono i criteri di archiviazione. È disponibile un modo per disattivare la modifica Web (aggiunta, eliminazione, ridenominazione e modifica) per il controllo della versione di Team Foundation per singolo progetto/repository.
Per impedire la modifica Web dalla pagina File , passare a Impostazioni e quindi controllo della versione(Figura 14). Fare clic sul repository del controllo della versione di Team Foundation nell'albero, passare al pivot Opzioni e deselezionare Abilita modifica Web per questo repository del controllo della versione di Team Foundation. Per impostazione predefinita, la modifica Web è abilitata.
Nota
La modifica di README dalla Pagina di panoramica progetto non è interessata.
Se si tenta una modifica Web in un progetto in cui è disabilitata, un messaggio notifica che la modifica Web non è consentita (figura 15) .
Identificare i rami non aggiornati
È possibile tenere pulito il repository eliminando i rami non più necessari per consentire ai team di trovare i rami di interesse e impostare i preferiti al giusto livello di granularità. Tuttavia, se il repository contiene molti rami, può essere difficile capire quali sono inattivi e possono essere eliminati. Ora è più semplice identificare i rami "non aggiornati" (rami che puntano a commit risalenti a oltre 3 mesi prima). Per visualizzare i rami non aggiornati, passare al pivot Non aggiornato nella pagina Rami(Figura 16) .
Eseguire la ricerca di un ramo eliminato e ricrearlo
Quando si elimina accidentalmente un ramo dal server, può essere difficile capire cosa ne è stato. Ora è possibile cercare un ramo eliminato, vedere chi lo ha eliminato e quando e, se lo si desidera, ricrearlo.
Per cercare un ramo eliminato, immettere il nome completo del ramo nella casella di ricerca relativa. Verranno restituiti i rami esistenti che corrispondono al testo specificato. Verrà anche visualizzata un'opzione per cercare una corrispondenza esatta nell'elenco dei rami eliminati. Fare clic sul collegamento per cercare i rami eliminati (Figura 17) .
Se viene trovata una corrispondenza, verrà indicato chi lo ha eliminato e quando. È anche possibile ripristinare il ramo (Figura 18) .
Tramite l'operazione di ripristino il ramo viene ricreato in corrispondenza dell'ultimo commit a cui ha fatto riferimento. I criteri e le autorizzazioni non verranno ripristinati.
Cercare un commit nei rami che iniziano con un prefisso
Se la struttura dei rami presenta un formato gerarchico in cui tutti i rami hanno un prefisso di testo, questa funzionalità consente di trovare un commit in tutti i rami che iniziano con quel prefisso. Ad esempio, se si vuole verificare se un commit ha fatto il suo modo a tutti i rami con prefisso "dev" e quindi digitare semplicemente "dev" nella casella di ricerca e selezionare Cerca nei rami a partire da "dev"(Figura 19).
Callout richiesta pull più completo nella pagina dei dettagli del commit
Il callout della richiesta pull nella pagina dei dettagli del commit consente di visualizzare un maggior numero di informazioni utili per eseguire una diagnosi migliore (Figura 20) . Ora vengono anche mostrate la prima richiesta pull che ha introdotto il commit ai rami e la richiesta pull associata al ramo predefinito nel callout.
Visualizzazione struttura ad albero filtro nel codice
Non è più necessario scorrere tutti i file che un commit potrebbe aver modificato solo per trovare quelli desiderati. La visualizzazione struttura ad albero nella pagina dei dettagli di commit, richieste pull, shelveset e insiemi di modifiche supporta ora il filtraggio di file e cartelle. Si tratta di un filtro avanzato che visualizza i file figlio di una cartella quando si filtra in base al nome della cartella e una struttura ad albero compressa di un file per visualizzare la relativa gerarchia quando si filtra in base al nome file.
Filtro per la ricerca di file o cartelle nell'albero del commit (Figura 21) e (Figura 22) :
La pagina Aggiornamenti del ramo è ora Push
La pagina Aggiornamenti del ramo ha una grande importanza. Era tuttavia nascosta come pivot nell'hub Cronologia. Ora la pagina degli aggiornamenti del ramo è visibile come hub denominato Push(Figura 23) in Codice, insieme a Commit, Rami, Tag e Richieste pull. Il nuovo URL per la pagina di push è: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes. Gli URL precedenti continueranno a funzionare.
Allo stesso tempo, l'hub cronologia viene ora rinominato Commits(Figura 24) poiché l'hub mostra solo i commit. Secondo i commenti e suggerimenti ricevuti, sembra che gli utenti avessero difficoltà a risolvere i problemi correlati ai commit perché la visualizzazione elenco commit mostra soltanto l'ora al passaggio del mouse. Nella visualizzazione elenco commit la data e l'ora vengono ora visualizzate nel formato gg/mm/aa hh:mm. Il nuovo URL per la pagina commit è: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits. Gli URL precedenti continueranno a funzionare.
Mantenere il nome file durante lo spostamento da file a commit
Secondo i commenti e i suggerimenti ricevuti, quando gli utenti filtrano la directory in base a un determinato file nel pivot File dell'hub Codice e poi passano al pivot Cronologia, il nome del file non viene salvato in modo permanente se il commit cambia più di 1.000 file. Per questo motivo gli utenti devono caricare più file e filtrare il contenuto per trovare il file, con un considerevole impatto sulla produttività. Gli sviluppatori lavorano in genere nella stessa directory e desiderano salvare in modo permanente nelle directory in cui lavorano mentre tengono traccia delle modifiche. Ora, il nome file viene salvato in modo permanente mentre si passa dai pivot dell'hub Codice, a prescindere dal numero di file modificati in un commit. Ciò significa che non è necessario fare clic su Carica altro per trovare il file desiderato.
Visualizzare i tag Git
È possibile visualizzare tutti i tag nel repository nella pagina Tag(Figura 25) . Se si gestiscono tutti i tag come versioni, un utente può visitare la pagina dei tag per ottenere una panoramica di tutte le versioni del prodotto.
È possibile distinguere facilmente tra un tag leggero e un tag annotato. I tag annotati visualizzano il tagger e la data di creazione insieme al commit associato, mentre i tag leggeri visualizzano soltanto le informazioni sul commit.
Eliminare i tag Git
Talvolta potrebbe essere necessario eliminare un tag dal repository remoto. Il problema potrebbe essere dovuto a un errore di digitazione nel nome del tag oppure all'applicazione del tag al commit errato. È possibile eliminare facilmente i tag dall'interfaccia utente Web facendo clic sul menu di scelta rapida di un tag nella pagina Tag e selezionando Elimina tag(Figura 26).
Avviso
L'eliminazione di tag nei repository remoti deve essere eseguita con attenzione.
Filtraggio dei tag Git
Per i repository precedenti, il numero di tag può aumentare considerevolmente nel tempo; è anche possibile che alcuni repository dispongano di tag creati in gerarchie, cosa che può complicare la ricerca dei tag.
Se non si trova il tag che si sta cercando nella pagina Tag, è possibile cercare semplicemente il nome del tag usando il filtro nella parte superiore della pagina Tag(Figura 27) .
Sicurezza dei tag Git
Ora è possibile concedere autorizzazioni granulari agli utenti del repository per gestire i tag. È possibile concedere agli utenti l'autorizzazione per eliminare o gestire tag dall'interfaccia (Figura 28) .
Suggerimento
Altre informazioni sui tag Git nel blog Microsoft DevOps.
Completare automaticamente gli elementi di lavoro quando si completano le richieste pull
Se si collegano elementi di lavoro a richieste pull, è ancora più semplice mantenere tutto aggiornato. Quando si completa una richiesta pull, sarà possibile completare automaticamente gli elementi di lavoro collegati dopo che la richiesta pull è stata unita (figura 29) . Se si usano criteri e si impostano le richieste pull per il completamento automatico, verrà visualizzata la stessa opzione. Non è più necessario ricordare di rivisitare gli elementi di lavoro per aggiornare lo stato dopo il completamento della richiesta pull. Tutto avviene automaticamente.
Reimpostare i voti al push/nuova iterazione
I team che scelgono un flusso di lavoro di approvazione più rigido nelle richieste pull possono ora scegliere esplicitamente di reimpostare i voti al push delle nuove modifiche (Figura 30) . La nuova impostazione è un'opzione nei criteri per richiedere un numero minimo di revisori.
Se impostata, ogni volta che il ramo di origine della richiesta pull verrà aggiornato verranno reimpostati i voti di tutti i revisori. La sequenza temporale della richiesta pull registrerà una voce ogni volta che i voti vengono reimpostati tramite questa opzione (Figura 31) .
Filtrare la struttura ad albero della richiesta pull in base al nome file
Trovare un file in una richiesta pull non è mai stato più semplice. La nuova casella filtro nella visualizzazione File consente agli utenti di filtrare l'elenco dei file nella visualizzazione struttura ad albero (Figura 32) .
Il filtro corrisponde a qualsiasi parte del percorso dei file nella richiesta pull, pertanto è possibile cercare nomi di cartelle, percorsi parziali, nomi di file o estensioni (Figura 33) .
Altre opzioni di filtraggio dei commenti delle richieste pull
I commenti nella panoramica della richiesta pull e nella visualizzazione file ora offrono le stesse opzioni (Figura 34) . È anche possibile filtrare per visualizzare solo le discussioni a cui si è partecipato.
Visualizzare le differenze originali per i commenti del codice nei dettagli della richiesta pull
Talvolta può essere difficile comprendere un commento della richiesta pull dopo che il codice a cui fa riferimento è cambiato (spesso dopo che è stata apportata una modifica richiesta) (figura 35) .
Quando si verifica questa situazione, verrà ora visualizzata una notifica con un numero di aggiornamento su cui è possibile fare clic per vedere come veniva visualizzato il codice quando è stato creato il commento (figura 36) .
Commenti della richiesta pull comprimibili
La revisione del codice è una parte essenziale dell'esperienza della richiesta pull, pertanto sono state aggiunte nuove funzionalità per consentire ai revisori di concentrarsi più facilmente sul codice. I revisori del codice possono nascondere con facilità i commenti quando rivedono per la prima volta il nuovo codice (Figura 37) .
Se si nascondono i commenti (Figura 38) , questi non sono più visibili nella visualizzazione struttura ad albero e i thread dei commenti vengono compressi nella visualizzazione file:
Quando i commenti sono compressi, possono essere espansi con facilità facendo clic sull'icona a margine, quindi compressi nuovamente con un altro clic. Le descrizioni comandi(Figura 39) semplificano la visualizzazione di un commento senza visualizzare l'intero thread.
Elenchi attività nei commenti e nelle descrizioni delle richieste pull
Quando si prepara una richiesta pull o si commenta, si inizia con un breve elenco di cose di cui tenere traccia, ma poi si finisce per modificare il testo o per aggiungere più commenti. Gli elenchi di attività leggere sono un modo ottimale per tenere traccia dei progressi compiuti relativamente a un elenco di cose da fare, sia come autore sia come revisore della richiesta pull, nella descrizione o in un singolo commento consolidato. Fare clic sulla barra degli strumenti Markdown per iniziare o per applicare il formato al testo selezionato (Figura 40) .
Dopo aver aggiunto un elenco attività (figura 41) , è sufficiente selezionare le caselle per contrassegnare gli elementi come completati. Questi sono espressi e archiviati nel commento come [ ] e [x] in Markdown. Per altre informazioni, vedere Markdown guidance (Linee guida per il markdown).
Possibilità di aggiungere "Mi piace" ai commenti nelle richieste pull
Per dimostrare il proprio apprezzamento per un commento alla richiesta pull è sufficiente un solo clic sul pulsante Mi piace(Figura 42) . È possibile visualizzare l'elenco di tutti gli utenti che hanno aggiunto Mi piace al commento passando il mouse sul pulsante.
Flusso di lavoro migliorato quando si approva con suggerimenti
L'uso dell'opzione di completamento automatico(figura 43) con le richieste pull è un ottimo modo per migliorare la produttività, ma non dovrebbe interrompere eventuali discussioni attive con i revisori del codice. Per agevolare queste discussioni, il voto Approva con suggerimenti chiederà ora quando impostare la richiesta pull per il completamento automatico. L'utente avrà la possibilità di annullare il completamento automatico in modo da poter leggere i commenti e suggerimenti o di mantenere impostato il completamento automatico e consentire il completamento automatico della richiesta pull quando vengono soddisfatti tutti i criteri.
Supporto del filtraggio percorso per le notifiche Git
Anziché ottenere notifiche per tutte le cartelle di un repository, è ora possibile scegliere di venire notificati quando i membri del team creano richieste pull o eseguono il push del codice nelle sole cartelle desiderate. Quando si creano sottoscrizioni delle notifiche di posta elettronica per le richieste pull o push di Git, viene visualizzata una nuova opzione per filtrare le notifiche in base al percorso delle cartelle (Figura 44) .
Modelli di posta elettronica aggiornati per i flussi di lavoro della richiesta pull
Gli avvisi di posta elettronica delle richieste pull sono stati aggiornati per renderli chiari, concisi e interattivi (Figura 45) . La riga dell'oggetto inizierà con il titolo della richiesta pull e informazioni secondarie, come il nome del repository e l'ID, vengono posticipate alla fine. Il nome dell'autore è stato aggiunto all'oggetto per rendere più semplice l'applicazione di regole e filtri in base all'autore della richiesta pull.
Il corpo dei messaggi di posta elettronica di avviso presenta un modello aggiornato che prima riepiloga il motivo per cui è stato inviato l'avviso, quindi visualizza i metadati critici (titolo, nomi dei rami e descrizione) e un pulsante di invito all'azione principale. Dettagli aggiuntivi come i revisori, i file e i commit vengono inclusi più avanti nel messaggio di posta elettronica.
Per la maggior parte degli avvisi l'invito all'azione riguarda la visualizzazione della richiesta pull nel Web (figura 46) . Quando si riceve notifica per un commento specifico, tuttavia, l'invito all'azione sarà collegato direttamente a quel commento per poter trovare con facilità il codice e la conversazione precedente per avere un contesto.
Modelli di posta elettronica aggiornati per le notifiche push
Le notifiche push sono state aggiornate per farle corrispondere ai nuovi modelli di messaggio di posta elettronica, ottimizzati per risultare chiari, concisi e interattivi (Figura 47) . La riga dell'oggetto consente di distinguere chiaramente i messaggi di posta elettronica push, di identificare il ramo, il repository e l'autore e di riepilogare il numero di commit inclusi nel push. Le modifiche semplificano anche la creazione di regole e filtri per la gestione ottimale di queste notifiche di posta elettronica.
Il corpo del messaggio di posta elettronica è simile a quello degli altri messaggi e indica il motivo dell'invio, l'utente che ha avviato l'azione e i dettagli dell'accaduto. In particolare, per gli avvisi di push vengono inclusi dettagli su repository, ramo, file e commit, per informare i destinatari sull'ambito delle modifiche. L'invito all'azione principale per gli avvisi push è Visualizza push, che apre la vista corrispondente al push che ha generato l'avviso.
Wiki
Ogni progetto supporta ora un proprio Wiki (Figura 48) . Ora è possibile scrivere facilmente pagine che aiuteranno i membri del team a comprendere, usare e contribuire al progetto.
Alcune delle funzionalità chiave del nuovo Wiki includono:
- Esperienza di modifica semplificata usando la sintassi di markdown.
- La nuova pagina consente di specificare un titolo e aggiungere contenuto. (Figura 49)
- Supporto dei tag HTML in markdown (Figura 50) .
- Facile ridimensionamento delle immagini nella cartella markdown (Figura 51) .
- Riquadro di gestione pagina sofisticato che consente di riordinare, riassegnare l'elemento padre e gestire le pagine.
- Possibilità di filtrare le pagine in base al titolo per Wiki di grandi dimensioni (Figura 52) .
- Aggiornamenti offline di Wiki per utenti esperti.
Suggerimento
Altre informazioni di introduzione a Wiki.
Man mano che aumenta l'uso di Wiki, aumentano le probabilità che si salvino modifiche non intenzionali. Ora è possibile ripristinare una revisione a una pagina Wiki accedendo ai dettagli della revisione e facendo clic sul pulsante Ripristina(Figura 53) .
Creare una pagina Wiki da un collegamento interrotto
Durante la creazione di Wiki è stato osservato un modello nel quale un sommario in una pagina Wiki includeva collegamenti inesistenti (Figura 54) . Gli utenti avrebbero potuto fare clic su tali collegamenti nel tentativo di creare una pagina effettiva. In passato questo scenario veniva gestito visualizzando un avviso che informava che il collegamento era interrotto o la pagina inesistente. Ora questo scenario viene gestito come uno scenario principale per Wiki consentendo all'utente di creare pagine.
Deep linking nelle pagine Wiki
Il Wiki ora supporta il collegamento diretto di sezioni all'interno di una pagina e tra una pagina e l'altra. Questa funzionalità è molto utile per la creazione di sommari. È possibile fare riferimento a un'intestazione nella stessa pagina o in un'altra pagina usando la sintassi seguente:
- Stessa pagina:
[text to display](#section-name) - Altra pagina:
[text to display](/page-name#section-name)
L'estensione Wiki nel Marketplace è deprecata. Gli utenti di estensioni Wiki esistenti possono migrare le proprie pagine nel nuovo Wiki usando questo strumento di migrazione. Altre informazioni per eseguire la migrazione di pagine Wiki esistenti nel nuovo Wiki.
Gestione pacchetti
Aggiornamenti dell'esperienza di gestione pacchetti
Gli URL dei pacchetti usano il nome e la versione dei pacchetti, anziché usare i GUID. Questo semplifica la creazione degli URL dei pacchetti (Figura 55) . Il formato è: \<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package.
È ora possibile nascondere le versioni dei pacchetti eliminati (Figura 56) a tutti gli utenti del feed. Viene così eliminata la visualizzazione di pacchetti barrati.
Qualsiasi azione eseguibile nella pagina dei dettagli del pacchetto può essere eseguita dal menu di scelta rapida nell'elenco dei pacchetti.
L'elenco dei pacchetti contiene una nuova colonna Ultimo push(Figura 57) con date leggibili dall'utente, che consente di trovare con facilità i pacchetti aggiornati di recente.
Pacchetti Maven
Ora è disponibile il supporto per l'hosting degli artefatti Maven in Team Foundation Server 2018 (figura 58) . Gli elementi Maven consentono agli sviluppatori Java di condividere con facilità codice e componenti. Estrarre la guida introduttiva per sapere come condividere gli elementi Maven usando Gestione pacchetti.
Nuova attività NuGet unificata
Le attività Ripristino NuGet, Strumento di creazione pacchetti NuGet e Strumenti di pubblicazione pacchetti NuGet sono state integrate in un'attività di compilazione NuGet unificata per un migliore allineamento al resto della libreria dell'attività di compilazione. La nuova attività usa NuGet 4.0.0 per impostazione predefinita. Di conseguenza, poiché le attività precedenti sono deprecate si consiglia di passare il prima possibile alla nuova attività NuGet. Questa modifica coincide con un'ondata di miglioramenti descritti di seguito accessibili unicamente usando l'attività combinata.
In questo contesto, è stata anche rilasciata una nuova attività Programma di installazione strumento NuGet che controlla la versione di NuGet disponibile su PATH e usata dalla nuova attività NuGet. In questo caso, per usare una versione più recente di NuGet, aggiungere un'attività Programma di installazione strumento NuGet all'inizio della build (Figura 59) .
Suggerimento
Altre informazioni sull'uso delle versioni più recenti di NuGet nella compilazione sul blog di Microsoft DevOps.
Opzione NuGet "Consenti di ignorare i duplicati"
Molti clienti NuGet generano un set di pacchetti di cui solo una parte presentano degli aggiornamenti (e quindi numeri di versione aggiornati). L'attività di compilazione NuGet prevede una nuova opzione Consenti di ignorare i duplicati che permette di continuare con l'attività anche se tenta di eseguire il push dei pacchetti in un feed di VSTS/TFS dove la versione è già in uso.
aggiornamenti attività di compilazione npm
Che si stia compilando un progetto npm in Windows, Linux o Mac, la nuova attività di compilazione NPM assicura un funzionamento senza problemi. L'attività è stata organizzata in modo che sia l'installazione di npm sia la pubblicazione di npm risultino più semplici. Per l'installazione e la pubblicazione è stata semplificata l'acquisizione delle credenziali in modo che le credenziali per i registri elencati nel file .npmrc del progetto possano essere archiviate in modo sicuro in un endpoint servizio. In alternativa, se si usa un feed di VSTS/TFS, è possibile selezionare un feed, dopodiché verrà generato un progetto .npmrc con le credenziali necessarie usate dall'agente di compilazione.
Maven ora supporta i feed autenticati
A differenza di NuGet e npm, l'attività di compilazione Maven precedente non funziona con i feed autenticati. L'attività Maven è stata aggiornata per semplificare l'uso dei feed di VSTS/TFS (figura 60) .
L'attività dotnet supporta i feed autenticati, i progetti Web
La versione principale successiva dell'attività dotnet (2.x) risponde a molte richieste degli utenti e corregge una serie di bug rilevati nel tempo. Il comportamento predefinito include quanto segue:
- Innanzitutto dotnet supporta ora origini di pacchetti autenticate come Gestione pacchetti, in modo che non sia più necessario usare l'attività NuGet per ripristinare i pacchetti da origini pacchetti private.
- Il comportamento del campo Percorso dei progetti è stato modificato nella versione 2.0 dell'attività. Nelle versioni precedenti dell'attività, se non è possibile trovare i file di progetto corrispondenti al criterio specificato, l'attività registra un avviso e procede fino a conclusione. In questi scenari può talvolta risultare difficile comprendere perché la compilazione riesce, ma le dipendenze non vengono ripristinate. Ora l'attività avrà esito negativo se i file di progetto corrispondenti al modello specificato non vengono trovati. Questo è in linea con il comportamento di altre attività ed è di facile comprensione e uso.
- Nelle versioni precedenti del comando di pubblicazione dell'attività il percorso di output viene modificato tramite l'inserimento di tutti i file in una cartella denominata in base al nome del file di progetto, anche quando si passa un percorso di output esplicito. In questo modo, è difficile concatenare i comandi. Ora si ha il controllo sul file del percorso di output.
È stata inoltre rilasciata una nuova attività Programma di installazione strumento dotnet che controlla la versione di dotnet disponibile in PATH e usata dalla nuova attività dotnet. Per usare una versione più nuova di dotnet, aggiungere un'attività Programma di installazione strumento dotnet all'inizio della build.
Lavorare al di fuori dellaccount/raccolta
Ora è più facile lavorare con i feed (figura 61) all'esterno del server TFS o dell'account VSTS, sia che si tratti di feed Gestione pacchetti in un altro account VSTS o in un altro server TFS o di feed non appartenenti a Gestione pacchetti, come NuGet.org/npmjs.com, Artifactory o MyGet (figura 60) . I tipi Endpoint servizio per NuGet e npm facilitano l'immissione delle credenziali corrette e consentono di eseguire le attività di compilazione in modo trasparente dal download fino al push del pacchetto.
Selezione feed per i feed di Visual Studio Team Services/Team Foundation Server
È sempre consigliabile archiviare un file di configurazione (NuGet.Config, .npmrc e così via) in modo che il repository di origine contenga un record dell'origine dei pacchetti. Sono stati tuttavia segnalati alcuni scenari in cui questo comportamento non è ideale, pertanto è stata aggiunta la nuova opzione Usa pacchetti da questo feed VSTS/TFS che consente di selezionare un feed e di generare automaticamente un file di configurazione da usare nel passaggio di compilazione (figura 62) .
Compilazione e versione
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. Se non si è ancora pronti a eseguire la migrazione ed è necessario continuare a usare le compilazioni XAML, eseguire l'aggiornamento a TFS 2018 Update 2.
Quando si esegue l'aggiornamento a TFS 2018 RTW o Update 1:
Se si dispone di dati di compilazioni XAML nella raccolta di progetti team, verrà visualizzato un avviso sulla rimozione delle funzionalità di compilazione XAML.
Sarà possibile visualizzare le compilazioni XAML completate, ma non sarà possibile accodarne di nuove.
In TFS 2018 non è presente nessuna nuova versione del controller di compilazione o dell'agente 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, questi vanno installati mediante il programma di installazione dell'agente di compilazione TFS 2015.
Suggerimento
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.
Esportare e importare le definizioni di compilazione
Le definizioni di compilazione vengono implementate internamente come file json, pertanto i dettagli delle modifiche sono visibili nella cronologia del file. È già possibile clonare e creare modelli dalle definizioni di compilazione, tuttavia molti utenti preferiscono eseguire una copia della loro logica di compilazione e riusarla in un altro progetto team. Si tratta di una delle dieci richieste più frequenti in UserVoice.
Ora è possibile eseguire questa operazione (figura 63) e (figura 64) .
Estensioni con modelli di compilazione
I modelli di compilazione rappresentano una linea di base per imparare a definire il processo di compilazione. Alcuni di questi modelli sono già disponibili e sebbene fosse possibile caricarne di nuovi nel proprio account, gli autori delle estensioni non potevano includere nuovi modelli all'interno di un'estensione. Ora è possibile includere i modelli di compilazione nelle estensioni. Esempio:
{ "id": "Template1",
"type": "ms.vss-build.template",
"targets": [ "ms.vss-build.templates" ],
"properties": { "name": "Template1" } }
Per l'esempio completo, vedere https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension.
Suggerimento
È possibile usare questa funzionalità per offrire e condividere lo stesso modello personalizzato in tutti i progetti team.
Deprecare un'attività in un'estensione
È ora possibile deprecare un'attività nella propria estensione. A tale scopo, è necessario aggiungere la seguente variabile alla versione più recente dell'attività:
"deprecated": true
Quando l'utente cerca attività deprecate (figura 65) , queste attività vengono spostate alla fine e quindi raggruppate in una sezione comprimibile, compressa per impostazione predefinita. Se una definizione sta già usando un'attività deprecata, viene mostrata una notifica per invitare gli utenti a passare a quella sostitutiva.
È possibile aiutare gli utenti a ottenere altre informazioni sull'attività sostitutiva citandola nella descrizione dell'attività (Figura 66) . La descrizione indirizzerà gli utenti che usano l'attività nella giusta direzione sia dal catalogo attività sia dalle definizioni di compilazione/versione esistenti.
Consentire alle sezioni di compilazione con contributo di controllare la visibilità della sezione
Se in precedenza si usava un'estensione con attività e sezioni di riepilogo di compilazione, la sezione di riepilogo di compilazione era comunque visibile anche se l'attività di compilazione non veniva usata in quella build. Ora è possibile scegliere di nascondere o di visualizzare la sezione nella pagina di riepilogo di compilazione aggiungendo la riga seguente nel codice dell'estensione e impostando il valore su true o false:
VSS.getConfiguration().setSectionVisibility("$(publisherId).$(extensionId).$(sectionId)", false);
Visualizzare l'esempio inclusono nel repository vsts-extension-samples Microsoft.
Supporto per i gruppi di variabili
I gruppi di variabili sono disponibili per l'uso nelle definizioni di versione e ora possono essere usati anche nelle definizioni di compilazione. Altre informazioni sulla creazione di un gruppo di variabili. Questo aspetto è stato sviluppato e trattato con priorità in base ai suggerimenti correlati per le variabili di compilazione/versione a livello di progetto e i gruppi di variabili nelle definizioni di compilazione.
Usare file protetti come i certificati Apple
È stata aggiunta una libreria di file sicuri per utilizzo generico (figura 67).
Usare la libreria di file protetti per archiviare file, ad esempio certificati di firma, profili di provisioning Apple, file di archivio chiavi Android e chiavi SSH nel server senza la necessità di eseguirne il commit nel repository di origine.
Il contenuto dei file protetti è crittografato e può essere usato durante processi di compilazione o versione facendo riferimento a essi da un'attività. I file protetti sono disponibili in più definizioni di compilazione e versione nel progetto team in base alle impostazioni di sicurezza. I file protetti seguono il modello di sicurezza della libreria.
Sono anche state aggiunte alcune attività Apple che usano questa nuova funzionalità:
Sospendere le definizioni di compilazione
Ora è possibile sospendere o disabilitare le definizioni di compilazione. Se si prevede di apportare modifiche alla definizione di compilazione e si vuole evitare l'accodamento di nuove build fino al termine delle modifiche, è possibile disabilitare la definizione di compilazione. Analogamente, se si prevede di aggiornare i computer agente è possibile scegliere di sospendere una definizione di compilazione. In tal modo VSTS accetta comunque le nuove richieste di compilazione, ma le mantiene in coda senza eseguirle fino a quando non si riprende l'esecuzione della definizione.
Supporto delle convalide di input di attività
La digitazione dei parametri nelle attività di definizione di compilazione può essere soggetta a errori. Con la convalida dell'input di attività, gli autori di attività possono verificare che siano specificati i valori appropriati. Le espressioni di convalida usano la stessa sintassi delle espressioni usata per le condizioni di attività e oltre alle funzioni generali supportate dalle condizioni di attività possono usare qualsiasi funzione supportata, tra cui funzioni URL, IPV4, sha1, funzioni di posta elettronica, funzioni intervallo di numeri, funzioni di lunghezza o funzioni di corrispondenza.
Suggerimento
Altre informazioni sugli obiettivi e l'uso sono disponibili nella pagina repository vsts-tasks.
Nuovo editor delle definizioni di versione
Nell'ambito dell'aggiornamento delle esperienze di compilazione e versione è stato rivisto l'editor delle definizioni di versione per renderlo più semplice e intuitivo, sono stati risolti alcuni punti deboli e sono state aggiunte nuove funzionalità. Una delle funzionalità più avanzate del nuovo editor è la possibilità di visualizzare lo stato delle distribuzioni nei diversi ambienti. Le approvazioni, le proprietà di ambiente e le impostazioni di distribuzione sono ora nel contesto e facilmente configurabili.
Visualizzazione della pipeline
La pipeline (figura 68) nell'editor offre una visualizzazione grafica dello stato delle distribuzioni in una versione. Gli artefatti vengono usati dalla versione e distribuiti negli ambienti. Il layout e il collegamento degli ambienti riflette le impostazioni trigger definite per ogni ambiente.
Interfaccia utente della configurazione nel contesto
Gli artefatti, i trigger di versione, le approvazioni pre-distribuzione e post-distribuzione, le proprietà dell'ambiente e le impostazioni di distribuzione sono ora incluse nel contesto e facilmente configurabili (Figura 69) .
Guida introduttiva ai modelli di distribuzione
Tutti i modelli di distribuzione incorporati sono dotati di parametri di processo che facilitano le operazioni iniziali degli utenti, i quali possono specificare i parametri più importanti senza addentrarsi nelle attività (Figura 70) .
Gestione semplificata delle variabili di versione e di ambiente
La visualizzazione Elenco consente di aggiungere rapidamente variabili di versione o di ambiente e la visualizzazione Griglia consente il confronto e la modifica delle variabili side-by-side tra un ambito e l'altro (Figura 71) . È anche possibile usare la ricerca tramite filtro e parola chiave per gestire il set di variabili con cui operare in entrambe le visualizzazioni.
Editor fase e attività migliorato
Tutti i miglioramenti apportati al nuovo editor delle definizioni di compilazione sono ora disponibili anche nell'editor delle definizioni di versione (Figura 72) . È possibile cercare attività e aggiungerle usando il pulsante Aggiungi o il trascinamento della selezione. È possibile riordinare o clonare attività usando il trascinamento della selezione.
Schede Gruppi di variabili, Conservazione e Opzioni
È ora possibile collegarsi/scollegarsi da gruppi di variabili (Figura 73) , impostare criteri di conservazione per i singoli ambienti e modificare le impostazioni a livello di definizione di versione, ad esempio il formato del numero di versione, nella scheda Opzioni. È anche possibile salvare un ambiente come un modello di distribuzione, impostare le autorizzazioni a livello di ambiente e riordinare le fasi all'interno della scheda Attività.
Usare operazioni a livello di ambiente per il salvataggio come modello e l'impostazione della sicurezza (figura 74) .
Distribuzione di macchine virtuali usando gruppi di distribuzione
Gestione del rilascio supporta ora la distribuzione su più computer predefinita. È ora possibile orchestrare le distribuzioni su più computer ed eseguire aggiornamenti assicurando la disponibilità elevata dell'applicazione.
La funzionalità di distribuzione basata su agenti si basa sugli stessi agenti di compilazione e distribuzione. A differenza dell'attuale approccio che prevede l'installazione degli agenti di compilazione e distribuzione in un set di server proxy in un pool di agenti e indirizza le distribuzioni in server di destinazione remoti, ora si installa direttamente l'agente in ognuno dei server di destinazione e si indirizzano le distribuzioni in quei server. È possibile usare il catalogo attività completo nei computer di destinazione.
Un gruppo di distribuzione (Figura 75) è un gruppo logico di destinazioni, ovvero computer, con agenti installati in ogni destinazione. I gruppi di distribuzione rappresentano gli ambienti fisici, ad esempio single-box Dev, QA di più computer e una farm di computer per UAT/Prod. Specificano anche il contesto di sicurezza per gli ambienti fisici.
È possibile usarli sulle macchine virtuali con cui si registra il proprio agente. È stata semplificata la registrazione in Azure con supporto per un'estensione macchina virtuale di Azure che installa automaticamente l'agente quando viene avviata la macchina virtuale. Erediteremo automaticamente i tag nella macchina virtuale di Azure al momento della registrazione.
Dopo aver creato un gruppo di distribuzione, è sufficiente configurare le operazioni da eseguire nel gruppo (Figura 76) . È possibile specificare quali operazioni eseguire in quali computer usando tag e controllare la velocità della distribuzione.
Quando viene eseguita la distribuzione, i registri visualizzano l'avanzamento nell'intero gruppo di computer di destinazione (Figura 77) .
Questa funzionalità è ora parte integrante di Release Management. Non occorre alcuna licenza aggiuntiva.
Interfaccia utente dei gruppi di distribuzione migliorata
Nel processo di aggiornamento delle aree Compilazione e Versione le pagine dei gruppi di distribuzione sono state rinnovate per offrire un'esperienza più diretta e intuitiva (Figura 78) . Dalla pagina di destinazione è possibile visualizzare l'integrità delle destinazioni nel gruppo di distribuzione. È anche possibile gestire la sicurezza per un singolo gruppo di distribuzione o impostare autorizzazioni predefinite tra diversi gruppi di distribuzione.
Per una destinazione all'interno di un gruppo di distribuzione, è possibile visualizzare un riepilogo, le distribuzioni recenti e le funzionalità della destinazione (figura 79) . È possibile impostare tag nella destinazione e controllare ciò che viene eseguito in ogni destinazione. Il supporto dei filtri per i gruppi di distribuzione verrà aggiunto nelle versioni future.
Riferimenti ai gruppi di attività
I gruppi di attività consentono di definire un set di attività da aggiungere alle definizioni di compilazione o versione (Figura 80) . È pratico se è necessario usare lo stesso raggruppamento di attività in più compilazioni o versioni. Per tenere traccia dei consumer di un gruppo di attività, è ora disponibile una visualizzazione delle definizioni di compilazione e versione e dei gruppi di attività che fanno riferimento al gruppo (figura 79) .
Quando si tenta di eliminare un gruppo di attività a cui viene ancora fatto riferimento, viene visualizzato un avviso e viene presentato un collegamento a questa pagina.
Controllo delle versioni dei gruppi di attività
Quando si apportano modifiche ai gruppi di attività, si corrono dei rschi perché la modifica viene applicata a tutte le definizioni che usano il gruppo di attività. Con il controllo delle versioni dei gruppi di attività, è ora possibile preparare e visualizzare in anteprima le versioni dei gruppi di attività offrendo versioni stabili per le definizioni più importanti finché non si è pronti a procedere. Dopo alcune bozze e iterazioni, è possibile pubblicare una versione stabile e, durante la pubblicazione, se le modifiche sono critiche per natura, è possibile scegliere di pubblicare il gruppo di attività come anteprima (a nuova versione principale). In alternativa, è possibile pubblicarlo direttamente come versione stabile aggiornata (Figura 81) .
Quando è disponibile una nuova versione principale (o anteprima) del gruppo di attività, l'editor definizioni avviserà che è disponibile una nuova versione. Se la versione principale è un'anteprima, viene visualizzato un messaggio che invita a provarla. Quando il gruppo di attività non è più in anteprima, le definizioni che lo usano vengono aggiornate automaticamente, passando lungo il canale principale corrispondente (figura 82) .
Importazione ed esportazione di gruppi di attività
Sebbene i gruppi di attività possano essere riusati in un progetto, è noto che la ricreazione di un gruppo di attività in progetti e account possa presentare delle difficoltà. Per l'importazione/esportazione di gruppi di attività (figura 83) , è ora possibile esportare i gruppi come file JSON e importarli nel percorso desiderato, con le stesse modalità usate per le definizioni di versione. Sono anche stati abilitati i gruppi di attività annidati che si espandono quando vengono esportati.
Supporto configurazione multipla nella attività lato server (senza agente)
La specificazione di moltiplicatori di variabili per le attività lato server, senza agenti, (Figura 84) ora consente di eseguire lo stesso set di attività in una fase in più configurazioni eseguite in parallelo.
Supporto di variabili nell'attività di intervento manuale
L'attività Intervento manuale(Figura 85) supporta ora l'uso di variabili nel testo dell'istruzione visualizzato durante l'esecuzione dell'attività, nel punto in cui l'utente può riprendere l'esecuzione del processo di rilascio o rifiutarlo. È possibile includere qualsiasi variabile definita e disponibile nella versione. I valori vengono usati nelle notifiche e nel messaggio di posta elettronica inviato agli utenti (figura 86) .
Controllare le versioni in un ambiente in base al ramo di origine
È possibile configurare una definizione di versione in modo che attivi automaticamente una distribuzione quando viene creata una nuova versione, in genere dopo il completamento di una compilazione dell'origine. Potrebbe tuttavia essere possibile distribuire solo le compilazioni da rami specifici dell'origine e non dopo il completamento di una compilazione.
È ad esempio possibile distribuire tutte le compilazioni negli ambienti Dev e Test, ma distribuire solo determinate compilazioni in Produzione. In precedenza era necessario gestire due pipeline di versione per questo scopo, una per gli ambienti Dev e Test e un'altra per l'ambiente di produzione.
Release Management supporta ora l'uso di filtri di elementi per ogni ambiente. Ciò significa che è possibile specificare le versioni che verranno distribuite in ogni ambiente quando vengono soddisfatte le condizioni di attivazione della distribuzione (ad esempio una compilazione completata e la creazione di una nuova versione). Nella sezione Trigger della finestra di dialogo Condizioni di distribuzione dell'ambiente (Figura 87) selezionare le condizioni di artefatti come il ramo di origine e i tag per le compilazioni che attiveranno una nuova distribuzione nell'ambiente.
La pagina Riepilogo versione(Figura 88) contiene ora anche un suggerimento popup che indica il motivo per cui tutte le distribuzioni non avviate si trovano nello stato specifico e suggerisce come o quando avviare la distribuzione.
Trigger di versione per i repository Git come un'origine elemento
Release Management ora supporta la configurazione di un trigger di distribuzione continua (Figura 89) per i repository Git collegati a una definizione di versione in un progetto team nello stesso account. In questo modo è possibile attivare automaticamente una versione quando viene eseguito un nuovo commit nel repository. È anche possibile specificare un ramo nel repository Git per il quale i commit attiveranno una versione.
Trigger di versione: distribuzione continua delle modifiche di cui è stato eseguito il push in un repository Git
Release Management ha sempre fornito la possibilità di configurare la distribuzione continua quando viene completata una compilazione. È ora possibile configurare la distribuzione continua in Git Push. Ciò significa che è possibile collegare i repository GitHub e Team Foundation Git come origini elemento a una definizione di versione e quindi attivare automaticamente le versioni per applicazioni come Node.JS e PHP che non vengono generate da una compilazione e non richiedono un'azione di compilazione per la distribuzione continua.
Filtri di ramo nei trigger di ambiente
Nel nuovo editor della definizione di versione è ora possibile specificare le condizioni di artefatto per un determinato ambiente. Queste condizioni di artefatto offrono un controllo più granulare sugli artefatti che vanno distribuiti in un ambiente specifico. Ad esempio, in un ambiente di produzione si vuole garantire che vengano distribuite solo le build generate dal ramo principale. Il filtro deve essere impostato per tutti gli artefatti che si ritiene debbano soddisfare questo criterio.
È anche possibile aggiungere più filtri per ogni artefatto collegato alla definizione di versione (Figura 90) . La distribuzione a questo ambiente viene attivata solo se sono soddisfatte tutte le condizioni dell'artefatto.
Miglioramenti alle attività lato server
Sono stati apportati due miglioramenti alle attività lato server (attività eseguite all'interno di una fase server).
È stata aggiunta una nuova attività che può essere usata per chiamare qualsiasi API REST HTTP generica (Figura 91) come parte della pipeline automatizzata. Può ad esempio essere usata per richiamare un'elaborazione specifica con una funzione di Azure e attenderne il completamento.
È stata aggiunta anche una sezione Opzioni di controllo(Figura 92) a tutte le attività lato server. Il comportamento dell'attività include ora l'impostazione delle opzioni Abilitato, Continua in caso di errore, Esegui sempre e Timeout.
Rilasciare la notifica di stato nell'hub Codice
Attualmente, per sapere se un commit viene distribuito nell'ambiente di produzione del cliente, è necessario identificare la compilazione che usa il commit e quindi verificare tutti gli ambienti di versione in cui viene distribuita la compilazione. Questa esperienza risulta semplificata con l'integrazione dello stato della distribuzione nella notifica di stato dell'hub Codice per mostrare l'elenco di ambienti in cui il codice viene distribuito. Per ogni distribuzione, lo stato viene registrato nell'ultimo commit che faceva parte della distribuzione. Se un commit viene distribuito in più definizioni di versione, con più ambienti, ognuno presenta una voce nella notifica e viene visualizzato lo stato di ogni ambiente (Figura 93) . In questo modo si migliora la tracciabilità del commit di codice nelle distribuzioni.
Per impostazione predefinita, quando si crea una definizione di versione, viene pubblicato lo stato di distribuzione per tutti gli ambienti. È tuttavia possibile scegliere gli ambienti per i quali visualizzare lo stato di distribuzione nella notifica di stato, ad esempio per visualizzare solo gli ambienti di produzione (Figura 94) .
Miglioramenti al menu di definizione di compilazione quando si aggiungono elementi
Quando si aggiungono artefatti di compilazione a una definizione di versione, ora è possibile visualizzare le definizioni con le informazioni sulla struttura di cartelle e semplificare la scelta della definizione (Figura 95) . In questo modo, è più semplice distinguere lo stesso nome di definizione di compilazione, ma in cartelle diverse.
L'elenco delle definizioni viene filtrato in base a quelle che contengono il termine di filtro.
Ripristinare la definizione di versione a una versione precedente
Attualmente, se si aggiorna una definizione di versione, non è possibile eseguire direttamente il ripristino a una versione precedente. L'unico modo consiste nell'accedere alla cronologia della definizione di versione per trovare le differenze delle modifiche e quindi modificare manualmente la definizione di versione. Usando la funzionalità Ripristina definizione(Figura 96) , è possibile selezionare e ripristinare qualsiasi versione precedente di una definizione di versione nella scheda Cronologia della definizione di versione.
Notifiche personalizzate per le versioni
Le notifiche di versione sono ora integrate con le impostazioni di notifica di Visual Studio Team Services. I gestori delle versioni ricevono una notifica automatica per azioni in sospeso (approvazioni o interventi manuali) e per errori di distribuzione importanti. È possibile disattivare le notifiche nelle impostazioni Notifica disponibili nel menu del profilo disattivando l'opzione Release Subscriptions (Sottoscrizioni versione). È anche possibile eseguire la sottoscrizione a notifiche aggiuntive mediante la creazione di sottoscrizioni personalizzate. Gli amministratori possono controllare le sottoscrizioni per i team e i gruppi nelle impostazioni Notifica in Team e Account.
Gli autori di definizioni di versione non dovranno più inviare manualmente messaggi di posta elettronica per le approvazioni e il completamento delle distribuzioni.
Ciò è particolarmente utile per gli account di grandi dimensioni che hanno molti stakeholder per le versioni e stakeholder diversi dal responsabile approvazione, dall'autore della versione e dal proprietario dell'ambiente che vogliono ricevere una notifica (Figura 97) .
Suggerimento
Per altre informazioni, vedere il post per la gestione delle notifiche di versione.
Test
Rimozione del supporto per Centro lab e flussi di test automatici in Microsoft Test Manager
Con lo sviluppo di Build e Release Management, le compilazioni XAML non sono più supportate in Team Foundation Server 2018, di conseguenza è in corso l'aggiornamento del supporto per l'uso di Microsoft Test Manager (MTM) con TFS. L'uso di Centro test/Centro lab in MTM per i test automatici non è più supportato da Team Foundation Server, a partire da Team Foundation Server 2018. Se non si è pronti a eseguire la migrazione dalle compilazioni XAML e da Centro Lab, non eseguire l'aggiornamento a Team Foundation Server 2018.
Vedere l'impatto dell'aggiornamento a TFS 2018 sotto:
Centro Lab:
- Non più supportato:
- Impossibile registrare il controller di test con Team Foundation Server per la creazione e la gestione degli ambienti Lab.
- Qualsiasi controller di test esistente registrato con Team Foundation Server andrà offline e gli ambienti lab saranno contrassegnati da "Non pronto".
- Alternativa consigliata:
- È possibile connettersi al server SCVMM usando l'estensione SCVMM TFS, creare e gestire macchine virtuali, nonché eseguirvi i flussi di lavoro. Per altre informazioni, vedere Come eseguire le operazioni di gestione lab in compilazione e versione.
Test automatizzato:
- Non più supportato:
- I flussi di lavoro di test automatizzati basati su ambienti lab e controller di test come il flusso di lavoro Compilazione XAML-Distribuzione-Test o l'esecuzione di test automatizzati da un piano di test usando MTM non sono più supportati.
- Alternative consigliate:
Test manuali:
- Tutti gli scenari di test manuali continuano a essere pienamente supportati. Se è possibile eseguire test manuali usando MTM con Team Foundation Server 2018, non è possibile usare gli ambienti lab per eseguire test manuali.
- Per tutti gli scenari di test manuali, è consigliabile usare l'hub Test nell'accesso Web di Team Foundation Server.
Miglioramenti alla tracciabilità dei test esplorativi per collegamenti di elementi di lavoro, iterazioni e percorsi di area
In base ai commenti e suggerimenti ricevuti dai team che eseguono test esplorativi, è in corso il miglioramento dei collegamenti di tracciabilità durante la registrazione di bug, attività o test case dall'estensione Test Feedback. I bug e le attività create durante l'esplorazione dei requisiti vengono ora creati con lo stesso percorso di area e la stessa iterazione di quella del requisito e non con le impostazioni predefinite del team. I test case creati durante l'esplorazione dei requisiti verranno ora collegati a un test <- Testato tramite collegamento anziché al collegamento Padre -> Figlio in modo che i test case creati vengano aggiunti automaticamente ai pacchetti di test basati sui requisiti.>< Infine, gli elementi di lavoro creati senza esplorare in modo specifico alcun requisito vengono archiviati nell'iterazione predefinita del team e non nell'iterazione corrente. In questo modo, nessun nuovo elemento di lavoro viene inserito nell'iterazione corrente al termine della pianificazione dello sprint.
Filtri per gli elementi di lavoro test case nei piani e nei gruppi di test nell'hub Test
Oltre ai filtri nei campi Test , ad esempio Risultato, Configurazione e Tester, è ora possibile filtrare nei campi elemento di lavoro test case, ad esempio Titolo, Stato e Assegnato a(Figura 98).
Grafici delle tendenze dei test per ambienti versione ed esecuzioni dei test
Sarà presto disponibile il supporto degli ambienti versione nel widget Test Result Trend (Tendenza risultati del test) (Figura 99) che consentirà di tenere traccia dello stato degli ambienti di test nei dashboard VSTS. Ad esempio la modalità di operazioni da eseguire per testare i risultati in compilare, è possibile creare grafici di tendenza che Mostra test superati e conteggio dei test totale, superato o non superato e durata per test ambienti della versione. È anche possibile filtrare i grafici in base a un'esecuzione test specifica in un ambiente con il filtro del titolo Esecuzione dei test.
Supporto formattazione markdown per i commenti Esecuzione dei test e Risultato del test
Sarà presto disponibile il supporto per la formattazione dei commenti Esecuzione dei test e Risultato del test con la sintassi markdown. È possibile utilizzare questa funzionalità per creare testo formattato o collegamenti rapidi a URL nei commenti. È possibile aggiornare i commenti Risultato del test nella pagina Riepilogo risultati con i commenti Aggiorna analisi e Esecuzione dei test nella pagina Riepilogo esecuzione con i commenti aggiornamento nell'hub Test.
Aggiungere un collegamento a un bug esistente per un test non superato
Quando si analizza il risultato del test nella pagina di riepilogo della compilazione o della versione o nell'hub Test, è ora possibile associare un bug esistente a un test non superato. Questo è utile quando un test non viene superato per un motivo noto per cui è già stato archiviato un bug.
Caricamento di allegati a esecuzioni di test e risultati di test
Ora è possibile allegare come informazioni aggiuntive alle esecuzioni di test o ai risultati del test file come gli screenshot e i file di log. Fino ad ora questa funzionalità era disponibile solo tramite il client Microsoft Test Manager (MTM) ed era necessario alternare il contesto tra l'hub Test in VSTS/TFS e il client MTM.
Organizzazione dei test in batch
L'attività di test di Visual Studio in Gestione compilazione/versione include opzioni per controllare il raggruppamento (organizzazione in batch) dei test al fine di ottenere un'esecuzione efficiente. I test possono essere raggruppati in due modi:
- In base al numero di test e agenti che partecipano all'esecuzione: i test vengono semplicemente raggruppati in un determinato numero di batch di dimensioni specificate.
- In base al tempo di esecuzione precedente dei test: tale tempo viene usato per creare batch con test la cui esecuzione richiede all'incirca lo stesso tempo (Figura 100) . I test a esecuzione rapida vengono raggruppati in un batch, mentre i test con tempi di esecuzione più lunghi vengono raggruppati in un batch separato. Questa opzione può essere combinata con l'impostazione della fase con più agenti per ridurre al minimo il tempo totale di test.
Eseguire test Web usando l'attività VSTest
Con l'attività di test di Visual Studio ora è possibile eseguire i test Web, detti anche test delle prestazioni Web, nella pipeline CI/CD. È possibile eseguire i test Web specificando i test da eseguire nell'input dell'assembly dell'attività. È anche possibile eseguire qualsiasi elemento di lavoro test case in cui un'"automazione associata" è collegata a un test Web, selezionando il piano di test/gruppo di test nell'attività (Figura 101) .
I risultati del test Web saranno disponibili come allegato al risultato del test (figura 102) . È possibile scaricare l'allegato per l'analisi offline dei risultati in Visual Studio.
Questa funzionalità è dipendente dalle modifiche alla piattaforma di test di Visual Studio e richiede che nell'agente di compilazione/rilascio sia installato Visual Studio 2017 Update 4. I test Web non possono essere eseguiti con versioni precedenti di Visual Studio.
In modo analogo i test Web possono essere eseguiti con l'attività Esegui test funzionale. Questa funzionalità è dipendente dalle modifiche apportate all'agente di test, che saranno disponibili con Visual Studio 2017 Update 5.
Suggerimento
Per un esempio dell'uso di questa funzionalità con i test di carico, vedere Load test your app in the cloud using Visual Studio and VSTS quickstart (Guida introduttiva ai test di carico dell'app nel cloud con Visual Studio e VSTS).
Widget dei grafici per piani di test e gruppi di test
In precedenza era possibile creare grafici per i piani e i gruppi di test nell'hub Test e bloccare i grafici in un dashboard. Ora è stato aggiunto un widget che consente la creazione di grafici per i piani di test e i gruppi di test dal catalogo dei widget nel dashboard. È possibile creare grafici per lo stato creazione di test o lo stato esecuzione di test. L'aggiunta di grafici dal widget consente anche di creare grafici più grandi quando sono presenti più dati da visualizzare in un grafico (Figura 103) .
Supporto di screenshot e annotazioni per le app desktop con il browser Chrome per i test manuali
È ora supportata la funzionalità richiesta in uno dei suggerimenti principali derivanti dai test manuali: la possibilità di acquisire screenshot di applicazioni desktop da Web Test Runner nell'hub Test. Fino ad ora, per acquisire screenshot delle app desktop era necessario usare Test Runner in Microsoft Test Manager. Per usare questa funzionalità è necessario installare l'estensione Test Feedback. Il supporto per il browser Chrome è in corso di distribuzione e quello per Firefox seguirà a breve.
Sospensione dell'estensione TFS per SharePoint
TFS 2018 e versioni successive non supporterà più l'estensione TFS per SharePoint. Le schermate usate per configurare l'integrazione tra un server TFS e un server SharePoint sono state rimosse dalla Console di amministrazione di Team Foundation.
Nota
Se si esegue l'aggiornamento a TFS 2018 da una versione precedente configurata per l'integrazione con SharePoint, dopo l'aggiornamento è necessario disabilitare l'integrazione con SharePoint. In caso contrario non sarà possibile caricare i siti di SharePoint per TFS.
È stata creata una soluzione che consente di disabilitare l'integrazione nel server SharePoint. Per altre informazioni, vedere il post sul futuro dell'integrazione di TFS/SharePoint.
Sospensione delle chat team
I team di sviluppo moderni dipendono molto dalla collaborazione. Le persone desiderano e necessitano di una posizione da cui monitorare l'attività (notifiche) e discuterne (chat). Alcuni anni fa, quando si individuò questa tendenza si avviò la creazione della chat team per supportare questi scenari. Da quel momento, sono state introdotte sul mercato altre soluzioni di collaborazione. In particolare, l'ascesa di Slack. E più recentemente, l'annuncio di Microsoft Teams.
Con così tante buona soluzioni disponibili che si integrano perfettamente a Team Foundation Server e a Visual Studio Team Services sono stati annunciati nel mese di gennaio i piani per rimuovere la funzionalità Chat team da Team Foundation Server 2018 e da Visual Studio Team Services.
Qual è la tua opinione su questo prodotto?
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.