Note sulla versione di Team Foundation Server 2018

Last Update: 22/11/2017

In questo articolo sono disponibili informazioni relative alla versione più recente di Team Foundation Server 2018. Fare clic sul pulsante per continuare.

Download the latest version of Team Foundation Server

Per altre informazioni su Team Foundation Server 2018, vedere la pagina relativa a requisiti e compatibilità di Team Foundation Server.


Video delle novità in TFS 2018


Commenti 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. Come sempre, è possibile segnalare ciò a cui si desidera venga data priorità visitando UserVoice per aggiungere un'idea o votarne una esistente.


Data di rilascio: 15 novembre 2017

Riepilogo: aggiornamenti di Team Foundation Server 2018

In Team Foundation Server 2018 è stato aggiunto molto nuovo valore. Tra le caratteristiche principali:

Funzionalità rimosse in questa versione


Dettaglio: Novità di questa versione

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 utilizzare 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. Vedere i dettagli in Aggiungere report di progetto.

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 poiché 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 form 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.

Per altre informazioni vedere la documentazione per gli elementi WebLayout e Control.

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

Mobile work item query

(Figura 1) Query elemento di lavoro per dispositivi mobili

Oltre all'aspetto gradevole, questa esperienza supporta controlli ottimizzati per tutti i tipi di campo (Figura 2).

Mobile work item form

(Figura 2) Modulo elemento di lavoro per dispositivi mobili

Con la nuova navigazione mobile (Figura 3), gli utenti possono raggiungere altre parti di TFS predisposte per dispositivi mobili e tornare al sito desktop completo se occorre interagire con altri hub.

Mobile navigation

(Figura 3) Navigazione per dispositivi mobili

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.

Filtering on query

(Figura 4) Filtri per query

Espandere per visualizzare i campi vuoti in una scheda Kanban

È ora possibile scegliere di aggiungere altri campi a una scheda e quindi nascondere i campi vuoti (Figura 5) nelle impostazioni della bacheca per evitare il disordine. 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.

Hidden field

(Figura 5) Campo nascosto nella scheda Kanban

Fare clic sulla freccia di espansione rivolta verso il basso nella parte inferiore della scheda per aggiornare il campo (Figura 6).

Update hidden field

(Figura 6) Aggiornare un campo nascosto nella scheda Kanban

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 idee per nuove funzionalità possono arrivare in qualsiasi momento. Perciò è stata semplificata la procedura per aggiungere direttamente le nuove funzionalità 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.

Inline add on delivery plans

(Figura 7) Aggiunta inline ai piani di recapito

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.

Git forks

(Figura 8) Fork di Git

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 Nuovo > Cartella nella barra dei comandi o nel menu di scelta rapida:

New folder option

(Figura 9) Opzione per nuova cartella

Per TFVC specificare un nome della cartella e quindi archiviarla. Per Git, dato che le cartelle vuote non sono consentite, sarà anche necessario specificare un nome file, eventualmente modificare il file, 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.

New file dialog

(Figura 10) Finestra di dialogo Nuovo file

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

File minimap

(Figura 11) Mini mappa file

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

Bracket matching

(Figura 12) Corrispondenza tra parentesi graffe

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.

Toggle white space

(Figura 13) Visualizzare e nascondere gli spazi

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 TFVC per singolo progetto/repository.

Per disattivare la modifica Web dalla pagina File, scegliere 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.

Turn off web editing

(Figura 14) Disattivare la modifica di pagine Web

Se si tenta una modifica Web in un progetto in cui è disabilitata, un messaggio notifica che la modifica Web non è consentita (Figura 15).

Web editing not allowed dialog

(Figura 15) Finestra di dialogo La modifica Web non è consentita

Questo sviluppo è stato inserito in base a un suggerimento correlato.

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

Stale branches

(Figura 16) Rami non aggiornati

Eseguire la ricerca di un ramo eliminato e ricrearlo

Quando un ramo viene accidentalmente eliminato 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).

Search for deleted branches

(Figura 17) Cercare i rami eliminati

Se viene trovata una corrispondenza, verrà indicato chi lo ha eliminato e quando. È anche possibile ripristinare il ramo (Figura 18).

Restore deleted branches

(Figura 18) Ripristinare i rami eliminati

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, per vedere se è stato eseguito un commit in tutti i rami con prefisso "dev", digitare semplicemente "dev" nella casella di ricerca e selezionare Cerca nei rami che iniziano con "dev" (Figura 19).

Search for a commit

(Figura 19) Cercare un commit

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.

Pull request callout

(Figura 20) Callout richiesta pull

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

Find a file or folder

(Figura 21) Trovare un file o una cartella

Filtered view

(Figura 22) Visualizzazione filtrata nell'albero di commit

La pagina Aggiornamenti del ramo è ora Push

La pagina Aggiornamenti del ramo ha una grande importanza. Era tuttavia nascosta come pivot nell'hub Cronologia. La pagina Aggiornamenti del ramo sarà 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.

Pushes page

(Figura 23) Pagina Push

Allo stesso tempo, l'hub Cronologia è stato rinominato Commit (Figura 24) perché l'hub visualizza 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.

Commits page

(Figura 24) Pagina Commit

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 file non viene salvato in modo permanente se il commit ha modificato 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.

View Git tags

(Figura 25) Visualizzare i tag Git

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

Delete git tags

(Figura 26) Eliminare i tag Git

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

Filter Git tags

(Figura 27) Filtrare i tag Git

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

Git tag security

(Figura 28) Sicurezza dei tag Git

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, è possibile completare automaticamente gli elementi di lavoro collegati dopo che la richiesta pull è stata unita correttamente (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 che la richiesta pull è stata completata. Tutto avverrà automaticamente.

Complete linked work items

(Figura 29) Completare gli elementi di lavoro collegati

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.

Reset votes setting

(Figura 30) Reimpostare i voti

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

Reset votes in timeline

(Figura 31) Reimpostare i voti nella sequenza temporale

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

Find file or folder in pull request

(Figura 32) Trovare file o cartelle nella richiesta pull

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

Find results

(Figura 33) Trovare risultati

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.

PR comment filtering

(Figura 34) Filtri ai commenti richiesta pull

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

View original diff

(Figura 35) Visualizzare diff originale

Quando si verifica questa situazione, ora viene 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).

Update badge

(Figura 36) Notifica di aggiornamento

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

Hide comments

(Figura 37) Nascondere i commenti

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:

Collapsed comments

(Figura 38) Commenti compressi

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) agevolano la visualizzazione rapida di un commento senza visualizzare l'intero thread.

Collapsed comment tooltip

(Figura 39) Descrizione dei comandi dei commenti compressi

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

Task list toolbar

(Figura 40) Barra degli strumenti elenco attività

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

Task list

(Figura 41) Elenco attività

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.

Like pull request comments

(Figura 42) Aggiungere Mi piace a commenti della richiesta pull

Flusso di lavoro migliorato quando si approva con suggerimenti

L'uso dell'opzione 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.

Cancel auto-complete dialog

(Figura 43) Finestra di dialogo dell'annullamento completamento automatico

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

Path filtering for notifications

(Figura 44) Filtrare i percorsi delle notifiche

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 verrà posticipato 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.

Improved email template

(Figura 45) Modello di posta elettronica migliorato

Per la maggior parte degli avvisi l'invito all'azione riguarderà la visualizzazione della richiesta pull nel Web (Figura 46). Quando si viene notificati su 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.

Email call-to-action

(Figura 46) Invito all'azione

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.

Push template

(Figura 47) Modello push

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.

Wiki page

(Figura 48) Pagina Wiki richiesta pull

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)

Title wiki

(Figura 49) Titolo Wiki richiesta pull

  • Supporto dei tag HTML in markdown (Figura 50).

Wiki HTML tags

(Figura 50) Tag HTML wiki richiesta pull

  • Facile ridimensionamento delle immagini nella cartella markdown (Figura 51).

Image resize

(Figura 51) Ridimensionare le immagini richiesta pull

  • 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).

Wiki menu

(Figura 52) Menu wiki richiesta pull

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

Wiki revert button

(Figura 53) Pulsante Ripristina Wiki richiesta pull

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.

Create wiki page

*(Figura 54) Richiesta pull per creare una pagina Wiki *

Deep linking nelle pagine Wiki

Il Wiki ora supporta il deep linking 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.

Package URL

(Figura 55) URL del pacchetto richiesta pull

È ora possibile nascondere le versioni dei pacchetti eliminati (Figura 56) a tutti gli utenti del feed, in risposta a questo suggerimento UserVoice. Viene così eliminata la visualizzazione di pacchetti barrati.

Hide deleted packages

(Figura 56) Nascondere i pacchetti eliminati

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.

Last pushed column

(Figura 57) Colonna Ultimo push

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.

Maven packages

(Figura 58) Pacchetti Maven

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 per favorire l'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 rilasciata una nuova attività Programma di installazione strumento NuGet che controlla la versione di NuGet disponibile su PATH e usato 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).

Nuget task

(Figura 59) Attività NuGet

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 consente di continuare con l'attività anche se tenta di eseguire il push dei pacchetti a 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).

dotnet task

(Figura 60) Attività dotnet

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.

  1. 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.
  2. 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 non i file di progetto corrispondente al criterio specificato non viene trovato. Questo è in linea con il comportamento di altre attività ed è di facile comprensione e uso.
  3. 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.

Abbiamo inoltre rilasciato un'attività Programma di installazione strumento dotnet che controlla la versione del dotnet disponibile in PATH ed è 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.

Feeds to use

(Figura 61) Feed da usare

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

Feed picker

(Figura 62) Selezione di feed

Compilazione e versione

Rimozione del supporto per le compilazioni XAML

In Team Fouldation Server 2015 è stato introdotto un sistema di compilazione multipiattaforma basata sul Web. In Team Foundation Server 2018 è l'unico modello supportato. Le compilazioni XAML non sono supportate in Team Foundation Server 2018. È consigliabile eseguire la migrazione alle compilazioni XAML. Se non si è ancora pronti a eseguire la migrazione ed è necessario continuare a usare le compilazioni XAML, non eseguire l'aggiornamento Team Foundation Server 2018.

Quando si esegue l'aggiornamento a Team Foundation Server 2018:

  • Se si dispone di dati di compilazioni XAML nella raccolta di progetti team, verrà visualizzato un avviso sulla rimozione delle funzionalità di compilazione XAML.

  • In Team Foundation Server 2018 sarà possibile visualizzare le build XAML, ma non sarà possibile metterne in coda altre.

  • Non è disponibile una nuova versione del controller o dell'agente di compilazione XAML in Team Foundation Server 2018 e non è possibile configurare una versione precedente del controller o dell'agente di compilazione XAML da usare con Team Foundation Server 2018.

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 fatto di una delle principali richieste in UserVoice.

Ora è possibile eseguire questa operazione (Figura 63) e (Figura 64).

Export build definition

(Figura 63) Esportare una definizione di compilazione

Import build definition

(Figura 64) Importare una definizione di compilazione

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. Ad esempio:

{  "id": "Template1", 
   "type": "ms.vss-build.template", 
   "targets": [ "ms.vss-build.templates" ], 
   "properties": { "name": "Template1" } }

Per un 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), viene eseguito il push di queste attività alla fine, quindi le attività vengono 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.

Deprecated task badge

(Figura 65) Notifica attività deprecate

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

Deprecated task description

(Figura 66) Descrizione attività deprecate

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 protetti per uso generico (Figura 67).

Secure files library

(Figura 67) Libreria di file protetti

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.

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 elementi verranno usati dalla versione e distribuiti negli ambienti. Il layout e il collegamento degli ambienti riflette le impostazioni trigger definite per ogni ambiente.

Pipeline

(Figura 68) Pipeline delle versioni

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

Release configuration

(Figura 69) Configurazione delle versioni

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

Deployment templates

(Figura 70) Modelli di distribuzione

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.

Simplified management of variables

(Figura 71) Gestione semplificata delle variabili

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.

Task editor

(Figura 72) Editor attività

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

Variable groups

(Figura 73) Gruppi di variabili

Usare operazioni a livello di ambiente per il salvataggio come modello e l'impostazione della sicurezza (figura 74).

Environment menu

(Figura 74) Menu Ambiente

Per altre informazioni vedere la documentazione dell'Editor definizione di versione.

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.

Deployment groups

(Figura 75) Gruppi di distribuzione

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

Configure deployment groups

(Figura 76) Configurare i gruppi di distribuzione

Quando viene eseguita la distribuzione, i registri visualizzano l'avanzamento nell'intero gruppo di computer di destinazione (Figura 77).

Deployment group progress

(Figura 77) Avanzamento gruppi di distribuzione

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.

Deployment groups UI

(Figura 78) Interfaccia utente 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.

Deployment groups UI tags

(Figura 79) Tag interfaccia utente gruppi di distribuzione

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

Task group references

(Figura 80) Riferimenti ai gruppi di attività

Quando si tenta di eliminare un gruppo di attività a cui viene ancora fatto riferimento, viene visualizzato un avviso e viene fornito 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 e fatte scorrere lungo il canale principale corrispondente (Figura 82).

Save as draft

(Figura 81) Salvare i gruppi di attività come bozza

Publish task group as preview

(Figura 82) Pubblicare i gruppi di attività come anteprima

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.

Export task group

(Figura 83) Esportare i gruppi di attività

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.

Multi configuration of agentless tasks

(Figura 84) Configurazione multipla di attività senza agenti

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

Manual intervention task

(Figura 85) Attività di intervento manuale

Manual intevention pending dialog

(Figura 86) Finestra di dialogo dell'intervento manuale in sospeso

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 (compilazione completata e 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.

Deployment conditions dialog

(Figura 87) Finestra di dialogo Condizioni di distribuzione

La pagina Release Summary (Riepilogo versione) (Figura 88) contiene ora anche un suggerimento popup che indica il motivo per cui tutte le distribuzioni non avviate sono in questo stato e suggerisce come o quando avviare la distribuzione.

Release summary tip

(Figura 88) Suggerimento riepilogo della versione

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.

Release triggers

(Figura 89) Trigger di 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 master. 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 verrà attivata solo se sono soddisfatte tutte le condizioni dell'artefatto.

Branch filters

(Figura 90) Filtri dei rami

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.

REST API task

(Figura 91) Attività API REST

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

Task control options

(Figura 92) Opzioni di controllo attività

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.

Release status badge

(Figura 93) Notifica dello stato della definizione versione

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

Deployment options dialog

(Figura 94) Finestra di dialogo opzioni di distribuzione

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.

Add artifact

(Figura 95) Aggiungere artefatti

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

Oggi, se si aggiorna una definizione di versione, non è possibile ripristinarla direttamente 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.

Revert release definition

(Figura 96) Ripristinare una 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 devono 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).

Release notifications

(Figura 97) Notifiche delle versioni

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:
Test automatizzato:
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 verranno 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 collegamento Test <> Testato da e non da un collegamento Padre <> Figlio in modo che i test case creati vengano aggiunti automaticamente ai gruppi di test basate sui requisiti. Infine, gli elementi di lavoro creati senza esplorare in modo specifico alcun requisito verranno archiviati nell'iterazione predefinita del team e non nell'iterazione corrente. In questo modo, nessun nuovo elemento di lavoro verrà 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 come Risultato, Configurazione e Tester, è ora possibile filtrare in base ai campi elemento di lavoro del test case come Titolo, Stato e Assegnato a (Figura 98).

Test case filters

(Figura 98) Filtri di test case

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.

Test trend chart

(Figura 99) Grafico della tendenza 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.

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:

  1. 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.
  2. 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 con tempi di esecuzione brevi vengono raggruppati in un batch, mentre i test con tempi di esecuzione più lunghi vengono raggruppati in un altro batch. Questa opzione può essere combinata con l'impostazione della fase con più agenti per ridurre al minimo il tempo totale di test.

Test batching

(Figura 100) Raggruppamento dei test in batch

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

Test selection

(Figura 101) Selezione dei test

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.

Test summary

(Figura 102) Riepilogo dei test

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.

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

Chart widget

(Figura 103) Widget dei grafici

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.


In alto