Team Foundation Server 2017

Last Update: 30/10/2017

Per visualizzare gli aggiornamenti più recenti, visitare la pagina delle note sulla versione in lingua inglese.

Data di rilascio: 16 novembre 2016

Questo articolo contiene informazioni relative a Team Foundation Server 2017. Questa versione include le innovazioni e i miglioramenti delle funzionalità più recenti. Si noti che i requisiti per Team Foundation Server 2017 sono cambiati. Altri dettagli sono disponibili nella pagina relativa a requisiti e compatibilità di Team Foundation Server. Se queste non sono le note sulla versione previste, sono state visualizzate le note sulla versione per la versione più recente.

Fare clic sul pulsante per scaricare Team Foundation Server 2017.

Download the latest version of Team Foundation Server

Per altre informazioni sui download correlati, vedere la pagina Download di Visual Studio.

Novità

Problemi noti


Novità

Ricerca di codice

La funzionalità per la ricerca di codice offre una soluzione rapida, flessibile e accurata per effettuare ricerche in tutto il codice. Con la progressiva espansione della codebase e la relativa suddivisione in più progetti e repository, diventa sempre più difficile trovare le informazioni necessarie. Per ottimizzare la collaborazione tra team e la condivisione di codice, la funzionalità per la ricerca di codice consente di individuare in modo rapido ed efficiente informazioni rilevanti in tutti i progetti.

Dall'individuazione di esempi di implementazione di un'API, con possibilità di esplorarne la definizione, alla ricerca del testo degli errori, la funzionalità per la ricerca di codice offre una soluzione unica per tutte le esigenze di esplorazione e risoluzione dei problemi del codice (figura 1).

Questa funzionalità offre i vantaggi seguenti:

  • Ricerca in uno o più progetti
  • Classificazione semantica
  • Applicazione di filtri avanzati
  • Collaborazione tra sviluppatori

Code Search

* (Figura 1) Code Search*

Per informazioni dettagliate, vedere Search across all your code (Eseguire ricerche in tutto il codice).

Gestione pacchetti

I pacchetti consentono di condividere il codice all'interno dell'organizzazione: è possibile comporre un prodotto di grandi dimensioni, sviluppare più prodotti in base a un framework condiviso comune oppure creare e condividere librerie e componenti riutilizzabili. Gestione pacchetti (figura 2) semplifica la condivisione del codice eseguendo l'hosting dei pacchetti, condividendoli con gli utenti selezionati e rendendoli facilmente accessibili da Team Build e Release Management.

Gestione pacchetti elimina la necessità di eseguire l'hosting di una condivisione file o server NuGet separata eseguendo l'hosting dei pacchetti NuGet direttamente in Team Foundation Server. Offre il supporto ottimale per NuGet 3. x e per i client legacy di NuGet 2.x. Si integra perfettamente con l'infrastruttura, i team e le autorizzazioni di TFS esistenti e non è quindi necessario eseguire la sincronizzazione delle identità, la gestione dei gruppi in più posizioni e così via. Si integra facilmente anche con Team Build ed è possibile creare e usare pacchetti in flussi di lavoro di integrazione continua.

Per altre informazioni dettagliate, vedere la panoramica di Gestione pacchetti.

Package Management

* (Figura 2) Gestione pacchetti*

Miglioramenti agli strumenti Agile

In Team Foundation Server 2017 sono state aggiunte nuove caratteristiche e funzionalità per gli elementi di lavoro e le lavagne Kanban.

Nuovo form dell'elemento di lavoro

Il nuovo form dell'elemento di lavoro (figura 3) ha un nuovo aspetto grafico. e include alcune nuove interessanti funzionalità:

  • Funzionalità avanzata per la discussione su elementi di lavoro.
  • Supporto per il trascinamento della selezione degli allegati.
  • Esperienza di gestione della cronologia migliorata. Per altre informazioni, vedere History & auditing (Cronologia e controllo).
  • Integrazione più efficace di codice e compilazione.
  • Colorazione dello stato.
  • Progettazione reattiva.
Nota

Il nuovo form dell'elemento di lavoro è l'impostazione predefinita solo per le nuove raccolte. Se si esegue la migrazione di una raccolta esistente, è necessario abilitare il nuovo form dell'elemento di lavoro dalle impostazioni dell'amministratore. Per altre informazioni, vedere Manage roll out of the new web form (Gestire la distribuzione del nuovo form Web).

New WIT Form

(Figura 3) Nuovo form elemento di lavoro

Seguire un elemento di lavoro

È ora possibile configurare un avviso per tener traccia delle modifiche apportate a un singolo elemento di lavoro facendo semplicemente clic sul nuovo pulsante "Segui" (figura 4) nel form. Quando si segue un elemento di lavoro, si riceve una notifica ogni volta che tale elemento cambia, inclusi aggiornamenti di campi, collegamenti, allegati e commenti.

Follow Work Item

(Figura 4) Seguire un elemento di lavoro

Per informazioni dettagliate, vedere Follow a work item (Seguire un elemento di lavoro).

Aggiornamenti in tempo reale della lavagna Kanban

La lavagna Kanban è ora disponibile in tempo reale.

Si è premuto più volte F5 per scoprire che cosa accade nel corso della giornata sulla lavagna Kanban? Provare l'icona nella schermata seguente (figura 5).

Kanban live updates

(Figura 5) Aggiornamenti dinamici Kanban

Quando un utente del proprio team crea, aggiorna o elimina un elemento di lavoro nella lavagna, si ricevono immediatamente aggiornamenti in tempo reale. Inoltre, se l'amministratore esegue aggiornamenti a livello di lavagna o team, ad esempio aggiungendo una nuova colonna o abilitando bug nel backlog, si riceverà una notifica per aggiornare la lavagna e il relativo layout. Per attivare questa funzionalità, è sufficiente abilitare l'icona a forma di torre sulla lavagna Kanban e iniziare a collaborare con il proprio team.

Per altre informazioni, vedere Kanban basics (Nozioni di base su Kanban).

Miglioramenti agli elenchi di controllo

Sono stati apportati numerosi miglioramenti alla modalità di funzionamento degli elenchi di controllo.

I titoli degli elenchi di controllo vengono ora visualizzati come collegamenti ipertestuali (figura 6). Per aprire il form dell'elemento di lavoro è possibile fare clic sul titolo.

Checklist improvements

(Figura 6) Collegamenti ipertestuali elenco di controllo

Gli elenchi di controllo includono ora anche il supporto per menu di scelta rapida che consentono di aprire, modificare o eliminare le voci degli elenchi (figura 7).

Checklist context menu

(Figura 7) Menu di scelta rapida elenco di controllo

Per informazioni dettagliate, vedere l'argomento Add task checklists (Aggiungere elenchi di controllo attività).

Drill-down delle lavagne di epiche e funzionalità

È ora possibile eseguire il drill-down delle lavagne di epiche e funzionalità (figura 8). Il formato dell'elenco di controllo consente di contrassegnare facilmente il lavoro come completato e offre una comoda panoramica del lavoro completato rispetto a quello in sospeso.

Epic Feature drilldown

(Figura 8) Drilldown funzionalità ed epiche

Per altre informazioni, vedere l'argomento relativo a funzionalità ed epiche di Kanban.

Attivazione o disattivazione delle annotazioni sulla lavagna

È ora disponibile un maggiore controllo delle informazioni aggiuntive visualizzate sulle schede nelle lavagne. È ora possibile selezionare le annotazioni da visualizzare nelle schede Kanban (figura 9). È sufficiente deselezionare un'annotazione per nasconderla dalle schede sulla lavagna Kanban. Le prime due annotazioni visualizzate di seguito sono quella relativa agli elementi figlio (Tasks in questo esempio) e l'annotazione Tests.

Turn on/off board annotations

(Figura 9) Attivare/disattivare annotazioni lavagna

Per altre informazioni, vedere l'argomento Customize Cards (Personalizzare le schede).

Comando Cancella formattazione

È stato aggiunto un nuovo comando a tutti i controlli di testo RTF su elementi di lavoro che consente di cancellare tutta la formattazione dal testo selezionato. Nelle versioni precedenti può capitare di copiare e incollare in questo campo del testo formattato che non è possibile annullare (o cancellare). Ora basta invece evidenziare un testo qualsiasi, selezionare il pulsante Cancella formattazione sulla barra degli strumenti (o premere CTRL+BARRA SPAZIATRICE) per ripristinare il formato predefinito del testo.

Applicazione di filtri nella lavagna Kanban

È possibile personalizzare le lavagne Kanban impostando filtri per utenti, iterazioni, tipi di elemento di lavoro e tag (figura 10). Questi filtri verranno mantenuti in modo da consentire la visualizzazione della lavagna personalizzata, anche quando ci si connette da più dispositivi.

Filtering in Kanban

(Figura 10) Applicazione di filtri nella lavagna Kanban

I membri del team possono anche filtrare le lavagne per visualizzare lo stato di avanzamento relativo a uno specifico elemento di lavoro padre. Ad esempio, un utente può visualizzare le storie utente collegate a una determinata funzionalità o visualizzare il lavoro relativo a due o più funzionalità che riportano a un'epica. Questa caratteristica, analogamente agli elenchi di controllo, rappresenta un altro passo nel nostro impegno a fornire visibilità ai diversi livelli di backlog.

Per informazioni dettagliate, vedere l'argomento relativo all'applicazione di filtri nella lavagna Kanban.

Percorso di iterazione predefinito per nuovi elementi di lavoro

Quando si crea un nuovo elemento di lavoro dalla scheda Query o dal widget del dashboard Nuovo elemento di lavoro, il percorso di iterazione di tale elemento è sempre impostato sull'iterazione corrente. Questa non è sempre l'impostazione preferita da tutti i team, perché comporta la visualizzazione immediata di bug sulla lavagna delle attività. Con questo miglioramento, i team possono scegliere il percorso di iterazione predefinito (un percorso specifico o l'iterazione corrente) da usare per i nuovi elementi di lavoro. Passare all'area di amministrazione del team per scegliere un'iterazione predefinita.

Per altre informazioni, vedere la pagina Customize area and iteration paths (Personalizzare percorsi di iterazione e di area).

Controllo CheckBox

È ora possibile aggiungere un controllo CheckBox agli elementi di lavoro (figura 11). Questo nuovo tipo di campo (booleano) ha tutte le proprietà dei campi normali e può essere aggiunto a qualsiasi tipo nel processo. Quando è visualizzato sulle schede o nel risultato di una query, compare come True o False.

Checkbox control

(Figura 11) Controllo checkbox

Per informazioni dettagliate, vedere l'argomento relativo alla personalizzazione di un campo.

Modifica in blocco dei tag

È ora possibile aggiungere e rimuovere i tag da più elementi di lavoro mediante la finestra di dialogo per la modifica in blocco (figura 12).

Bulk edit dialog

(Figura 12) Finestra di dialogo per modifica in blocco

Per informazioni dettagliate, vedere l'argomento relativo all'aggiunta di tag agli elementi di lavoro.

Nuovi punti di estensione

È stato introdotto un nuovo punto di aggiunta contributo nelle pagine di backlog e lavagne per consentire di scrivere estensioni in forma di scheda pivot accanto alle schede Lavagna/Backlog/Capacità.

È ora disponibile un nuovo punto di estensione nel backlog. Le estensioni possono fare riferimento al riquadro di destra, in cui attualmente si trovano il mapping e i dettagli di lavoro (figura 13).

Backlog extension points

(Figura 13) Punti di estensione backlog

Per altre informazioni sulle estensioni, vedere Punti di estensione.

Miglioramenti alla posta elettronica

Sono stati introdotti miglioramenti significativi alla formattazione e all'usabilità di avvisi relativi agli elementi di lavoro, inviti a seguire e messaggi di posta elettronica @mention inviati da TFS (figura 14). I messaggi includono ora un'intestazione coerente, un'istruzione chiara ed efficace e una migliore formattazione per consentire ai destinatari di comprendere più facilmente le informazioni del messaggio. Inoltre, tutti i messaggi di posta elettronica sono progettati in modo da risultare facilmente leggibili sui dispositivi mobili.

Email improvements

(Figura 14) Miglioramenti alla posta elettronica

Per altre informazioni, vedere l'argomento relativo agli avvisi per gli elementi di lavoro.

Modelli di elementi di lavoro

È stata aggiunta la possibilità di creare modelli di elemento di lavoro completi direttamente nell'esperienza Web nativa (figura 15). Questa funzionalità era in precedenza molto limitata nel Web e disponibile solo con il nuovo modulo tramite uno strumento avanzato di Visual Studio. I team hanno ora la possibilità di creare e gestire un set di modelli per modificare rapidamente campi di uso comune.

Work item templates

(Figura 15) Modelli di elementi di lavoro

Per informazioni dettagliate, vedere Modelli di elementi di lavoro.

Integrazione con Project Server non più supportata

Team Foundation Server 2017 e le versioni successive non supporteranno più l'integrazione con Project Server. A partire da RC2, se si aggiorna un database TFS che include l'integrazione con Project Server, verrà visualizzato l'avviso seguente:

È stato rilevato che per questo database è abilitata la configurazione dell'integrazione con Project Server. Team Foundation Server 2017 e le versioni successive non supporteranno più l'integrazione con Project Server.

Dopo l'aggiornamento, l'integrazione con Project Server non funzionerà più.

In futuro, ci si baserà sui partner per le soluzioni di integrazione.

Per altre informazioni su questa modifica, leggere l'argomento seguente: Sincronizzare TFS con Project Server.

Miglioramenti a dashboard e widget

In Team Foundation Server 2017 sono stati introdotti miglioramenti per diversi widget, ad esempio Riquadro query e Richiesta pull.

Catalogo dei widget riprogettato

Il catalogo dei widget è stato riprogettato per consentire la visualizzazione del numero crescente di widget e offrire un'interfaccia più intuitiva ed efficace (figura 16). La funzionalità di ricerca è stata migliorata e l'aspetto grafico è stato adattato allo stile dei pannelli di configurazione dei widget.

Widget catalog

(Figura 16) Catalogo widget

Per altre informazioni, vedere Catalogo dei widget.

Aggiornamenti dei widget

Il widget Riquadro query supporta ora fino a 10 regole condizionali e consente la selezione di colori (figura 17). Questo è molto utile quando si vuole usare i riquadri come indicatori KPI per identificare l'integrità e/o l'eventuale azione necessaria.

Dashboard updates

(Figura 17) Aggiornamenti del dashboard

Il widget Richiesta pull supporta ora più dimensioni e gli utenti possono controllarne l'altezza. Microsoft è attualmente impegnata a rendere ridimensionabile la maggior parte dei widget forniti. Verificare qui la disponibilità di altri widget.

Il widget Nuovo elemento di lavoro consente ora di selezionare il tipo di elemento di lavoro predefinito anziché forzare la selezione del tipo creato più di frequente dall'elenco a discesa.

I widget dei grafici WIT sono ora ridimensionabili. In questo modo gli utenti possono ottenere una visualizzazione estesa di un grafico WIT sul dashboard indipendentemente dalle dimensioni originali.

Il widget Membri del team è stato aggiornato per consentire di aggiungere più facilmente un utente al proprio team (figura 18).

Widget Update

(Figura 18) Aggiornamento dei widget

I team possono ora configurare le dimensioni del widget Risultati query del dashboard per visualizzare più risultati.

Il widget Panoramica sprint è stato riprogettato in modo da rendere più semplice per i team monitorare il proprio lavoro.

Il widget Assegnati a me consente agli utenti di gestire le attività loro assegnate senza uscire dal contesto del dashboard (figura 19). Con un widget dedicato a questo scopo, gli amministratori dei team possono aggiungere questa funzionalità ai dashboard con solo 16 clic del mouse, senza cambi di contesto e senza digitazioni su tastiera. Gli utenti possono ora visualizzare, ordinare, filtrare e gestire il lavoro loro assegnato nel contesto del widget.

Assigned to me

(Figura 19) Assegnati all'utente

API REST dei dashboard

È ora possibile usare le API REST per aggiungere, eliminare e ottenere informazioni su un dashboard a livello di codice. Le API consentono inoltre di aggiungere, rimuovere, aggiornare, sostituire e ottenere informazioni su un widget o un elenco di widget su un dashboard. Per informazioni, consultare la documentazione online di Visual Studio.

Dashboard consentiti

Gli utenti senza privilegi di amministratore possono ora creare e gestire i dashboard del team. Gli amministratori dei team possono limitare le autorizzazioni senza privilegi di amministratore tramite la gestione del dashboard.

Per altre informazioni, vedere Dashboard.

Miglioramenti a Git

In Git sono state apportate alcune modifiche significative per Team Foundation Server 2017. La pagina Rami è stata ridisegnata ed è disponibile una nuova opzione per il merge con squash.

Pagina Rami ridisegnata

La pagina Rami è stata completamente ridisegnata. Include un pivot "Personali" che mostra i rami creati, sottoposti a push o preferiti dall'utente (figura 20). Ogni ramo mostra lo stato delle richieste di compilazione e pull e anche altri comandi come Elimina. Se nel nome di un ramo è presente una barra, ad esempio in "features/jeremy/fix-bug", il ramo viene visualizzato come albero, consentendo così di sfogliare con facilità un lungo elenco di rami. Se si conosce il nome del ramo, è possibile trovare rapidamente quello desiderato.

Redesigned branches page

(Figura 20) Pagina Rami riprogettata

Per altre informazioni sui rami, vedere l'argomento relativo alla gestione dei rami.

Nuova esperienza di richiesta pull

L'esperienza di richiesta pull ha introdotto alcuni aggiornamenti rilevanti in questa versione: alcune funzionalità potenti, una nuova esperienza di creazione dei commenti e un'interfaccia utente completamente aggiornata.

Per altre informazioni, vedere l'argomento relativo alla revisione del codice con le richieste pull.

Interfaccia utente riprogettata

Quando si apre una richiesta pull, il nuovo aspetto grafico è immediatamente evidente (figura 21). L'intestazione è stata riorganizzata in modo da riepilogare tutte le azioni e gli stati più rilevanti, rendendoli accessibili da tutte le viste dell'esperienza.

Pull request header

(Figura 21) Intestazione della richiesta pull

Panoramica

La panoramica evidenzia ora la descrizione della richiesta pull e rende più semplice che mai fornire commenti e suggerimenti (figura 22). Gli eventi e i commenti vengono visualizzati con gli elementi più recenti nella parte superiore per consentire ai revisori di visualizzare le modifiche e i commenti più recenti in primo piano. Criteri, elementi di lavoro e revisioni sono tutti disponibili in dettaglio e riorganizzati in modo da essere più chiari e concisi.

Pull request overview

(Figura 22) Panoramica richiesta pull

File

La funzionalità più importante in questa versione è la possibilità di visualizzare le modifiche apportate a una richiesta pull (figura 23). Nelle anteprime precedenti, è stata rilasciata la possibilità di tenere traccia dei commenti non appena una richiesta pull veniva modificata. Tuttavia, non è sempre facile vedere cosa è avvenuto tra un aggiornamento e l'altro. Nella vista File è ora possibile visualizzare esattamente l'oggetto della modifica ogni volta che viene inserito nuovo codice nella richiesta pull. Si tratta di un'opzione molto utile se sono stati forniti commenti e suggerimenti sul codice e si vuole visualizzare esattamente tale modifica, indipendentemente dalle altre modifiche apportate alla revisione.

Pull request files

(Figura 23) File richiesta pull

Aggiornamenti

La nuova visualizzazione Aggiornamenti viene usata per mostrare i cambiamenti della richiesta pull nel tempo (figura 24). Mentre la vista File consente di visualizzare i cambiamenti dei file nel tempo, la vista Aggiornamenti illustra i commit aggiunti in ogni aggiornamento. Se si verifica un force push, la vista Aggiornamenti continuerà a mostrare gli ultimi aggiornamenti in ordine cronologico.

Pull request updates

(Figura 24) Aggiornamenti richiesta pull

Commenti con markdown ed emoji

Usare tutte le potenzialità del markdown in tutte le discussioni, incluse quelle relative a formattazione, codice con evidenziazione della sintassi, collegamenti, immagini ed emoji (figura 25). Anche i controlli sui commenti dispongono di un'esperienza di modifica più descrittiva che consente di modificare (e quindi salvare) più commenti contemporaneamente.

Pull request comments

(Figura 25) Commenti richiesta pull

Aggiungere e rimuovere revisori nelle richieste pull

È ora più semplice aggiungere e rimuovere revisori dalle richieste pull. Per aggiungere un revisore o un gruppo alla richiesta pull, è sufficiente immetterne il nome nella casella di ricerca nella sezione Revisori. Per rimuovere un revisore, passare il puntatore sul riquadro corrispondente nella sezione Revisori e fare clic sulla X per rimuoverlo (figura 26).

Add reviewers in pull requests

(Figura 26) Aggiungere revisori alle richieste pull

Miglioramenti alla tracciabilità di richieste pull e compilazioni

La tracciabilità tra compilazioni e richieste pull è stata migliorata ed è ora possibile passare da una richiesta pull a una compilazione e viceversa. Nella visualizzazione Dettagli compilazione per una compilazione attivata da una richiesta pull, l'origine mostrerà ora un collegamento alla richiesta pull che ha accodato la compilazione. Nella visualizzazione Definizioni di compilazione, qualsiasi compilazione attivata da una richiesta pull fornirà un collegamento alla richiesta pull nella colonna "Attivata da". Infine, nella visualizzazione per l'esplorazione delle compilazioni saranno elencate le richieste pull nella colonna di origine.

Rilevamento dei commenti per le richieste pull

In VSTS la funzionalità relativa alle richieste pull è stata migliorata in modo da visualizzare sulla riga appropriata i commenti presenti nei file, anche se questi ultimi sono stati modificati dopo l'aggiunta dei commenti. Nelle versioni precedenti i commenti vengono sempre visualizzati sulla riga del file in cui sono stati aggiunti in origine, anche se il contenuto del file viene modificato. In altre parole, un commento sulla riga 10 rimane sempre visualizzato su tale riga. Con i miglioramenti introdotti di recente, i commenti seguono il codice in modo da visualizzare ciò che si aspetta l'utente. In altre parole, se si inserisce un commento sulla riga 10 e successivamente si aggiungono due nuove righe all'inizio del file, il commento verrà visualizzato sulla riga 12.

Ecco un esempio di modifica con un commento alla riga 13 (Figura 27):

Comment tracking

(Figura 27) Rilevamento dei commenti

Anche dopo che il codice è stato modificato e il testo con il commento originale si è spostato dalla riga 13 alla 14, il commento viene visualizzato nella posizione prevista, ossia sulla riga 14 (figura 28).

Comment tracking with change

(Figura 28) Rilevamento dei commenti modificati

Completamento automatico delle richieste pull in attesa su criteri

I team che usano i criteri ramo (https://www.visualstudio.com/it-it/docs/git/branch-policies) per proteggere i rami dovranno controllare l'azione di completamento automatico. In molti casi, l'autore di una richiesta pull è pronto per l'unione delle richieste pull, ma deve rimanere in attesa del completamento di una compilazione prima di poter selezionare Completa. In altri casi, la compilazione viene passata, ma un revisore non ha ancora concesso l'approvazione finale. In questi casi, l'azione di completamento automatico consente all'autore di impostare la richiesta pull per il completamento automatico non appena i criteri vengono tutti soddisfatti (figura 29).

Auto-complete

(Figura 29) Completamento automatico

Come per l'azione di completamento manuale, l'autore ha la possibilità di personalizzare il messaggio del commit di merge e selezionare le opzioni di merge appropriate (figura 30).

Autodialog

(Figura 30) Finestra di dialogo del completamento automatico

Dopo l'impostazione del completamento automatico, la richiesta pull visualizza un messaggio che conferma l'impostazione e comunica l'attesa del completamento dei criteri (figura 31).

Auto-complete confirmation

(Figura 31) Conferma completamento automatico

Una volta soddisfatti tutti i criteri (ad esempio, la compilazione è stata completata o l'approvazione finale è stata concessa), viene eseguito il merge della richiesta pull usando le opzioni e i commenti specificati. Come previsto, se si verifica un errore di compilazione o il revisore non concede l'approvazione, la richiesta pull rimane attiva fino a quando non vengono passati i criteri.

Eseguire il merge con squash delle richieste pull

Una volta completata una richiesta pull, è ora disponibile un'opzione per eseguire il merge con squash (figura 32). Questa nuova opzione genererà un singolo commit contenente le modifiche del ramo a tema che verrà applicato al ramo di destinazione. La differenza più evidente tra una normale operazione di merge e un'operazione di merge con squash consiste nel fatto che il commit di tipo merge con squash prevede un solo commit padre. Ciò determina la visualizzazione di un grafico della cronologia più semplice, poiché gli eventuali commit intermedi effettuati nel ramo a tema non saranno raggiungibili nel grafico del commit risultante.

Squash merge pull request

(Figura 32) Merge con squash della richiesta pull

Altre informazioni sono disponibili in Eseguire il merge con squash delle richieste pull.

Tracciabilità del commit

Lo stato della compilazione (esito positivo o negativo) è ora chiaramente visibile nella visualizzazione Dettagli commit e in quella per l'esplorazione del codice (figura 33). Altri dettagli sono facilmente visualizzabili ed è quindi sempre possibile sapere se le modifiche nel commit hanno superato la fase di compilazione. È inoltre possibile specificare le compilazioni per le quali viene registrato lo stato nelle opzioni di repository per la definizione di compilazione. Inoltre, gli aggiornamenti più recenti alla visualizzazione Dettagli commit consentono di mostrare informazioni più approfondite sulle modifiche apportate. Se si usano richieste pull per il merge delle modifiche, è possibile visualizzare il collegamento alla richiesta pull che ha introdotto le modifiche nel ramo master (o, nel caso di un commit con merge, la richiesta pull che l'ha creato). Quando le modifiche hanno raggiunto il master, verrà visualizzato il collegamento del ramo per verificare che siano state incluse le modifiche.

Commit Traceability

(Figura 33) Tracciabilità del commit

Visualizzare i file Git LFS nel Web

Se si sta già lavorando con file di grandi dimensioni in Git (audio, video, set di dati e così via), si è già a conoscenza del fatto che Git Large File Storage (LFS) sostituisce tali file con puntatori all'interno di Git e archivia il contenuto dei file in un server remoto. In questo modo è possibile visualizzare il contenuto completo dei file di grandi dimensioni facendo semplicemente clic sul file nel repository.

Per altre informazioni, vedere l'argomento relativo alla gestione di file di grandi dimensione con Git.

È possibile condividere facilmente riferimenti al codice con appositi collegamenti (figura 34). È sufficiente selezionare il testo in un file e fare clic sull'icona Collegamento. In questo modo verrà copiato un collegamento al codice selezionato. Quando un altro utente visualizzerà tale collegamento, il codice evidenziato avrà uno sfondo di colore oro. Funziona anche per le selezioni di riga parziali.

Send links to code

(Figura 34) Inviare collegamenti al codice

API dello stato

L'esito positivo o negativo della compilazione è ora chiaramente visibile nella visualizzazione dei dettagli del commit e in quella per l'esplorazione del codice (figura 35). Altri dettagli sono facilmente visualizzabili ed è quindi sempre possibile sapere se le modifiche nel commit hanno superato la fase di compilazione. È inoltre possibile specificare le compilazioni per le quali viene registrato lo stato nelle opzioni di repository per la definizione di compilazione.

Status API

(Figura 35) API dello stato

Icone del tipo di file

Nuove icone di file corrispondenti all'estensione del file sono ora presenti nelle visualizzazioni per l'esplorazione del codice, le richieste pull, i dettagli del commit, gli shelveset e gli insiemi di modifiche o in qualsiasi altra visualizzazione contenente un elenco di file (figura 36).

File type example

(Figura 36) Esempi di tipi di file

Aggiungere un file leggimi durante la creazione di repository

La funzionalità per la creazione di nuovi repository Git è stata migliorata e offre ora agli utenti la possibilità di aggiungere un file leggimi (figura 37). Aggiungendo un file leggimi al repository, lo sviluppatore non solo può illustrare agli altri lo scopo della codebase, ma può anche clonare immediatamente il repository.

Add a ReadMe file

(Figura 37) Aggiungere un file ReadMe

Miglioramenti alla compilazione

Tra i miglioramenti introdotti in questa versione, è stata aumentata la dimensione dei log, sono stati aggiunti modelli di compilazione Java ed è stato migliorato il supporto Xamarin.

Scheda della coda di compilazione riprogettata

La pagina Compilazioni in coda è stata riprogettata in modo da mostrare un elenco di compilazioni in coda e in esecuzione più completo e intuitivo (figura 38).

Build queue tab

(Figura 38) Scheda coda compilazioni

Per altre informazioni, vedere l'argomento relativo all'amministrazione del sistema di compilazione.

Abilitare le estensioni dei risultati di compilazione per specificare l'ordine e la colonna

Le estensioni della sezione dei risultati di compilazione possono ora specificare la colonna e l'ordine in cui appaiono (figura 39). La visualizzazione dei risultati include due colonne e tutte le estensioni si trovano nella prima colonna per impostazione predefinita. Nota: tutte le estensioni di terze parti vengono visualizzate dopo le sezioni dei risultati di compilazione incluse.

Build order and column

(Figura 39) Colonna e ordine di compilazione

Da compilazione a numero di riga

È ora possibile passare da un errore di compilazione alla riga di codice che lo ha generato. Se si esamina l'errore più recente sulla compilazione primaria che viene usata internamente come criterio di richiesta pull, si vedrà quanto segue (figura 40):

Build to line number

(Figura 40) Da compilazione a numero di riga

Log più grandi nella visualizzazione dei log di compilazione

Nella precedente visualizzazione dei log sono supportati log con un massimo di 10.000 righe. Il nuovo visualizzatore è basato sull'editor Monaco usato nel codice di Visual Studio e supporterà log con un massimo di 150.000 righe.

Modelli di compilazione Java

È adesso ancora più facile per gli sviluppatori Java eseguire operazioni di compilazione grazie ai modelli per Ant, Maven e Gradle (figura 41).

Java build templates

(Figura 41) Modelli di compilazione Java

Per altre informazioni sui modelli, vedere Istruzioni di compilazione.

Attività di compilazione Xamarin

Sono stati apportati notevoli miglioramenti al supporto Xamarin:

Il passaggio della licenza Xamarin non è più necessario ed è stato rimosso dai modelli di compilazione. Di conseguenza, verrà deprecata anche l'attività correlata. Tutte le definizioni di compilazione che usano questa attività devono essere aggiornate per rimuoverla, in modo da evitare interruzioni quando l'attività viene rimossa.

Infine, i modelli di definizione di compilazione Xamarin sono stati migliorati per consentire l'uso di queste nuove attività. Build your Xamarin app (Compilare l'app Xamarin).

Integrazione di Docker per la gestione di compilazioni e versioni

È possibile sfruttare le funzionalità di compilazione per compilare le immagini Docker e caricarle nell'hub Docker come parte del flusso di integrazione continua (figura 42). Distribuire quindi tali immagini a una serie di host Docker come parte delle attività di Release Management. L'estensione Marketplace aggiunge tutti i tipi di endpoint di servizio e le attività necessarie per usare Docker.

Docker images

(Figura 42) Immagini Docker

Risultati di SonarQube nella visualizzazione delle richieste pull

Se la compilazione per il merge di una richiesta pull contiene attività MSBuild di SonarQube, è ora possibile visualizzare nuovi problemi di analisi del codice come commenti nella richiesta pull (figura 43). Questa visualizzazione è possibile per le lingue per cui è installato un plug-in nel server SonarQube. Per altre informazioni, vedere il post di blog SonarQube Code Analysis issues integration into Pull Requests (Integrazione di problemi di analisi del codice SonarQube nelle richieste pull).

SonarQube pull requests

(Figura 43) SonarQube nelle richieste pull

Configurare la generazione di report nell'API di stato per una definizione di compilazione

È ora possibile scegliere le definizioni di compilazione che generano report sullo stato da inviare all'API di stato Git. Questa funzionalità è particolarmente utile se sono presenti numerose definizioni che compilano un determinato repository o ramo, ma solo una rappresenta lo stato reale.

Per altre informazioni, vedere l'argomento relativo alle informazioni di riferimento sulle API REST.

Supporto per Build vNext nei chat team

È stato sempre possibile aggiungere notifiche relative alle compilazioni XAML nel chat team. Con questo sprint, gli utenti possono anche ricevere notifiche da completamenti Build vNext.

Abilitare i filtri di percorso per i trigger CI di Git

I trigger CI per repository Git ospitati possono includere o escludere determinati percorsi. È così possibile configurare una definizione di compilazione in modo che venga eseguita solo quando sono stati modificati file in percorsi specifici (figura 44).

Git CI Triggers

(Figura 44) Trigger CI per Git

Miglioramenti a Release Management

Dall'introduzione del servizio integrato Release Management basato sul Web in Team Foundation Server 2015, sono stati apportati numerosi miglioramenti in questa versione.

Clonare, esportare e importare definizioni di versione

Sono ora disponibili funzionalità per clonare, esportare e importare definizioni di versione all'interno dell'hub Release, senza richiedere l'installazione di un'estensione (figura 45).

Clone and export commands on release summary page

(Figura 45) Comandi per la clonazione e l'esportazione nella pagina di riepilogo della versione

Per altre informazioni, vedere il documento Clone, export, and import a release definition (Clonare, esportare e importare una definizione di versione).

Risultati dei test visualizzati nel riepilogo versione

Nella pagina di riepilogo della versione, abbiamo abilitato un punto di aggiunta contributo per un servizio esterno per mostrare informazioni specifiche dell'ambiente.

In Team Services questa funzionalità viene usata per visualizzare un riepilogo dei risultati di test quando i test vengono eseguiti come parte di un ambiente di versione (figura 46).

Test results displayed in the release summary

(Figura 46) Risultati dei test visualizzati nel riepilogo versione

Per altre informazioni, vedere la documentazione Understand the summary view of a release (Informazioni sulla vista di riepilogo di una versione).

Passare i token OAuth agli script

Se è necessario eseguire uno script PowerShell personalizzato che richiama le API REST su Team Services, ad esempio per creare un elemento di lavoro o eseguire query su una compilazione per cercare informazioni, è necessario passare il token OAuth nello script.

Una nuova opzione disponibile quando si configura un ambiente consente di eseguire gli script come attività nell'ambiente per accedere al token OAuth corrente (figura 47).

Pass OAuth tokens to scripts

(Figura 47) Passare i token OAuth agli script

Per altre informazioni, vedere la documentazione Environment general options (Opzioni generali dell'ambiente).

Questo semplice esempio illustra come ottenere una definizione di compilazione (figura 48):

Example script using passed oAuth token

(Figura 48) Script di esempio con token OAuth passato

Attivare in base a distribuzioni parzialmente completate

Per le attività di compilazione e rilascio, in Opzioni di controllo è disponibile il parametro Continua in caso di errore.

In una definizione di compilazione, se un'attività con questa opzione impostata ha esito negativo, viene restituito il messaggio Compilazione completata parzialmente.

Lo stesso comportamento è ora disponibile anche per le definizioni di versione. Se un'attività non riesce, la versione risulterà parzialmente completata (figura 49).

Release summary shows partially successful releases in orange color

(Figura 49) Schermata di riepilogo con versioni parzialmente completate di colore arancione

Per impostazione predefinita, una versione parzialmente completata non attiva automaticamente una distribuzione di versione in un ambiente successivo, anche se questo comportamento è specificato nelle opzioni di distribuzione dell'ambiente.

In ogni ambiente di versione è tuttavia possibile impostare una nuova opzione che indica a Release Management di attivare una distribuzione di versione in un ambiente successivo quando quella precedente è parzialmente completata (figura 50).

Setting the option to trigger from a partially successful release

(Figura 50) Impostazione dell'opzione per attivare una distribuzione di versione a partire da una versione parzialmente completata

Per altre informazioni, vedere la documentazione Environment deployment triggers (Trigger della distribuzione dell'ambiente).

Utilizzare direttamente gli elementi archiviati in GitHub

Talvolta può essere opportuno usare direttamente gli artefatti archiviati in un sistema di controllo della versioni, senza passare attraverso un processo di compilazione, come descritto in questo argomento.

Questa operazione è ora possibile anche se il codice è archiviato in un repository GitHub (figura 51).

Linking code in a GutHub repository to a release definition

(Figura 51) Collegamento del codice in un repository GitHub a una definizione di versione

Per altre informazioni, vedere la documentazione TFVC, Git, and GitHub sources (Origini TFVC, Git e GitHub).

Distribuzione di app Web con ARM

È disponibile una nuova versione dell'attività della distribuzione di app Web di Azure denominata Distribuzione app Web AzureRM (figura 52).

Usa MSDeploy e una connessione dell'endpoint del servizio Azure Resource Manager. Usare questa attività per distribuire i processi Web di Azure e le app per le API di Azure, oltre alle app Web basate su ASP.NET 4, Node e Python.

L'attività supporta anche opzioni di pubblicazione comuni, ad esempio la possibilità di conservare i dati dell'app, eseguire un'app offline e rimuovere i file aggiuntivi nella destinazione.

Altre funzionalità, ad esempio le trasformazioni di configurazione, potrebbero essere introdotte in versioni future (figura 52).

Web app deployment using ARM

(Figura 52) Distribuzione di app Web con ARM

Gruppi di attività

Un gruppo di attività consente di incapsulare una sequenza di attività già definita in una definizione di versione o di compilazione in una singola attività riutilizzabile che può essere aggiunta a una definizione di versione o di compilazione come qualsiasi altra attività (figura 53).

È possibile scegliere di estrarre i parametri dalle attività incapsulate come variabili di configurazione e astrarre il resto delle informazioni sull'attività.

Il nuovo gruppo di attività viene aggiunto automaticamente al catalogo di attività, pronto per essere aggiunto ad altre definizioni di compilazione e di versione.

Linking code in a GutHub repository to a release definition

(Figura 53) Collegamento del codice in un repository GitHub a una definizione di versione

Per altre informazioni, vedere la documentazione Task Groups (Gruppi di attività).

Eliminazione temporanea di versioni

Quando viene eliminata manualmente o automaticamente da un criterio di conservazione, la versione viene rimossa dagli elenchi di panoramica e di dettagli.

Viene tuttavia conservata con la definizione di versione per un periodo, in genere di 14 giorni, prima dell'eliminazione definitiva.

In questo periodo la versione viene indicata nella scheda Eliminato degli elenchi di panoramica e dei dettagli.

È possibile ripristinare una di queste versioni aprendo il menu di scelta rapida e scegliendo Annulla Elimina (figura 54).

Undelete releases

(Figura 54) Annullare l'eliminazione di versioni

Per altri dettagli, vedere la documentazione Restore deleted releases (Ripristinare versioni eliminate).

Conservare le versioni e le compilazioni per ogni ambiente

I criteri di conservazione delle versioni per una definizione di versione determinano il tempo per il quale una versione e la compilazione collegata vengono conservate.

Per impostazione predefinita, una versione viene conservata per 60 giorni; le versioni che non vengono distribuite o modificate durante questo periodo verranno eliminate automaticamente.

Tuttavia, è possibile mantenere più versioni che sono state distribuite in ambienti specifici, ad esempio l'ambiente di produzione, o conservarle più a lungo di quelle che sono state appena distribuite in altri ambienti, ad esempio quelli di test, di gestione temporanea e di controllo di qualità.

È possibile anche conservare la compilazione collegata a una versione per lo stesso periodo della versione per garantirne la disponibilità degli artefatti, se si vuole ridistribuire questa versione (figura 55).

Retain releases

(Figura 55) Conservare le versioni

Per altri dettagli, vedere la documentazione Release and build retention (Mantenimento di versioni e compilazioni).

Miglioramenti degli artefatti collegati

Due nuove funzionalità rendono più facile lavorare con gli artefatti e le relative origini:

  • È possibile collegare più origini di artefatti alla definizione di una versione (figura 56). Ogni artefatto viene scaricato in una cartella sull'agente, il cosiddetto alias di origine. È ora possibile modificare l'alias di origine di un artefatto collegato. Ad esempio, quando si modifica il nome della definizione di compilazione, è possibile modificare l'alias di origine in modo da riflettere il nome della definizione di compilazione.

Linked artifact improvements

(Figura 56) Miglioramenti degli artefatti collegati

For more details, see [Artifact source alias](https://www.visualstudio.com/en-us/docs/release/author-release-definition/understanding-artifacts#source-alias) documentation.
  • Una serie di variabili nel formato Build.*, ad esempio Build.BuildId e Build.BuildNumber, viene esposta per l'uso nei parametri dell'attività. Quando più origini sono associate a una versione, queste variabili vengono ora popolate con i valori dall'origine dell'artefatto specificato come origine principale. Per altri dettagli, vedere la documentazione Artifact variables (Variabili di artefatti).

Distribuzione: attività di intervento manuale

È ora possibile sospendere l'esecuzione durante la distribuzione in un ambiente.

L'inclusione di un'attività di intervento manuale in un ambiente consente di interrompere temporaneamente una distribuzione, eseguire operazioni manuali e quindi riprendere ulteriori passaggi automatizzati.

È possibile anche rifiutare la distribuzione e impedire l'esecuzione di altri passaggi dopo un intervento manuale (figura 57).

Manual intervention task

(Figura 57) Attività di intervento manuale

Per altri dettagli, vedere la documentazione Manual intervention (Intervento manuale).

Script dell'attività di distribuzione del database SQL

L'attività Distribuzione database SQL di Azure (figura 58) è stata migliorata per eseguire script SQL in un database SQL di Azure. Gli script possono essere forniti come file o inline all'interno dell'attività.

SQL database deployment task scripts

(Figura 58) Script dell'attività di distribuzione del database SQL

Riepilogo delle definizioni di versione - widget del dashboard

La possibilità di aggiungere una definizione di versione al dashboard offre una soluzione semplice per rendere visibili a tutti i membri del team un riepilogo delle versioni per tale definizione.

Per altri dettagli, vedere la documentazione Add release information to the dashboard (Aggiungere informazioni sulle versioni al dashboard).

Impostare la distribuzione di versioni in un ambiente a una determinata ora

Si vuole impostare l'esecuzione di tutte le distribuzioni di produzione a mezzanotte? È possibile configurare, in un determinato ambiente, una condizione che seleziona una distribuzione completata (o semplicemente la più recente) da un altro ambiente e la esegue all'ora specificata (figura 59).

Schedule release to an environment

(Figura 59) Pianificare la distribuzione di versioni in un ambiente

Distribuire in più ambienti in base a condizioni

Nelle versioni precedenti è possibile eseguire distribuzioni in parallelo (distribuzioni di tipo fork), ma non è possibile avviare una distribuzione in un ambiente in base allo stato di più ambienti (distribuzioni di tipo join). Ora è possibile usare anche questa modalità di distribuzione.

Per altri dettagli, vedere la documentazione Parallel forked and joined deployments (Distribuzioni di tipo fork e join in parallelo).

API REST per Release Management

È possibile usare le API REST per il servizio Release Management per creare versioni e definizioni di versione e gestire molti aspetti della distribuzione di una versione.

Per altre informazioni, vedere la documentazione di riferimento delle API. Alcuni esempi di base in cui vengono usate le API sono disponibili in questo post di blog, Using ReleaseManagement REST API's (Uso delle API REST di Release Management).

Integrazione di hook del servizio

È possibile inviare notifiche di rilascio quando vengono create nuove versioni, quando vengono avviate o completate distribuzioni o quando sono presenti approvazioni in sospeso o completate. La funzionalità di ricezione delle notifiche può essere integrata anche con strumenti di terze parti, ad esempio Slack.

Distribuzione nei cloud in ambito nazionale di Azure

Usare la nuova impostazione di ambiente in un endpoint del servizio di Azure classico per un cloud di Azure specifico, tra cui i cloud nazionali predefiniti, come il cloud in Cina di Azure, il cloud del governo degli Stati Uniti di Azure e il cloud in Germania di Azure (figura 60).

Deployment to national Azure clouds

(Figura 60) Distribuzione nei cloud nazionali di Azure

Per altri dettagli, vedere la documentazione Azure Classic service endpoint (Endpoint servizio Azure classico).

Miglioramenti ai test

In Team Foundation Server 2017 sono stati introdotti alcuni miglioramenti fondamentali relativi ai test.

Schema di archiviazione dei risultati dei test aggiornato

In questa versione, gli artefatti relativi ai risultati dei test sono stati migrati in un nuovo schema di archiviazione compatto ed efficiente. Poiché i risultati dei test sono la principale causa del consumo di spazio di archiviazione nei database TFS, si presume che questa funzionalità abbia l'effetto di ridurre il footprint di archiviazione per i database TFS. Per i clienti che eseguono l'aggiornamento da precedenti versioni di TFS, i risultati dei test verranno migrati al nuovo schema durante l'aggiornamento di TFS. Questo può comportare lunghi tempi di aggiornamento a seconda della quantità di dati relativi ai risultati dei test nei database. È consigliabile configurare criteri di conservazione dei test e attendere l'attivazione dei criteri per ridurre lo spazio di archiviazione usato dai risultati dei test e rendere così più veloce l'aggiornamento di TFS. Dopo aver installato TFS, ma prima di aver aggiornato l'istanza di TFS, è possibile usare lo strumento TFSConfig.exe per pulire i risultati dei test. Per altre informazioni dettagliate, vedere la Guida di TFSConfig.exe. Se non si ha la flessibilità adeguata per configurare la conservazione dei test o pulire i risultati dei test prima dell'aggiornamento, verificare di eseguire una pianificazione appropriata per la finestra di aggiornamento. Vedere Test result data retention with Team Foundation Server 2015 (Conservazione dei dati relativi ai risultati dei test con Team Foundation Server 2015) per altri esempi sulla configurazione dei criteri di conservazione dei test.

Miglioramenti all'hub di test

Gestione della configurazione dei test nell'hub di test

Nell'interfaccia utente Web è stata introdotta una funzionalità di gestione della configurazione dei test con una nuova scheda Configurazioni nell'hub di test (figura 61). È ora possibile creare e gestire le configurazioni dei test e testare le variabili di configurazione direttamente nell'hub di test.

Configurations hub

(Figura 61) Hub delle configurazioni

Per altre informazioni, vedere Create configurations and variables (Creare configurazioni e variabili).

Assegnazione di configurazioni a piani di test, gruppi di test e test case

L'assegnazione di configurazioni è ora più semplice che mai. È possibile assegnare configurazioni di test a un piano di test, a un gruppo di test e a uno o più test case direttamente dall'hub di test (figura 62). Basta fare clic con il pulsante destro del mouse su un elemento e scegliere Assegna configurazioni a (per piano di test, gruppo di test o test case selezionati). È anche possibile filtrare in base alle configurazioni nell'hub di test (figura 63).

Assign Configurations

(Figura 62) Assegnare configurazioni

Configurations Filter

(Figura 63) Filtro configurazioni

Per altre informazioni, vedereAssign configurations to test plans and suites (Assegnare le configurazioni a piani di test e gruppi di test).

Visualizzare le colonne del piano o del gruppo di test nel riquadro Risultati test

Nel riquadro Risultati test sono state aggiunte nuove colonne che mostrano il piano e il gruppo di test per i quali sono stati generati i risultati dei test. Queste colonne forniscono informazioni sul contesto che sono utili quando si esaminano i risultati dei test (figura 64).

Test Results Pane

(Figura 64) Riquadro Risultati test

Ordinamento dei test nell'hub di test e nelle schede

È ora possibile ordinare i test manuali dall'hub di test (figura 65), indipendentemente dal tipo di gruppo in cui sono inclusi: gruppi statici, basati su requisiti o basati su query. Per riordinare i test è sufficiente trascinare la selezione di uno o più test o usare il menu di scelta rapida. Al termine dell'ordinamento, è possibile ordinare i test in base al campo Ordine e quindi eseguirli nell'ordine specificato da Web Runner. È anche possibile ordinare i test direttamente nella scheda di una storia utente sulla lavagna Kanban (figura 66). Questo consente di risolvere uno degli elementi di User Voice che è rimasto a lungo in sospeso (con 495 voti) nella sezione relativa ai test manuali.

Order tests

(Figura 65) Ordinare i test

Order tests on card

(Figura 66) Ordinare i test nella scheda

Ordinare i gruppi di test nell'hub di test

I team di test possono ora ordinare i gruppi di test in base alle proprie esigenze. Nelle versioni precedenti in cui non è presente questa funzionalità, i gruppi vengono ordinati solo alfabeticamente. Nella versione attuale usando la funzionalità di trascinamento della selezione nell'hub di test, è possibile riordinare un gruppo tra gruppi peer oppure spostarlo in un altro gruppo nella gerarchia (figura 67). Questo aggiornamento consente di risolvere il problema segnalato su User Voice nella sezione relativa alla gestione di test case/testing manuale.

Order Test suites

(Figura 67) Ordinamento dei gruppi di test

Cercare utenti durante l'assegnazione di tester

Come parte della distribuzione di nuovi controlli di selezione di identità tra i diversi hub, nell'hub di test è stata abilitata anche l'opzione che consente di cercare gli utenti quando si assegnano tester a uno o più test (figura 68). Questa opzione è estremamente utile negli scenari in cui il team è composto da numerosi membri, ma il menu di scelta rapida visualizza un gruppo limitato di voci *(figura 69).

Search users

(Figura 68) Ricercare utenti

Assign Users

(Figura 69) Assegnare gli utenti

Selezionare una compilazione per il test

È ora possibile selezionare la compilazione da testare e quindi avviare il runner Web usando "Esegui con opzioni" nell'hub di test (figura 70). Eventuali bug segnalati durante l'esecuzione verranno associati automaticamente alla compilazione selezionata. Inoltre, i risultati del test verranno pubblicati per la specifica compilazione.

Pick a build

(Figura 70) Selezionare una compilazione

Avviare il client di Microsoft Test Runner dall'hub di test con gli agenti di raccolta dati

È ora possibile scegliere gli agenti di raccolta dati e la compilazione da associare all'esecuzione del test (figura 71) e quindi avviare rapidamente Microsoft Test Runner 2017 (client) dall'hub di test, senza che sia necessario configurarli nel client di Microsoft Test Manager. Microsoft Test Runner verrà avviato senza aprire l'intera shell di Microsoft Test Manager e verrà arrestato al termine dell'esecuzione del test.

Run with options

(Figura 71) Eseguire con opzioni

Per altre informazioni, vedere Run tests for desktop apps (Eseguire test per app desktop).

Scegliere il client degli agenti di raccolta dati e dell'avvio di Exploratory Runner dall'hub di test

È ora possibile scegliere gli agenti di raccolta dati e avviare Exploratory Runner 2017 (client) dall'hub di test, senza che sia necessario configurarli nel client di Microsoft Test Manager. Richiamare 'Esegui con opzioni' dal menu di scelta rapida (figura 72) per un gruppo basato su requisiti e scegliere Exploratory Runner e gli agenti di raccolta dati necessari. Exploratory Runner verrà avviato in modo analogo a Microsoft Test Runner come descritto in precedenza.

Run with Options - XT

(Figura 72) Eseguire con opzioni - XT

Configurare i risultati dei test per i test in gruppi di test diversi

È stata aggiunta la possibilità di configurare il comportamento dei risultati dei test per test condivisi tra gruppi di test diversi nello stesso piano di test (figura 73). Se questa opzione è selezionata e si imposta il risultato di un test (contrassegnarlo come Superato/Non superato/Bloccato dall'hub di test, dal runner Web, da Microsoft Test Runner o dalle schede nella lavagna Kanban), tale risultato verrà propagato a tutti gli altri test presenti in gruppi di test diversi nello stesso piano di test, con la stessa configurazione. Gli utenti possono impostare l'opzione "Configura impostazioni per risultati dei test" per un piano di test specifico dal menu di scelta rapida del piano di test dell'hub di test o dalla pagina di test della lavagna Kanban nella finestra di dialogo di configurazione delle impostazioni comuni. Questa opzione è disattivata per impostazione predefinita e sarà necessario abilitarla in modo esplicito per renderla effettiva.

Configure test outcomes

(Figura 73) Configurare i risultati dei test

Verificare i bug dall'elemento di lavoro

È ora possibile verificare un bug eseguendo di nuovo i test che hanno identificato il bug (figura 74). È possibile richiamare l'opzione di verifica dal menu di scelta rapida del form dell'elemento di lavoro bug per avviare il test case corrispondente nel runner Web. Eseguire la convalida tramite il runner Web e aggiornare l'elemento di lavoro bug direttamente all'interno del runner Web.

Verify bugs

(Figura 74) Verificare i bug

API REST per la clonazione di piani o gruppi di test

Sono state aggiunte API REST per la clonazione di piani e gruppi di test. È possibile trovarle nella sezione relativa alla gestione dei test nel sito di integrazione di Team Services.

Stato di avanzamento del test dalle schede Kanban

È ora possibile aggiungere, visualizzare e interagire con i test case direttamente dalle storie sulla lavagna Kanban. Usare la nuova opzione di menu Aggiungi test per creare un test case collegato e quindi monitorare lo stato direttamente dalla scheda nel corso delle operazioni (figura 75).

Inline tests

(Figura 75) Test inline

Con questa nuova funzionalità, è ora possibile eseguire le azioni seguenti direttamente da una scheda sulla lavagna:

  • Aggiungere test.
  • Aprire test.
  • Associare un test a un nuovo elemento padre trascinando la selezione del test da una storia utente a un'altra.
  • Copiare lo stesso test in un'altra storia utente premendo CTRL mentre si trascina la selezione (per gli scenari in cui lo stesso test case viene applicato a più storie utente).
  • Aggiornare lo stato del test contrassegnandolo rapidamente come Superato, Non superato e così via.
  • Eseguire il test avviandolo in Web Test Runner, da cui è possibile superare o non superare singoli passi, segnalare bug così via.
  • Visualizzare un riepilogo dello stato di rollup in cui sono riportati il numero di test superati e il numero di test rimanenti per una determinata storia.

Se sono necessarie funzionalità avanzate per la gestione dei test (ad esempio, assegnazione di tester, assegnazione di configurazioni, parametri centralizzati, esportazione di risultati dei test e così via), è possibile passare all'hub di test e iniziare a usare i gruppi predefiniti, basati su piani o requisiti di test, che sono stati creati automaticamente per l'utente. Per altre informazioni, vedere l'argomento relativo ad aggiunta, esecuzione e aggiornamento dei test inline.

Passare a un piano/gruppo di test dalla scheda

È ora possibile passare facilmente al piano/gruppo di test in cui vengono creati i test, direttamente da una scheda sulla lavagna Kanban. Se si fa clic su questo collegamento (figura 76), verrà avviato l'hub di test e quindi verrà aperto il piano di test corretto e selezionato il gruppo che controlla gli specifici test inline.

Traverse to plan/suite

(Figura 76) Passare a un piano/gruppo

Pagina Test nella configurazione delle impostazioni comuni della lavagna Kanban

Usare la nuova pagina Test nella finestra di dialogo per la configurazione delle impostazioni comuni nella lavagna Kanban per controllare il piano di test in cui vengono creati i test inline (figura 77). Nelle versioni precedenti i test creati in una scheda vengono aggiunti automaticamente a un piano di test appena creato purché non siano presenti piani di test corrispondenti ai percorsi di area e iterazione della scheda. È ora possibile eseguire l'override di questo comportamento configurando un piano di test esistente. In questo modo, tutti i test vengono aggiunti al piano di test selezionato. Si noti che questa funzionalità è abilitata solo se è attivata l'annotazione di test.

Common settings

(Figura 77) Impostazioni comuni

Miglioramenti al runner Web

Aggiungere allegati ai passi del test durante il test manuale

Web Test Runner è stato migliorato per offrire la possibilità di aggiungere allegati ai passi del test durante il test manuale (figura 78). Questi allegati vengono visualizzati automaticamente nei bug segnalati nella sessione e successivamente nel riquadro Risultati test.

Test Step attachments

(Figura 78) Allegati ai passi del test

Supporto di screenshot, registrazione dello schermo, log delle azioni per immagini e informazioni di sistema nel runner Web (con il browser Chrome)

Quando si usa il runner Web con Chrome, è possibile acquisire schermate e aggiungervi annotazioni inline (figura 79). È possibile acquisire registrazioni dello schermo su richiesta non solo per le app Web, ma anche per le app desktop. Questi screenshot e registrazioni dello schermo vengono aggiunti automaticamente al passo del test corrente. Oltre agli screenshot e alle registrazioni dello schermo, è possibile anche acquisire log delle azioni per immagini su richiesta dalle app Web. È necessario specificare la finestra del browser in cui acquisire le azioni. Tutte le azioni eseguite in questa finestra, in qualsiasi scheda nuova o esistente aperta nella finestra o in qualsiasi finestra figlio avviata nel browser, vengono automaticamente acquisite e associate ai passi testati nel runner Web. Gli screenshot, le registrazioni dello schermo e i log delle azioni per immagini vengono quindi aggiunti ai bug segnalati durante l'esecuzione e associati al risultato del test corrente. Analogamente, le informazioni di sistema vengono automaticamente acquisite e incluse come parte dei bug segnalati da Web Runner. Vengono così sfruttate pienamente le funzionalità dell'estensione per il test e il feedback basati su Chrome.

Web runner using Chrome browser

(Figura 79) Runner Web con browser Chrome

Per altre informazioni, vedere Collect diagnostic data during tests (Raccogliere dati di diagnostica durante i test).

Bug segnalati come elementi figlio: estensione per il test e il feedback/runner Web

Quando si eseguono test in Web Runner, avviati da una scheda sulla lavagna o da un gruppo basato su requisiti nell'hub di test, i nuovi bug segnalati vengono ora creati automaticamente come figli della storia utente. Analogamente, se si esplora una storia utente dall'estensione per il testing esplorativo, i nuovi bug segnalati vengono anch'essi creati come figli della storia utente. Questo nuovo comportamento consente una tracciabilità più semplice in storie e bug. Questa opzione è disponibile solo se le "Gestione dei bug" nella pagina di configurazione delle impostazioni comuni è impostata a "I bug non vengono visualizzati nei backlog o nelle lavagne" o "I bug vengono visualizzati nei backlog e nelle lavagne con le attività". Per tutte le altre impostazioni dell'opzione "Gestione dei bug" e in alcuni altri scenari, ad esempio nel caso di aggiunta a un bug esistente per cui è già definito un elemento padre, viene creato in alternativa un collegamento correlato.

Aggiornare i bug esistenti dal runner Web

Oltre alla creazione di nuovi bug dal runner Web, è ora possibile aggiornare un bug esistente (figura 80). Tutti i dati di diagnostica raccolti, i passi di ripetizione bug e i collegamenti per la tracciabilità dalla sessione corrente vengono aggiunti automaticamente al bug esistente.

Add to existing bug

(Figura 80) Aggiungere al bug esistente

Estensione per il test e il feedback: miglioramenti

L'estensione per il test e il feedback basata su browser può essere installata da Visual Studio Marketplace. Supporta sia Visual Studio Team Services che Team Foundation Server (2015 o versione successiva).

Esplorare gli elementi di lavoro

È possibile eseguire il testing esplorativo per un elemento di lavoro specifico (figura 81). Ciò consente di associare l'elemento di lavoro selezionato alla sessione di test in corso e di visualizzare i criteri di accettazione e la descrizione dall'interno dell'estensione. Consente anche di creare una tracciabilità end-to-end tra i bug o le attività registrate nell'elemento di lavoro selezionato. È possibile esplorare l'elemento di lavoro direttamente da un elemento di lavoro oppure dall'interno dell'estensione:

• Direttamente da un elemento di lavoro (figura 81): avviare la sessione di testing esplorativo per un elemento di lavoro specifico direttamente dall'interno del prodotto tramite l'opzione "Esegui testing esplorativo" nel menu di scelta rapida. Sono stati aggiunti punti di ingresso in tutte le schede e griglie e nell'hub di test.

• All'interno dell'estensione (figura 82): cercare un elemento di lavoro dall'interno della sessione di testing esplorativo e quindi associarlo alla sessione in corso.

XT from card

(Figura 81) Testing esplorativo da elemento di lavoro

Explore work item

(Figura 82) Testing esplorativo dall'estensione

Per altre informazioni, vedere Explore work items with the Test & Feedback extension (Esplorare elementi di lavoro con l'estensione per il test e il feedback).

Acquisire log delle azioni per immagini, registrazioni dello schermo e dati di caricamento della pagina Web tramite l'estensione per il test e il feedback

Log delle azioni per immagini: l'estensione offre una nuova opzione per aggiungere automaticamente con un solo clic i passi che portano al bug. Selezionare l'opzione "Include image action log" (Includi log delle azioni per immagini) (figura 83) per acquisire le azioni del mouse, della tastiera e del touchscreen e aggiungere il testo e le immagini corrispondenti direttamente nel bug o nell'attività.

Registrazione dello schermo come video: l'estensione consente anche di acquisire registrazioni dello schermo su richiesta. Queste registrazioni possono essere acquisite non solo dalle app Web, ma anche dalle applicazioni desktop. È possibile configurare l'estensione per arrestare le registrazioni dello schermo e collegarle automaticamente a un bug che viene archiviato usando la pagina delle opzioni dell'estensione.

Dati di caricamento pagina: nell'estensione è stata introdotta una nuova funzionalità in background per l'acquisizione dei dati di caricamento delle pagine Web. Proprio come il log delle azioni con immagine acquisisce le azioni eseguite su un'app Web sotto forma di immagini in background, la funzionalità di caricamento delle pagine acquisisce automaticamente i dettagli relativi al completamento dell'operazione di caricamento di una pagina Web. Anziché basarsi sull'impressione soggettiva riguardo alla lentezza del caricamento di una pagina Web, è ora possibile quantificare oggettivamente il grado di lentezza nel bug. Una volta segnalato il bug, oltre alla visualizzazione affiancata, viene associato un report dettagliato che può essere utile allo sviluppatore per svolgere il set iniziale di indagini.

XT Image Action Log

(Figura 83) Log delle azioni per immagini del testing esplorativo

Creare test case in base ai dati del log delle azioni per immagini

È ora possibile creare test case durante la sessione esplorativa, inserendo automaticamente i passi del test per immagini (figura 84). La progettazione e l'esecuzione simultanee dei test sono alla base del testing esplorativo, ora facilmente attuabile grazie a questa nuova funzionalità. È possibile modificare il testo acquisito, aggiungere il risultato previsto, deselezionare le righe non pertinenti e salvare i dati per passate o esecuzioni di test futuri.

XT Create Test Cases

(Figura 84) Creare test case con il testing esplorativo

Per altre informazioni, vedere Creare test case in base ai dati del log delle azioni con immagine.

Approfondimenti sulle sessioni di testing esplorativo

È ora possibile visualizzare le sessioni di testing esplorativo completate, a livello individuale o di team, per un determinato periodo di tempo che sono state create mediante l'estensione per il test e il feedback. È possibile accedere a questa pagina di approfondimenti facendo clic sul collegamento "Recent exploratory sessions" (Sessioni di esplorazione recenti) nell'hub delle esecuzioni all'interno del gruppo dell'hub di test nel servizio di accesso Web. Questa nuova visualizzazione consente di ottenere informazioni significative, tra cui:

  • La visualizzazione di riepilogo che mostra una ripartizione degli elementi di lavoro esplorati, di quelli creati e dei proprietari delle sessioni, oltre al tempo totale impiegato in tali sessioni (figura 85).
  • La visualizzazione per gruppo che può essere trasformata tramite pivot in una visualizzazione degli elementi di lavoro esplorati, delle sessioni, dei proprietari delle sessioni o di nessun elemento. Per qualsiasi pivot, è possibile visualizzare sia l'elenco di tutti gli elementi di lavoro (bug, attività, test case) creati sia definire l'ambito dell'elenco fino a un particolare tipo di elemento di lavoro.
  • La visualizzazione del riquadro dei dettagli in cui sono riportate le informazioni in base alla selezione nella visualizzazione per gruppo. Per una riga pivot selezionata (come gli elementi di lavoro esplorati), è possibile visualizzare le informazioni di riepilogo nel riquadro dei dettagli, ad esempio il numero totale di sessioni, il tempo totale impiegato nelle sessioni, i proprietari delle sessioni che l'hanno esplorata, nonché i bug, le attività o i test case creati per tale riga, oltre allo stato e alla priorità. Per una riga di elemento di lavoro selezionata, è possibile visualizzare il form dell'elemento di lavoro inline e apportare le modifiche necessarie.

XT Session insights

(Figura 85) Approfondimenti sulle sessioni di testing esplorativo

Per altre informazioni, vedere Get insights across your exploratory testing sessions (Approfondimenti sulle sessioni di testing esplorativo).

Sessioni di testing esplorativo - Visualizzare elementi di lavoro non esplorati

Oltre a esaminare i dettagli di tutti gli elementi di lavoro esplorati nella visualizzazione delle sessioni di testing esplorativo recenti, filtrati in base a tutte le sessioni o alle sessioni personali per un determinato intervallo di date, nella stessa visualizzazione è ora possibile esaminare l'elenco di tutti gli elementi di lavoro che NON sono stati esplorati (figura 86). Si inizia specificando una query condivisa per gli elementi di lavoro a cui si è interessati. In questo modo, nella pagina delle sessioni viene visualizzato l'elenco di tutti gli elementi di lavoro restituiti dalla query, ripartiti tra esplorati e non esplorati nella sezione di riepilogo. Inoltre, usando il gruppo degli elementi di lavoro non esplorati, definito in base a pivot, è possibile visualizzare l'elenco degli elementi che non sono ancora stati esplorati. Questa funzionalità è estremamente utile per tenere traccia del numero di storie che non sono state esplorate o sottoposte a bug bash.

View unexplored WIT

(Figura 86) Visualizzare elementi di lavoro non esplorati

Flusso di feedback degli stakeholder end-to-end
Richiedere il feedback

Gli utenti con il livello di accesso base possono ora richiedere un feedback agli stakeholder direttamente per le funzionalità/storie in corso o completate tramite l'opzione Richiesta feedback nel menu dell'elemento di lavoro (figura 87). Verrà aperto il modulo di richiesta del feedback in cui è possibile scegliere gli stakeholder a cui si vuole richiedere il feedback e, facoltativamente, fornire una semplice serie di istruzioni specificando le aree del prodotto per cui si vogliono ottenere le informazioni. Verranno inviati singoli messaggi di posta elettronica agli stakeholder selezionati con le istruzioni fornite, se presenti.

XT Feedback Flow

(Figura 87) Flusso del feedback del testing esplorativo

Per altre informazioni, vedere Request stakeholder feedback using the Test & Feedback extension (Richiedere feedback agli stakeholder tramite l'estensione per il test e il feedback).

Fornire il feedback

Gli stakeholder possono rispondere alla richiesta di feedback selezionando il collegamento Richiesta feedback nel messaggio di posta elettronica ricevuto, che configura automaticamente l'estensione per il test e il feedback (in precedenza l'estensione per il testing esplorativo) con la richiesta di feedback selezionata; verrà richiesto di installare l'estensione, se non è già installata. Gli stakeholder possono usare le funzionalità di acquisizione complete dell'estensione per acquisire i loro risultati e inviare il feedback sotto forma di elementi di lavoro di attività/bug/risposta. Inoltre, gli stakeholder possono passare alla pagina "Richieste feedback" per visualizzare in un'unica posizione tutte le richieste di feedback ricevute. Dall'elenco possono selezionare la richiesta di feedback su cui intendono offrire il feedback, gestire le richieste di feedback in sospeso (figura 88) e contrassegnarle come completate o rifiutarle; possono anche passare tra diversi tipi di richieste di feedback facendo clic sul pulsante di opzione desiderato (figura 89).

Provide feedback link

(Figura 88) Offrire il collegamento al feedback

XT Feedback Flow

(Figura 89) Flusso del feedback del testing esplorativo

Per altre informazioni, vedere Provide feedback using the Test & Feedback extension (Inviare feedback tramite l'estensione per il test e il feedback).

Commenti e suggerimenti volontari

Oltre al flusso richiesto indicato in precedenza, gli stakeholder possono usare l'estensione anche per fornire commenti e suggerimenti volontari (figura 90). Possono aprire l'estensione, selezionare la modalità "Connesso" nella pagina delle impostazioni di connessione e connettersi all'account e al progetto/team a cui fornire i il feedback. Possono quindi usare l'estensione per acquisire i loro risultati e inviare il feedback sotto forma di elementi di lavoro di attività/bug/risposta.

Voluntary Feedback

(Figura 90) Commenti e suggerimenti volontari

Per altre informazioni, vedere Provide voluntary feedback using the Test & Feedback extension (Inviare feedback volontario tramite l'estensione per il test e il feedback).

Miglioramenti ai test automatizzati

Log della console e durata del test nella scheda Test nel riepilogo Compilazione e versione

I log della console con i risultati dei test acquisiti nei file con estensione trx vengono estratti e pubblicati come allegati ai risultati di test (figura 91). È possibile visualizzarli in anteprima nella scheda Test e non è più necessario scaricare il file con estensione trx per visualizzare i log.

Console logs and duration

(Figura 91) Log della console e durata

Widget relativo alla tendenza dei risultati dei test per le compilazioni

Nella raccolta dei widget è stato aggiunto un nuovo widget "Test result trend" (Tendenza risultati test) (figura 92). Questo widget è utile per aggiungere al dashboard un grafico della tendenza dei risultati dei test per un massimo di 30 compilazioni più recenti relative a una definizione di compilazione. Le opzioni di configurazione del widget consentono di personalizzare il grafico e includere elementi pivot, come il numero di test superati o quello di test non superati, il numero totale dei test, la percentuale di esiti positivi e la durata dei test.

'Test result trend' widget

(Figura 92) "Test result trend" (Tendenza risultati test)

Stato dei test con riepilogo degli ambienti di versione

È pratica consigliata usare ambienti di versione per distribuire applicazioni e sottoporle a test. In questa versione è stata introdotta la percentuale di superamento test degli ambienti di versione nella sezione Ambienti della pagina di riepilogo delle versioni (figura 93). Come illustrato nella schermata, se un ambiente risulta in errore, è possibile intuire rapidamente se l'errore è dovuto al mancato superamento di test esaminando la colonna Test. Per passare alla scheda Test e analizzare i test non superati per tale ambiente, è sufficiente fare clic sulla percentuale di superamento.

Test status with Release Environment summary

(Figura 93) Stato dei test con riepilogo degli ambienti di versione

Cronologia dei test automatizzati per rami e ambienti di versione

In genere un singolo test viene eseguito su più rami, ambienti e configurazioni. Quando il test ha esito negativo, è importante identificare se l'errore è contenuto nei rami di sviluppo, ad esempio il ramo master, o se gli errori hanno un impatto anche sui rami di versione distribuiti negli ambienti di produzione. È ora possibile visualizzare la cronologia di un test attraverso vari rami esaminando la scheda Cronologia nella pagina di riepilogo dei risultati (figura 94). Analogamente, è possibile raggruppare i risultati in base al pivot Ambiente per visualizzare la cronologia di un test nei diversi ambienti di versione in cui viene eseguito.

Test status with Release Environment summary

(Figura 94) Stato dei test con riepilogo degli ambienti di versione

Tracciabilità con il testing continuo

Gli utenti possono ora tenere traccia della qualità dei requisiti direttamente nel dashboard (figura 95). La soluzione per la qualità dei requisiti per gli utenti del testing pianificato è ora disponibile anche per gli utenti del testing continuo. Gli utenti potranno collegare i test automatizzati direttamente ai requisiti e quindi usare i widget del dashboard per tenere traccia della qualità dei requisiti a cui sono interessati durante il rilevamento e l'estrazione dei dati sulla qualità da Compilazione/Versione.

Requirement Quality Widget

(Figura 95) Widget relativo alla qualità dei requisiti

Testing remoto: distribuire test in base al numero di computer

È ora possibile distribuire a computer remoti i test relativi a un assembly usando l'attività Esegui test funzionali (figura 96). In TFS 2015 è possibile distribuire test solo a livello di assembly. Questa opzione può essere abilitata selezionando la casella di controllo nell'attività, come indicato di seguito.

Task Setting

(Figura 96) Impostazione di attività

Test automatizzati per SCVMM e VMWare

Gli utenti possono configurare in modo dinamico i computer di test nel cloud con Azure, o in locale mediante SCVMM o VMWare, e usare questi computer per eseguire i test in modalità distribuita. Possono inoltre usare una delle attività di provisioning dei computer (Azure, SCVMM o VMWare), seguita dall'attività Esegui test funzionali per l'esecuzione dei test.

Analisi SonarQube in attività Maven e Gradle

È ora possibile attivare un'analisi SonarQube nell'attività di compilazione Maven e Gradle selezionando "Esegui analisi SonarQube" e specificando l'endpoint, il nome del progetto SonarQube, la chiave di progetto e la versione (figura 97).

Run SonarQube Analysis

(Figura 97) Eseguire l'analisi SonarQube

Si otterrà anche un collegamento al progetto SonarQube (figura 98). È possibile richiedere un'analisi completa per visualizzare i dettagli dei quality gate e scegliere di interrompere la compilazione se non vengono soddisfatti.

Run SonarQube Analysis

(Figura 98) Eseguire l'analisi SonarQube

Per altre informazioni, vedere The Gradle build task now supports SonarQube analysis (L'attività di compilazione Gradle include ora il supporto per l'analisi SonarQube).

Miglioramenti a Marketplace

Gli amministratori della raccolta di progetti possono ora passare a Visual Studio Marketplace da un'istanza di Team Foundation Server e installare le estensioni gratuite in una raccolta di progetti team. Le estensioni vengono scaricate da Visual Studio Marketplace, caricate in Team Foundation Server e installate in modo automatico nella raccolta di progetti team selezionata (figura 99).

Install Free Extension

(Figura 99) Installare l'estensione gratuita

Acquistare e installare le estensioni a pagamento

Gli amministratori della raccolta di progetti possono ora passare a Visual Studio Marketplace da un'istanza di Team Foundation Server, acquistare estensioni a pagamento e installarle in una raccolta di progetti team (figura 100). L'amministratore può acquistare le estensioni con una sottoscrizione di Azure e selezionare il numero di utenti a cui assegnare tali estensioni. Le estensioni vengono scaricate da Visual Studio Marketplace, caricate in Team Foundation Server e installate in modo automatico nella raccolta di progetti team selezionata.

Purchase Paid Extension

(Figura 100) Acquistare l'estensione a pagamento

Per altri dettagli, vedere la documentazione Get extensions for Team Foundation Server (Ottenere estensioni per Team Foundation Server).

Miglioramenti all'amministrazione

Autenticazione di Windows

Nelle versioni precedenti era necessario scegliere tra i Security Support Provider NTLM e Negotiate per l'Autenticazione di Windows durante la configurazione di una distribuzione di TFS aggiunti al dominio. Nella versione 2017 questa impostazione è stata rimossa dall'esperienza di configurazione. Se si vuole continuare a usare l'autenticazione NTLM nella versione 2017 non è necessario eseguire alcuna operazione. Se si usa l'autenticazione Kerberos e si vuole continuare a usarla nella versione 2017 non è necessario eseguire alcuna operazione. TFS 2017 ora configura sempre entrambi i Security Support Provider Negotiate e NTLM, nell'ordine. Con questa configurazione, verrà usata l'autenticazione Kerberos dove possibile offrendo una protezione avanzata. Quando non è possibile usare Kerberos, verrà usata l'autenticazione NTLM. Sono stati eseguiti numerosi test per garantire l'assenza di effetti sulle distribuzioni TFS esistenti che usano l'autenticazione NTLM a causa di questa modifica.

Nuova esperienza di spostamento

In questa versione verrà abilitata una nuova barra di spostamento superiore, migliorata per soddisfare due obiettivi principali:

  • Aumentare l'efficienza di spostamento tra le aree del prodotto consentendo di accedere rapidamente agli hub con un singolo clic.
  • Aggiornare il prodotto con una grafica moderna e un'esperienza utente innovativa.

Poiché si tratta di una modifica importante per gli utenti e la funzionalità è ancora in fase di iterazione, è stato deciso di lasciare disabilitata la nuova barra di spostamento per impostazione predefinita. Se si vuole modificare questa impostazione, è possibile accedere al Pannello di controllo dell'area di amministrazione di Team Foundation Server e scegliere "Turn on new navigation" (Abilita il nuovo spostamento) per abilitare la barra. L'impostazione sarà valida per tutti gli utenti del server.

Autorizzazione di ridenominazione di un progetto team

Il controllo dell'autorizzazione in base alla quale gli utenti possono rinominare un progetto team è stato modificato. In precedenza, gli utenti con autorizzazione Modifica informazioni a livello di progetto per un progetto team potevano rinominarlo. Ora è invece possibile concedere o negare agli utenti la possibilità di rinominare un progetto team tramite la nuova autorizzazione Rinomina il progetto team.

Hub di lavoro nelle impostazioni di amministrazione

Nella pagina delle impostazioni di amministrazione è stato introdotto un nuovo hub "Lavoro" che combina impostazioni generali (figura 101), iterazioni e aree in una singola scheda. Con questa modifica, gli utenti potranno vedere chiaramente le differenze tra le impostazioni a livello di progetto e le impostazioni del team. Per le impostazioni del team, gli utenti vedranno solo le aree e le iterazioni rilevanti per il proprio team. A livello di progetto, la pagina delle impostazioni consentirà agli amministratori di gestire le aree e le iterazioni per l'intero progetto. Inoltre, per i percorsi delle aree di progetto, è stata aggiunta una nuova colonna denominata "Team" per consentire agli amministratori di individuare in modo semplice e rapido i team che hanno selezionato un determinato percorso di area.

Admin work hub

(Figura 101) Hub di lavoro per amministratori

API REST di configurazione del processo

Questa API pubblica consente agli utenti di ottenere la configurazione del processo di un determinato progetto. La configurazione del processo contiene le impostazioni seguenti:

  • TypeFields: astrazioni di campi personalizzabili che vengono usate negli strumenti Agile. Ad esempio, il tipo del campo "Punti della storia" è "Lavoro richiesto".
  • Definizioni di backlog: definizioni dei tipi di elemento di lavoro presenti in ognuno dei backlog. Si tratta di un'API richiesta di frequente dai clienti che compilano estensioni. Con questi dati, un'estensione può sapere come sfruttare i campi specifici del processo per gestire scenari comuni negli strumenti Agile (ad esempio, modificare l'attività o il lavoro richiesto per un elemento di lavoro, conoscere quali elementi di lavoro sono inclusi a uno specifico livello di backlog o determinare se i team vengono identificati dal percorso di area o da un campo personalizzato). Per altre informazioni, vedere Work Overview (Informazioni generali sul lavoro).

Team Foundation Server 2017 offre una nuova esperienza per gestire i gruppi e la relativa appartenenza. È possibile eseguire ricerche in utenti o gruppi di Active Directory o del computer locale usando criteri di ricerca basati su prefisso per uno o più nomi di utente o gruppo. Ad esempio, "John D" e nomeaccountsam (come "businessdomain\johbdnd") e vedere la scheda di contatto di un utente o gruppo.

Impostazioni di sicurezza degli utenti

Nella nuova esperienza "My Security" (Sicurezza personale) è possibile gestire i token di accesso personale e SSH (figura 102). Gli utenti che usavano "Profilo personale" per gestire SSH, devono ora gestire le proprie chiavi pubbliche SSH nelle impostazioni di sicurezza utente (figura 103).

My security

(Figura 102) My security (Sicurezza personale)

My profile

(Figura 103) Profilo personale

Configurazione guidata unificata

Nelle versioni precedenti, per la distribuzione di TFS, è necessario selezionare una delle diverse procedure guidate di configurazione, a seconda dei risultati desiderati. La Configurazione guidata server di base e la Configurazione guidata server completo possono essere usate per configurare una nuova distribuzione. L'Aggiornamento guidato può essere usato per gli aggiornamenti di produzione e pre-produzione. Infine, la Procedura guidata solo livello applicazione può essere usata per un'ampia gamma di scenari, tra cui l'aumento del numero di istanze di una distribuzione esistente, la sostituzione di un livello di applicazione con nuovo hardware e così via. In TFS 2017 tutti questi scenari sono stati unificati in una singola Configurazione guidata server, che fornisce le istruzioni da seguire per selezionare uno dei diversi scenari e definire la configurazione desiderata. Sono inoltre disponibili configurazioni avanzate, come gli aggiornamenti di pre-produzione e le azioni automatizzate per clonare una distribuzione esistente, eseguite in precedenza tramite tfsconfig.exe, incluse la modifica degli ID del server, la ridefinizione del mapping delle stringhe di connessione al database e la rimozione dei riferimenti alle dipendenze esterne (eseguita in precedenza con PrepareClone di tfsconfig.exe).

Nuovo livello di accesso

Con il nuovo gruppo di Visual Studio Enterprise aggiunto al portale di amministrazione del livello di accesso in Team Foundation Server, è ora possibile identificare rapidamente chi ha una sottoscrizione di Visual Studio Enterprise. Una volta identificati, questi utenti otterranno accesso completo a tutte le estensioni TFS del produttore installate da Visual Studio Marketplace senza alcun costo aggiuntivo.

Token di accesso personali

È ora possibile connettersi a qualsiasi istanza di Team Foundation Server usando un token di accesso personale oltre a SSH (figura 104). Questo token è utile se si sviluppa su Linux o Mac e si vuole usare il codice in qualsiasi strumento di automazione e GIT. È possibile gestire i token di accesso personali dalla pagina delle impostazioni di sicurezza utente.

Personal Access Tokens

(Figura 104) Token di accesso personali

Problemi noti

Questa sezione include un elenco di problemi noti riscontrati in questa versione.

Non sono disponibili Power Tools per Team Foundation Server 2017

  • Problema:

    Non sono stati rilasciati Power Tools nella versione TFS 2017.

  • Soluzione temporanea:

    Siamo lieti di comunicare che la maggior parte di Power Tools precedenti è stata integrata in TFS 2017. L'editor dei modelli di processo è uno strumento non integrato, ma è possibile ottenerlo in Visual Studio Marketplace.

Aggiornamento delle estensioni del controllo personalizzato

  • Problema:

    Lo schema dei campi nel form dell'elemento di lavoro è stato modificato. È stata modificata anche la documentazione per le estensioni del controllo personalizzato.

  • Soluzione temporanea:

    Vedere la nuova documentazione: Add a custom control to the work item form (Aggiungere un controllo personalizzato al form di un elemento di lavoro).

Errore durante l'importazione della definizione del tipo di elemento di lavoro

  • Problema:

    Verrà visualizzato un errore indicante che l'attributo LayoutMode non è dichiarato ai clienti con un'estensione della pagina dell'elemento di lavoro installata che esportano una definizione del tipo di elemento di lavoro e quindi importano questa definizione.

  • Soluzione temporanea:

    Esiste un attributo LayoutMode aggiuntivo sull'elemento PageContribution ogni volta che si esporta una definizione del tipo di elemento di lavoro. Prima di importare la definizione, cercare la modalità PageContribution e rimuovere l'attributo LayoutMode, ad esempio rimuovere LayoutMode = "FirstColumnWide".

I clienti devono eseguire l'aggiornamento a Git LFS versione 1.3.1 o successiva

  • Problema:

    Le versioni di Git LFS precedenti alla 1.3.1 non saranno supportate nelle versioni future.

  • Soluzione alternativa:

    Si consiglia ai clienti che usano Git LFS di eseguire l'aggiornamento a Git LFS versione 1.3.1 o successiva. Le versioni precedenti del client LFS non sono compatibili con le modifiche di autenticazione in questa versione di TFS. Per offrire ai clienti tempo sufficiente per la migrazione, è stata implementata una soluzione alternativa a breve termine per RTW. La soluzione alternativa verrà rimossa nell'Update 1 e a quel punto i client Git LFS di una versione precedente alla 1.3.1 non funzioneranno più.

Impossibilità per NuGet Restore di trovare i pacchetti esistenti in nuget.org

  • Problema:

    Quando si usa NuGet 3.4.3 o versione successiva, l'attività di ripristino NuGet non eseguirà il ripristino di pacchetti da NuGet.org a meno che non si tratti di un'origine esplicita di NuGet.Config.

  • Soluzione temporanea:

    Assicurarsi che NuGet.org si trovi in NuGet.Config.


Mancata autenticazione delle attività di compilazione e rilascio NuGet

  • Problema:

    Quando si usa Team Foundation Server o Gestione pacchetti, le attività di compilazione e rilascio NuGet non eseguono l'autenticazione ai feed se l'agente è in esecuzione come utente del servizio di rete, ovvero se è attivata l'impostazione predefinita per l'esecuzione dell'agente di compilazione come servizio. Ciò accade perché le versioni di NuGet precedenti alla 3.5 usano le credenziali dell'account utente che esegue l'agente di compilazione, non le credenziali fornite dall'attività di compilazione.

  • Soluzione alternativa:

    Per usare le attività di compilazione/rilascio di NuGet con feed TFS mediante un agente in esecuzione come servizio di rete, è necessario usare NuGet 3.5 o versione successiva.

Le attività di compilazione e rilascio di NuGet usano le credenziali dell'agente

  • Problema:

    Le versioni di NuGet precedenti alla 3.5 usano le credenziali dell'account utente che esegue l'agente di compilazione, non le credenziali fornite dall'attività di compilazione. Ciò può causare un accesso imprevisto o mancanza di accesso ai feed.

  • Soluzione alternativa:

    Usare NuGet 3.5 o versione successiva negli agenti di compilazione TFS.

Le estensioni esterne non vengono aggiornate automaticamente durante l'aggiornamento di TFS

  • Problema:

    Se l'estensione è stata scaricata da Visual Studio Marketplace e pubblicata nell'installazione di TFS 2015 e successivamente è stato eseguito l'aggiornamento a TFS 2017, l'estensione non verrà aggiornata automaticamente alla pubblicazione di nuove versioni dell'estensione in Marketplace.

  • Soluzione temporanea:

    Dopo l'aggiornamento a TFS 2017, disinstallare le estensioni installate in TFS 2015. Reinstallare quindi le estensioni più recenti. In TFS 2017 è stata aggiunta una funzionalità per la ricerca di estensioni esterne aggiornate una volta al giorno e per l'aggiornamento in modo automatico.

Non è possibile eseguire l'attività del processo di accodamento Jenkins nelle definizioni di versione

  • Problema:

    Quando si esegue l'attività del processo di accodamento Jenkins in una definizione di versione, ai clienti viene visualizzato un errore server 500.

  • Soluzione temporanea:

    Attualmente è possibile eseguire l'attività del processo di accodamento Jenkins come parte delle definizioni di compilazione TFS, ma non delle definizioni di versione. Questa funzionalità verrà aggiunta in una versione futura.

È necessario ricompilare i plugin del server TFS personalizzati rispetto alle DLL di TFS 2017

  • Problema:

    I plug-in del server TFS personalizzati non funzionano dopo l'aggiornamento a TFS 2017.

  • Soluzione temporanea:

    Ricompilare il plug-in del server personalizzati rispetto agli assembly di TFS 2017.

Il modello a oggetti server per i plug-in del server TFS personalizzati è stato modificato dopo TFS 2015 RTM

  • Problema:

    La compilazione dei plug-in del server TFS personalizzati non viene eseguita.

  • Soluzione temporanea:

    Correggere il codice sorgente come descritto in questo post di blog.

Viene generata un'eccezione quando si usano le azioni di amministratore

  • Problema:

    Nella pagina di amministrazione degli avvisi gli amministratori del team potrebbero ricevere un'eccezione quando usano la ricerca Trova avvisi per un utente specifico per trovare le sottoscrizioni per un team.

  • Soluzione temporanea:

    • Opzione 1: fare clic sul nodo Tutti gli avvisi e impostare il filtro Tutti gli avvisi del team per la visualizzazione. Verranno visualizzati tutti gli avvisi per tutti i gruppi a cui ha accesso l'utente.

    • Opzione 2: se il gruppo è un team, invece di eseguire la ricerca in base al nome del team, passare alla pagina di amministrazione degli____ avvisi di questo team per gestire le sottoscrizioni.

Viene generato un problema usando le attività per l'esecuzione di test funzionali in Team Build/Release Management

  • Problema:

    Esecuzione di test funzionali in Team Build/Release Management con 'Distribuzione agente di test di Visual Studio' e le attività di 'Eseguire test funzionali' dal catalogo delle attività che attualmente usa Agenti per Visual Studio 2015 Update 3 e può essere usato solo per eseguire i test creati in Visual Studio 2013 e Visual Studio 2015. Non è possibile usare queste attività per l'esecuzione di test compilati usando Visual Studio 2017 RC. Per altre informazioni dettagliate, fare riferimento a questo post di blog.

  • Soluzione temporanea:

    Non è disponibile alcuna soluzione. In TFS 2017 Update 1 verrà aggiunto il supporto per l'uso dell'agente di test 2017 e l'esecuzione di test compilati con Visual Studio 2017.

Le estensioni non vengono aggiornate automaticamente

  • Problema:

    Se si aggiorna una versione precedente di TFS a TFS 2017 e si esegue questa versione in modalità connessa, le estensioni non verranno aggiornate automaticamente in modo corretto.

  • Soluzione alternativa:

    Attualmente non esiste alcuna soluzione. Il problema è stato risolto e il comportamento di aggiornamento automatico sarà attivo in TFS 2017 Update 2. Se per qualsiasi motivo non è possibile attendere questo aggiornamento, contattare Microsoft attraverso il canale di supporto per ottenere prima la correzione.

Se si riscontrano problemi che impediscono la distribuzione in un ambiente di produzione (Go-Live), contattare il servizio supporto tecnico clienti Microsoft. (Solo in inglese) Solo orario lavorativo negli Stati Uniti (da lunedì a venerdì, dalle 6 alle 18 ora solare del Pacifico), risposta entro 1 giorno lavorativo.

In alto