Note sulla versione di Team Foundation Server 2017 Update 2 RC2

Last Update: 27/06/2017

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

In questo articolo sono disponibili informazioni relative alle versioni più recenti di Team Foundation Server 2017 Update 2 RC2. Fare clic sul pulsante per continuare.

Scarica la versione più recente di Team Foundation Server

Per altre informazioni su Team Foundation Server 2017, vedere la pagina Team Foundation Server Requirements and Compatibility (Requisiti e compatibilità di Team Foundation Server).


Commenti e suggerimenti

Le opinioni dei nostri clienti sono molto importanti per noi. È possibile segnalare un problema e tenerne traccia tramite il portale Developer Community (Community degli sviluppatori). Inviare suggerimenti tramite il sito Aggiornamenti del prodotto Visual Studio Team Services.


Data di rilascio: 26 giugno 2017

Riepilogo degli aggiornamenti in questa versione

In Team Foundation Server 2017 Update 2 RC2 è stato aggiunto molto nuovo valore. Tra le caratteristiche principali:

Per i dettagli di tutte le nuove funzionalità, visualizzare i miglioramenti per area:


Novità di questa versione

Miglioramenti alla verifica degli elementi di lavoro

Icone dei tipi di elemento di lavoro

Microsoft si è assunta a livello globale l'impegno di rendere i propri prodotti completamente accessibili ai clienti. Nell'ambito di tale impegno, sono stati individuati e affrontati numerosi problemi di accessibilità, dagli schemi della tastiera alla progettazione e al layout visivi.

In molti casi, per indicare il tipo di elemento di lavoro, la gestione degli elementi di lavoro si è finora basata esclusivamente sul colore. Questo metodo, tuttavia, crea problemi per gli utenti daltonici o ipovedenti, che potrebbero non essere in grado di distinguere alcuni elementi a causa dell'impossibilità di distinguerne i colori. Per favorire il riconoscimento del tipo degli elementi di lavoro da parte di tutti i clienti, nel linguaggio visivo del tipo di elemento di lavoro sono state introdotte le icone. È possibile personalizzare i tipi di elemento di lavoro scegliendo le icone da una selezione di quelle presenti nella libreria.

Le barre colorate indicanti il tipo nelle griglie del backlog e delle query sono state sostituite da icone colorate (Figura 1).

Icone dei tipi di elemento di lavoro nelle query

(Figura 1) Icone colorate nelle query

Le schede sulla bacheca includono ora l'icona del tipo (Figura 2).

Bacheca con icona del tipo

(Figura 2) Bacheca con icona del tipo

Piani di recapito

I piani di recapito sono uno strumento organizzativo che promuove visibilità e allineamento tra team diversi, verificando lo stato del lavoro in base a un calendario basato sull'iterazione. È possibile personalizzare il piano in modo da includere qualsiasi team o livello di backlog da tutti i progetti dell'account. In più, i criteri campi dei piani consentono di personalizzare ulteriormente la vista, mentre i marcatori evidenziano le date importanti.

Per altre informazioni e per installare l'estensione, vedere la pagina del marketplace per i Piani di recapito.

Collegamento automatico da elementi di lavoro a compilazioni

Con questa nuova impostazione nella definizione di compilazione è possibile tener traccia delle compilazioni in cui il lavoro è stato incorporato, senza dover effettuare una ricerca manuale all'interno di un ampio set di compilazioni. Ogni compilazione completata associata all'elemento di lavoro in questione viene visualizzata automaticamente nella sezione relativa allo sviluppo del form elemento di lavoro.

Per abilitare questa funzionalità, attivare o disattivare l'impostazione in Opzioni nella definizione di compilazione (Figura 3).

Collegamento di una compilazione ai tipi di elemento di lavoro

(Figura 3) Collegamento di una compilazione ai tipi di elemento di lavoro

Form elemento di lavoro precedente deprecato

Il feedback complessivo sul nuovo form elemento di lavoro è stato positivo ed è quindi stato adottato al 100% per gli account ospitati. Per garantire ai clienti locali lo stesso valore che ha reso estremamente soddisfatti gli utenti VSTS, è stato deciso di dichiarare deprecati il form elemento di lavoro e il modello di estendibilità precedenti. Per altre informazioni, vedere la pagina Microsoft Application Lifecycle Management.

Ricerca di elementi di lavoro

La funzione di ricerca di elementi di lavoro rappresenta uno strumento di ricerca rapido e flessibile all'interno di tutti gli elementi di lavoro di tutti i progetti di una raccolta (Figura 4). È possibile usare il motore di ricerca full-text della funzione di ricerca di elementi di lavoro per cercare termini in tutti i campi degli elementi di lavoro in modo semplice e per individuare in modo efficiente gli elementi di lavoro pertinenti. Per ridurre l'elenco degli elementi di lavoro trovati, è possibile usare filtri di ricerca inline in base a qualsiasi campo di elemento di lavoro.

Una volta configurato il servizio di ricerca in TFS, è possibile effettuare ricerche senza dover installare altri strumenti. Tramite la funzione di ricerca di elementi di lavoro è possibile:

  • Cercare all'interno di tutti i progetti: cercare all'interno del proprio backlog e di quello del team partner. Per effettuare una ricerca all'interno di tutti gli elementi di lavoro dell'organizzazione, è possibile cercare all'interno degli elementi di lavoro di più progetti. È possibile limitare la ricerca tramite filtri percorso di area e di progetto.
  • Ricerca in tutti i campi degli elementi di lavoro: Per trovare elementi di lavoro in modo rapido e semplice è possibile cercare in tutti i campi degli elementi di lavoro, compresi i campi ere. Eseguire una ricerca full-text in tutti i campi per individuare in modo efficiente gli elementi di lavoro pertinenti. La visualizzazione frammento di codice indica dove sono state trovate corrispondenze.
  • Cercare all'interno di campi specifici: per limitare in pochi secondi l'elenco degli elementi di lavoro risultanti, è possibile usare i filtri di ricerca inline per un qualsiasi campo degli elementi di lavoro. L'elenco a discesa dei suggerimenti consente di completare la ricerca più velocemente. Ad esempio, la ricerca AssignedTo:Chris WorkItemType:Bug State:Active consente di trovare tutti i bug attivi assegnati a un utente con nome Chris.
  • Sfruttare i vantaggi dell'integrazione con la gestione di elementi di lavoro: l'interfaccia della ricerca di elementi di lavoro si integra con controlli noti nell'hub di lavoro, consentendo di visualizzare, modificare, commentare, condividere e molto altro ancora.

Ricerca di elementi di lavoro

(Figura 4) Ricerca di elementi di lavoro

Miglioramenti al controllo della versione

Nuova esperienza di configurazione dei criteri ramo

L'esperienza di configurazione dei criteri ramo è stata riprogettata con l'aggiunta di alcune nuove eccezionali funzionalità (Figura 5). Una delle funzionalità più avanzate è la possibilità di configurare criteri per le cartelle di rami. È possibile eseguire questa operazione dalla vista Rami selezionando una cartella di ramo e scegliendo Criteri ramo dal menu di scelta rapida.

Configurare criteri di ramo

(Figura 5) Configurare criteri di ramo

Verrà aperta la nuova esperienza utente di configurazione dei criteri, in cui è possibile configurare i criteri che si applicano a tutti i rami nella cartella di rami (Figura 6).

Pagina dei criteri

(Figura 6) Pagina dei criteri

Se si usano criteri di compilazione, è ora possibile configurare più compilazioni per un unico ramo. Sono disponibili anche nuove opzioni per specificare un trigger automatico o manuale (Figura 7). I trigger manuali sono utili per operazioni che possono richiedere tempi di esecuzione lunghi, ad esempio esecuzioni di test automatizzate, e che è necessario eseguire una sola volta prima di completare la richiesta pull. I criteri di compilazione hanno anche un nome visualizzato, utile se si stanno configurando più compilazioni.

Compilazione manuale

(Figura 7) Compilazione manuale

Dopo aver configurato criteri attivati manualmente, è possibile eseguirli selezionando l'opzione Accoda compilazione nella sezione Criteri per la richiesta pull (Figura 8).

Coda di compilazione manuale

(Figure 8) Coda di compilazione manuale

Per i criteri per revisori obbligatori (Figura 9) è stata aggiunta la possibilità per gli amministratori di specificare una nota da aggiungere alla sequenza temporale della richiesta pull quando i criteri vengono applicati(Figura 10).

Finestra di dialogo con revisori obbligatori

(Figura 9) Finestra di dialogo con revisori obbligatori

Nota di un revisore obbligatorio

(Figura 10) Nota di un revisore obbligatorio

Nuovi criteri per i commenti non attivi

Verificare che per tutti i commenti nelle richieste pull vengano applicati i nuovi criteri Commenti. Se questi criteri sono abilitati, i commenti attivi bloccano il completamento della richiesta pull, imponendo la risoluzione di tutti i commenti. I revisori che lasciano commenti per l'autore della richiesta pull ma ottimisticamente approvano la richiesta pull hanno la certezza che se l'autore è desideroso di eseguire il merge non trascurerà alcun commento.

Miglioramenti all'hub dei file

Sono stati eseguiti diversi aggiornamenti per l'hub dei file per migliorarne l'esperienza di visualizzazione e modifica.

Per la visualizzazione sono stati aggiunti pivot che consentono di visualizzare il file LEGGIMI nella cartella corrente (Figura 11), nonché di visualizzare l'anteprima dei file markdown, confrontare un file con una versione precedente (Figura 12)e visualizzare gli errori.

Visualizzazione di file

(Figura 11) Visualizzazione di file

Confronto di file

(Figura 12) Confronto di file

Per quanto riguarda la modifica, è ora possibile visualizzare in anteprima le modifiche, aggiungere facilmente un commento, eseguire il commit in un nuovo ramo e collegare elementi di lavoro (Figura 13).

Modifica di file

(Figura 13) Modifica di file

Visualizzare il repository Git

È ora possibile visualizzare un grafo durante la visualizzazione della cronologia dei commit per i repository o i file. Ciò consente di creare facilmente tramite un grafo Git un modello mentale di tutti i rami e di tutti i commit per i repository Git (Figura 14). Il grafo mostra tutti i commit in ordine topologico.

Grafo Git

(Figura 14) Grafo Git

Gli aspetti chiave del grafo Git sono (Figura 15):

  1. Il grafo Git è allineato a destra. Pertanto i commit associati al ramo predefinito o a quello selezionato sono visualizzati a destra, mentre il resto del grafo si espande a sinistra.
  2. I commit di merge sono rappresentati da punti grigi connessi al primo e al secondo elemento padre.
  3. I commit normali sono rappresentati da punti blu.
  4. Se il commit padre di un commit non è visibile nel viewport per i 50 commit successivi, la connessione di commit viene interrotta. Quando si fa clic sulla freccia, il commit viene connesso al commit padre corrispondente.

Elementi del grafo Git

(Figura 15) Elementi del grafo Git

Visualizzare tag Git per i commit

Se il team usa tag Git per contrassegnare punti specifici nella cronologia del repository, i commit ora visualizzano i tag creati dall'utente. È possibile visualizzare i tag (Figura 16) per un commit specifico nella vista di elenco dei commit e nella pagina dei dettagli.

Visualizzare tag

(Figura 16) Visualizzare tag

Aggiungere tag ai commit

Anziché creare tag dalla riga di comando ed eseguirne il push nel repository, è ora possibile passare semplicemente a un commit e aggiungere un tag (Figura 17). La finestra di dialogo di creazione di tag consente anche di aggiungere tag a qualsiasi altro tipo di riferimento nel repository.

Creare dettagli di tag

(Figura 17) Creare dettagli di tag

La vista di elenco dei commit supporta anche un menu di scelta rapida(Figura 18). Per creare tag e nuovi rami non è necessario passare alla pagina dei dettagli del commit (Figura 19).

Creare la cronologia dei tag

(Figura 18) Creare la cronologia dei tag

Ramo di tag

(Figura 19) Ramo di tag

Aggiornamento delle pagine degli insiemi di modifiche e degli shelveset

Le pagine degli insiemi di modifiche e degli shelveset nel controllo della versione di Team Foundation sono state modernizzate. Entrambe le pagine sono ora più accessibili per gli utenti che usano dispositivi di assistive technology. Le nuove pagine hanno anche una nuova intestazione che contiene il titolo dell'insieme di modifiche e le informazioni associate, ad esempio i dettagli sull'autore (Figura 20).

Pagina di un insieme di modifiche

(Figura 20) Pagina di un insieme di modifiche

Sia le pagine degli insiemi di modifiche che quelle degli shelveset ospitano anche un nuovo controllo di discussione markdown (Figura 21) che consente di digitare i commenti in markdown, usare @mention per gli utenti, associare elementi di lavoro tramite # e allegare facilmente file e immagini.

Discussione di un insieme di modifiche

(Figura 21) Discussione di un insieme di modifiche

Filtro dei commit migliorato

È ora possibile filtrare i risultati della cronologia di commit (Figura 22) in base a opzioni di filtro avanzate. È possibile filtrare i commit per:

  • cronologia completa;
  • cronologia completa con semplificazione dei merge;
  • primo elemento padre;
  • cronologia semplice (impostazione di filtro predefinita).

Filtro dei commit migliorato

(Figura 22) Filtro dei commit migliorato

Importare repository dal controllo della versione di Team Foundation a Git

È possibile eseguire la migrazione di codice dai repository del controllo della versione di Team Foundation a repository Git nell'ambito dello stesso account. Per avviare la migrazione, selezionare Importa repository dall'elenco a discesa di selezione del repository(Figura 23).

Elenco a discesa di selezione del repository

(Figura 23) Elenco a discesa di selezione del repository

È possibile importare nel repository Git singole cartelle o singoli rami oppure l'intero repository del controllo della versione di Team Foundation, meno i rami (Figura 24). È anche possibile importare un massimo di 180 giorni di cronologia.

Importazione dell'intero repository

(Figura 24) Importazione dell'intero repository

Blocco di file Git LFS

È stata aggiunta la funzionalità di blocco di file Git LFS. Questa funzionalità consente ai team che usano file di grandi dimensioni su cui non è possibile eseguire Diff di evitare di perdere il proprio lavoro se due o più utenti tentano di modificare lo stesso file contemporaneamente. Prima di iniziare a modificare il file, un utente acquisisce un blocco, di cui viene informato il server. Se un altro utente tenta di acquisire un blocco, il server rifiuta la richiesta, informando il secondo utente che il file è già in corso di modifica. Per usare questa funzionalità, eseguire l'aggiornamento a Git LFS 2.1 o versione successiva.

I commenti di commit Git usano il nuovo controllo di discussione

La funzionalità dei commenti brevi ai commit Git è stata aggiornata in modo da consentire l'uso del nuovo controllo di discussione. Grazie all'aggiornamento, tali commenti ora supportano Markdown ed è possibile usare tutte le funzionalità di commento di codice nel Web sia in Git che nel controllo della versione con l'interfaccia più recente.

Nuovo controllo di visualizzazione albero

La vista dei file di richiesta pull e i dettagli dei commit Git, dei push Git, degli shelveset e degli insiemi di modifiche del controllo della versione di Team Foundation, nonché l'hub degli insiemi del controllo della versione di Team Foundation e l'hub della cronologia Git sono stati aggiornati con un nuovo controllo di visualizzazione albero (Figura 25). La visualizzazione struttura ad albero contiene alcuni miglioramenti di usabilità. Prima di tutto, la vista ora contiene una visualizzazione struttura ad albero ridotta che comprime automaticamente i nodi cartella vuoti, ottimizzando il numero di file visibili.

L'albero poi mostra i commenti in modo più compatto. Per i file con commenti è visualizzato un elemento figlio per ogni thread di commenti, con l'avatar dell'utente che ha creato il thread. I thread di commenti nuovi e quelli con risposte sono indicati da un punto blu e il conteggio delle risposte è riepilogato da un numero.

Nuova visualizzazione struttura ad albero

(Figura 25) Nuova visualizzazione struttura ad albero

Miglioramenti alle richieste pull

Inviti all'azione migliorati per l'autore della richiesta pull e i revisori

Per i team che usano criteri ramo può essere talvolta difficile sapere esattamente qual è l'azione richiesta quando è visualizzata una richiesta pull. Se l'invito all'azione principale corrisponde al pulsante Completa, significa che la richiesta è pronta per il completamento? Usando le informazioni sull'utente che visualizza la pagina e sullo stato dei criteri ramo configurati, la vista della richiesta pull presenta ora l'invito all'azione più appropriato per tale utente.

Se sono configurati criteri, ma questi non sono stati ancora soddisfatti, il pulsante Completa (Figura 26) lascia il posto alla funzionalità Completamento automatico. Non è probabile che si riesca a completare la richiesta pull correttamente se i criteri causano un blocco. Pertanto è disponibile un'opzione che consente di completare automaticamente la richiesta pull quando i criteri vengono infine soddisfatti.

Funzionalità di completamento automatico

(Figura 26) Funzionalità di completamento automatico

Per i revisori è più probabile dover approvare una richiesta pull piuttosto che doverla completare. Per i revisori viene quindi visualizzato il pulsante Approva (Figura 27), evidenziato come invito all'azione principale se l'approvazione non è ancora stata effettuata.

Invito all'azione di approvazione

(Figura 27) Invito all'azione di approvazione

Dopo l'approvazione, per i revisori viene visualizzato il pulsante Completa (o Completamento automatico) evidenziato come invito all'azione principale nei casi in cui il revisore è anche l'utente che completa la richiesta pull.

Commenti interattivi

In una richiesta pull con un certo numero di commenti può essere difficile tenere traccia di tutte le conversazioni. Per consentire una gestione più efficace dei commenti, abbiamo apportato alcuni miglioramenti per semplificare il processo di risoluzione degli elementi presi in considerazione:

  • Nell'intestazione di ogni richiesta pull è ora visualizzato il numero dei commenti risolti (Figura 28).

Intestazione di una richiesta pull

(Figura 28) Intestazione di una richiesta pull

  • Quando un commento è stato preso in considerazione, è possibile risolverlo con un solo clic (Figura 29).

Pulsante Risolvi

(Figura 29) Pulsante Risolvi

  • Se si vogliono aggiungere commenti durante la risoluzione, è possibile rispondere e risolvere con un unico movimento (Figura 30).

     Rispondi e risolvi

(Figura 30) Rispondi e risolvi

  • Man mano che i commenti vengono risolti, si vedrà aumentare il numero finché tutti non saranno stati presi in considerazione (Figura 31).

Numero di commenti presi in considerazione

(Figura 31) Numero di commenti presi in considerazione

  • Il filtro nella panoramica è stato migliorato per consentire l'applicazione di filtri in base al diverso stato dei commenti e la visualizzazione del numero di commenti per ogni opzione di filtro (Figura 32).

Miglioramenti al filtro

(Figura 32) Miglioramenti al filtro

La vista Aggiornamenti mostra riassegnazioni e force push

Nella vista dei dettagli della richiesta pull la scheda Aggiornamenti è stata migliorata e ora visualizza quando si è verificato un force push e se il commit di base è stato modificato (Figura 33). Queste due funzionalità sono molto utili se si riassegnano le modifiche nei rami a tema prima di completare le richieste pull. I revisori hanno ora informazioni sufficienti su ciò che è avvenuto.

Viste Aggiornamenti

(Figura 33) Viste Aggiornamenti

Filtro di richieste pull per utente

Trovare richieste pull è ora più semplice. Sono state aggiunte nuove opzioni di filtro che consentono di trovare le richieste pull create da un autore specifico o assegnate a un revisore particolare (Figura 34). È sufficiente selezionare un utente dal filtro degli autori o dei revisori. L'elenco verrà aggiornato in modo da visualizzare solo le richieste pull che corrispondono al filtro.

Filtro per utente

(Figura 34) Filtro per utente

Motivo obbligatorio quando si ignorano i criteri di una richiesta pull

Quando si ignorano i criteri di una richiesta pull, è necessario specificare un motivo. Se si sceglie di ignorare i criteri, nella finestra di dialogo Completa richiesta pull viene visualizzato il nuovo campo Motivo (Figura 35).

Finestra di dialogo di bypass

(Figura 35) Finestra di dialogo di bypass

Dopo aver immesso il motivo e aver completato la richiesta pull, in __Panoramica__verrà visualizzato questo messaggio (Figura 36).

Messaggio di bypass

(Figura 36) Messaggio di bypass

Condividere richieste pull con altri team

L'azione Condividi richiesta pull è un modo pratico per inviare notifiche ai revisori (Figura 37). In questa versione è stato aggiunto il supporto per team e gruppi. Pertanto è possibile informare tutti gli interessati alla richiesta pull in un unico passaggio.

Condividere richieste pull con altri team

(Figura 37) Condividere richieste pull con altri team

Miglioramenti alle richieste pull per i team

Se si fa parte di più team, è ora possibile visualizzare l'elenco di tutte le richieste pull assegnate ai team a cui si appartiene nella vista Richieste pull personali (Figura 38). La vista Richieste pull personali rappresenta quindi l'unico punto di riferimento che occorre consultare per visualizzare tutte le richieste pull di proprio interesse.

Miglioramenti alle richieste pull per i team

(Figura 38) Miglioramenti alle richieste pull per i team

In una versione futura i team verranno aggiunti all'hub Richieste pull in Code, per semplificare la visualizzazione di tutte le richieste pull personali per un unico progetto.

Notifiche predefinite per i commenti a richieste pull

La nuova funzionalità relativa alle notifiche predefinite dei commenti consente di seguire tutti gli aggiornamenti alle conversazioni sulle richieste pull di proprio interesse (Figura 39). Per le richieste pull create dall'utente, quest'ultimo riceverà automaticamente una notifica ogni volta che un altro utente aggiungerà un nuovo thread di commenti o risponderà a un thread esistente. Quando si inserisce un commento per una richiesta pull di un altro utente, si riceverà una notifica per le eventuali future risposte al thread di commenti creato o a cui si risponde.

Notifiche predefinite per richieste pull

(Figura 39) Notifiche predefinite per richieste pull

Queste notifiche, disponibili nell'ambito delle sottoscrizioni predefinite, sono configurabili nella pagina di impostazioni Notifiche.

Miglioramenti a Gestione pacchetti

Aggiornamento dell'esperienza di Gestione pacchetti

L'esperienza utente di Gestione pacchetti è stata aggiornata per renderla più veloce, risolvere problemi comuni segnalati dagli utenti e fare spazio per le funzionalità future relative al ciclo di vita dei pacchetti (Figura 40). Per altre informazioni sull'aggiornamento, vedere la pagina Updated Package Management UX (Aggiornamento dell'esperienza utente di Gestione pacchetti).

Gestione pacchetti

(Figura 40) Gestione pacchetti

Aggiunta a Gestione pacchetti dei file LEGGIMI di npm e del pulsante Scarica

È ora possibile visualizzare il file LEGGIMI di qualsiasi pacchetto npm che include un file README.md (Figura 41). I file LEGGIMI semplificano la documentazione e la condivisione di conoscenze relative ai pacchetti da parte del team.

È anche possibile scaricare qualsiasi pacchetto npm tramite il pulsante Scarica sulla barra dei comandi.

LEGGIMI di npm in Gestione pacchetti

(Figura 41) LEGGIMI di npm in Gestione pacchetti

Attività di compilazione di NuGet Restore, Command e Tool Installer

Sono stati effettuati aggiornamenti importanti delle attività di NuGet Installer (ora denominato NuGet Restore) e sono state aggiunte due nuove attività NuGet: NuGet Command e il NuGet Tool Installer. In particolare, per impostazione predefinita le attività NuGet Command e NuGet Restore ora usano nuget.exe 4.0.0.

NuGet Tool Installer consente il controllo della versione di NuGet usata sia da NuGet Restore che da NuGet Command. Per impostazione predefinita, le attività usano una versione testata nota. Se si vuole eseguire l'override di questa versione, è sufficiente aggiungere un passaggio di NuGet Tool Installer prima di eseguire altri passaggi di compilazione NuGet.

NuGet Restore è ora ottimizzato per lo scenario più comune di ripristino dei pacchetti prima di un passaggio di compilazione di Visual Studio. Offre anche un supporto più efficiente dei progetti di piccole dimensioni che condividono un unico feed NuGet: è ora possibile selezionare un feed di Team Services e aggiungerlo a un file NuGet.Config generato automaticamente.

Per operazioni NuGet più complesse, l'attività NuGet Command offre la flessibilità necessaria per specificare qualsiasi comando e set di argomenti (Figura 42).

Comando NuGet

(Figura 42) Comando NuGet

Miglioramenti alle compilazioni e alle versioni

Nuovo editor delle definizioni di compilazione

L'editor delle definizioni di compilazione è stato riprogettato per offrire un'esperienza più intuitiva, risolvere alcuni punti deboli e aggiungere nuove funzionalità, nella speranza che risulti più semplice usare i modelli, aggiungere attività e modificare le impostazioni. E ora è possibile usare parametri di processo per facilitare l'indicazione dei dati più importanti senza dover addentrarsi nelle attività.

Cercare modelli

È possibile cercare il modello voluto e quindi applicarlo oppure iniziare con un processo vuoto (Figura 43).

Ricerca di un modello di compilazione

(Figura 43) Ricerca di un modello di compilazione

Trovare un'attività e aggiungerla esattamente nel punto voluto

È possibile cercare l'attività che si vuole usare e quindi, dopo averla individuata, è possibile aggiungerla dopo l'attività attualmente selezionata a sinistra oppure trascinarla nel punto in cui si vuole eseguirla (Figura 44).

Ricerca di un'attività di compilazione

(Figura 44) Ricerca di un'attività di compilazione

È anche possibile trascinare un'attività per spostarla oppure trascinarla tenendo premuto CTRL per copiarla.

Passare argomenti chiave alle attività tramite parametri di processo

È ora possibile usare parametri di processo (Figura 45) per facilitare l'indicazione dei dati più importanti, senza alcuna necessità di addentrarsi nelle attività, per gli utenti che usano la definizione o il modello di compilazione creato.

Parametri di processo

(Figura 45) Parametri di processo

Se si crea una nuova compilazione da alcuni modelli incorporati, ad esempio Visual Studio e Maven, è possibile visualizzare esempi del loro funzionamento.

Il nuovo editor include alcuni altri miglioramenti, ad esempio una maggiore rapidità di accesso alle impostazioni delle origini.

Per una procedura dettagliata per la creazione della prima definizione di compilazione tramite il nuovo editor, vedere CI/CD for newbies (CI/CD per principianti).

Per altre informazioni, vedere la pagina sull'esperienza utente 2017.

Attività di compilazione condizionale

Se si vuole avere un maggiore controllo sulle attività di compilazione, ad esempio un'attività per eseguire la pulizia o inviare un messaggio quando si verifica un problema, sono ora disponibili quattro opzioni predefinite per controllare quando eseguire un'attività (Figura 46).

Attività di compilazione condizionale

(Figura 46) Attività di compilazione condizionale

Se si vuole una maggiore flessibilità, ad esempio per eseguire un'attività solo per rami specifici, con trigger particolari, in determinate condizioni, è possibile esprimere condizioni personalizzate:

and(failed(), eq(variables['Build.Reason'], 'PullRequest'))

Vedere la pagina Specify conditions for running a task (Specificare le condizioni per l'esecuzione di un'attività).

Attività predefinite per la compilazione e la distribuzione di applicazioni basate su contenitore

In questa versione, per impostazione predefinita la maggior parte delle attività presenti nell'estensione Docker è stata spostata nel prodotto e migliorata. È stato anche introdotto un set di nuove attività e di nuovi modelli per rendere più semplice la creazione di un set di scenari contenitore.

  • Docker: compilare o eseguire immagini Docker, effettuare il push di tali immagini o eseguire un comando Docker. Questa attività può essere usata con Docker o con il registro contenitori di Azure. È ora possibile usare l'autenticazione dell'entità servizio incorporata con i record di controllo di accesso per renderne ancora più semplice l'uso.
  • Docker-Compose: consente di compilare o eseguire applicazioni Docker o di effettuarne il push con più contenitori. Questa attività può essere usata con Docker o con il registro contenitori di Azure.
  • Kubernetes: consente di distribuire, configurare o aggiornare il cluster Kubernetes nel servizio contenitore di Azure tramite comandi kubectl.
  • Service Fabric: consente di distribuire contenitori in un cluster di Service Fabric. Service Fabric è oggi la scelta migliore per l'esecuzione di contenitori di Windows nel cloud.

Aggiornamenti della distribuzione di app Web di Azure

Sono stati apportati numerosi miglioramenti alle applicazioni Web di Azure:

  • L'attività di distribuzione del servizio app di Azure supporta la distribuzione di file WAR Java e Node.js, nonché di applicazioni Python e PHP.
  • Tramite i contenitori l'attività di distribuzione del servizio app di Azure supporta la distribuzione di app Web di Azure per Linux.
  • La funzionalità di recapito continuo del portale di Azure è stata espansa e ora supporta le applicazioni Node.
  • Nel servizio app di Azure è stata aggiunta un'attività di gestione per l'avvio, l'arresto, il riavvio o lo scambio di slot. È ora supportata anche l'installazione di estensioni di siti per consentire l'installazione della versione di PHP o Python richiesta, di Gestione IIS o di Application Insights.

La versione più recente dell'interfaccia della riga di comando di Azure supporta CI/CD e ne consente la configurazione. Ecco un esempio:

az appservice web source-control config --name mywebapp --resource-group mywebapp_rg --repo-url https://myaccount.visualstudio.com/myproject/_git/myrepo --cd-provider vsts --cd-app-type AspNetCore

Supporto dei file di progetto da parte delle attività .NET Core

L'aggiornamento corrente prevede il miglioramento delle attività .NET Core perché supportino i file con estensione csproj oltre al file project.json. È ora possibile usare Visual Studio 2017 con gli agenti di compilazione per compilare applicazioni .NET Core usando file csproj.

Miglioramenti alla distribuzione SSH

L'attività di compilazione/versione Copia file tramite SSH supporta ora il carattere tilde (~) nel percorso di destinazione, per semplificare la copia di file nella directory home di utenti remoti. Una nuova opzione, poi, fa in modo che la compilazione/versione non riesca se non sono presenti file da copiare.

L'attività di compilazione/versione SSH supporta ora l'esecuzione di script con terminazioni di riga Windows in computer remoti Linux o macOS.

Installare una chiave SSH durante una compilazione o una versione

Una nuova attività di anteprima, Install SSH Key (Preview) (Installa chiave SSH (anteprima)), consente di installare una chiave SSH prima di una compilazione o di una versione, rimuovendola dall'agente quando la compilazione o la versione è completata. La chiave installata può essere usata per recuperare codice da un repository o da un modulo secondario Git oppure per eseguire script di distribuzione o altre attività che richiedono l'autenticazione SSH. Questa funzionalità verrà migliorata in futuro con il supporto di passphrase e altre funzionalità.

Le attività hanno esito negativo se Visual Studio 2017 è specificato ma non è presente nell'agente

Le attività Compilazione Visual Studio e MSBuild consentono di selezionare una versione di Visual Studio specifica. Finora, se la versione Visual Studio 2017 non era disponibile, queste attività selezionavano automaticamente la versione successiva.

Questo comportamento cambierà. Ora la compilazione ha esito negativo se si seleziona Visual Studio 2017 ma questa versione non è presente nell'agente.

Questa modifica è stata effettuata per i motivi seguenti:

  • I tipi di app più recenti, ad esempio .NET Core, non possono essere compilati con strumenti di compilazione precedenti ma richiedono in modo esplicito Visual Studio 2017 o una versione successiva.

  • Si ottengono risultati più coerenti e prevedibili se si usa esattamente la stessa versione di Visual Studio.

  • Quando l'attività di compilazione non riesce, si potrebbero ricevere errori di compilazione difficili da comprendere.

Suggerimento

Assicurarsi di usare una coda connessa a un pool che abbia agenti con Visual Studio 2017 e che non abbia agenti dotati solo di versioni precedenti di Visual Studio.

Pulizia automatica dell'area di lavoro degli agenti privati

È ora possibile configurare un pool di agenti che pulisca periodicamente le directory di lavoro e i repository non aggiornati (Figura 47). Il pool, ad esempio, eliminerà le aree di lavoro rimaste dopo l'eliminazione di definizioni di compilazione e versione.

Manutenzione degli agenti

(Figura 47) Manutenzione degli agenti

Questa opzione riduce la possibilità che gli agenti privati di compilazione e versione esauriscano lo spazio su disco. La manutenzione viene effettuata per agente, non per computer. Pertanto se in un unico computer sono presenti più agenti, sono ancora possibili problemi di spazio su disco.

Stato di aggiornamento degli agenti di compilazione

Quando un agente viene aggiornato, il suo stato di aggiornamento è ora indicato nel portale di gestione delle code e dei pool.

Selezione di agenti privati in computer non in uso

Il sistema ora usa il nome del computer come fattore per l'allocazione di una compilazione o di una versione a un agente privato. Di conseguenza, al momento di allocare un processo il sistema preferisce un agente in un computer inattivo a un agente in un computer occupato.

Miglioramenti a DevOps iOS

L'estensione per App Store di Apple supporta ora la verifica in due passaggi (autenticazione a due fattori) e il rilascio di build a tester esterni (Figura 48).

Connessione ad App Store di Apple

(Figura 48) Connessione ad App Store di Apple

Installa certificato Apple (anteprima) è una nuova attività di compilazione che installa un certificato di firma P12 nell'agente per l'uso da parte di una compilazione Xcode o Xamarin.iOS successiva.

Install Apple Profile (Preview) (Installa profilo Apple (anteprima)) è una nuova attività di compilazione per l'installazione di profili di provisioning nell'agente per l'uso da parte di una compilazione Xcode o Xamarin.iOS successiva.

Le attività di compilazione MSBuild, Xamarin.Android e Xamarin.iOS ora supportano la compilazione tramite il set di strumento di Visual Studio per Mac.

Miglioramenti alla code coverage Java

L'attività di compilazione Pubblica risultati di code coverage segnala la code coverage Cobertura o JaCoCo come parte di una compilazione. Ora l'attività supporta l'uso di caratteri jolly e criteri di corrispondenza minima nei campi File di riepilogo e Directory dei report, consentendo la risoluzione di file e directory in base alla compilazione per i percorsi che cambiano tra una compilazione e l'altra.

Miglioramenti a Maven e SonarQube

L'attività di compilazione Maven consente ora di specificare un progetto di SonarQube per i risultati dell'analisi nei casi in cui ci siano differenze rispetto a quanto specificato nel file pom.xml di Maven.

Miglioramento dell'integrazione di Jenkins

L'attività di compilazione/versione Accoda il processo nel server Jenkins ora supporta l'esecuzione di processi di pipeline Jenkins a più rami durante la visualizzazione dell'output della console Jenkins in Team Services (Figura 49). I risultati di pipeline vengono pubblicati nel riepilogo della compilazione di Team Services

Miglioramento dell'integrazione di Jenkins

(Figura 49) Miglioramento dell'integrazione di Jenkins

Distribuzione di set di scalabilità di macchine virtuali di Azure

Un criterio comunemente usato per la distribuzione consiste nel creare un'immagine completa del computer per ogni versione dell'applicazione da distribuire. Per semplificare questa procedura è disponibile la nuova attività Crea immagine non modificabile. Questa attività usa lo strumento di creazione pacchetti per generare l'immagine di un computer dopo la distribuzione di applicazioni e di tutti i prerequisiti necessari. L'attività accetta lo script di distribuzione o il modello di configurazione dello strumento di creazione pacchetti per creare l'immagine del computer, che archivia in un account di Archiviazione di Azure. Questa immagine può quindi essere usata per distribuzioni di set di scalabilità di macchine virtuali di Azure. Tali distribuzioni sono molto efficienti con questo tipo di distribuzione di immagini non modificabili.

Override dei parametri di modello nelle distribuzioni di gruppi di risorse di Azure

Attualmente nelle attività di distribuzione di gruppi di risorse di Azure si selezionano i file template.json e parameters.json e si specificano i valori dei parametri di override in una casella di testo secondo una sintassi specifica. Questa esperienza è stata ora migliorata in modo che i parametri del modello vengano visualizzati in una griglia che consente di modificarli e di sottoporli a override (Figura 50). È possibile accedere a questa funzionalità facendo clic su ... accanto al campo dei parametri di override. Si aprirà una finestra di dialogo con i parametri di modello e i relativi valori predefiniti e consentiti, se definiti nei file template.json e parameters.json. Questa funzionalità richiede che per l'origine le regole CORS siano abilitate. Se i file template.json e parameters.json sono presenti nel BLOB di Archiviazione di Azure, per abilitare CORS fare riferimento alla documentazione dei servizi di Archiviazione di Azure.

Parametri dei gruppi di risorse di Azure

(Figura 50) Parametri dei gruppi di risorse di Azure

Più trigger di rilascio con filtri di ramo e tag

La gestione del rilascio ora supporta l'impostazione di trigger CD per più origini artefatto di tipo "Build". Se aggiunta, una nuova versione viene creata automaticamente quando una nuova versione dell'artefatto è disponibile per qualsiasi origine dell'artefatto specificato. È anche possibile specificare il ramo di origine della nuova compilazione perché si attivi una versione. È poi possibile impostare filtri di tag per filtrare ulteriormente le compilazioni che devono attivare una versione.

Impostare i valori predefiniti per le origini di artefatti in una versione

Gli utenti possono definire la versione di artefatto predefinita da distribuire in una versione al momento di collegare l'origine di un artefatto all'interno di una definizione (Figura 51). Quando una versione viene creata automaticamente, verrà distribuita la versione predefinita per tutte le origini di artefatto.

Versione di artefatto predefinita

(Figura 51) Versione di artefatto predefinita

Separazione dei compiti per il richiedente e per i responsabili approvazione di una distribuzione

In precedenza, il proprietario di un ambiente poteva impedire agli autori delle versioni di approvare le distribuzioni della versione nell'ambiente in questione. Era possibile, tuttavia, avviare manualmente la distribuzione di una versione creata da un altro utente e approvarla personalmente.

Questa lacuna è stata ora risolta creando per le distribuzioni un ruolo utente separato per l'autore della distribuzione. È possibile impedire l'approvazione delle distribuzioni o all'autore della distribuzione o all'autore della versione.

Approvazioni a livello di versione

È ora possibile scegliere di approvare automaticamente le distribuzioni attivate automaticamente a seguito del completamento della distribuzione in un altro ambiente (Figura 52). L'approvazione di una catena di distribuzioni, in cui i responsabili approvazione sono gli stessi, può essere eseguita in un'unica operazione se si sceglie di non approvare le distribuzioni una per una.

Si supponga di avere due ambienti, Dev e Test, i cui responsabili approvazione pre-distribuzione sono"utenteA" e "utenteB". La distribuzione deve essere approvata da entrambi. Se i criteri dell'ambiente Test sono impostati come illustrato di seguito, durante il periodo di distribuzione utenteA e utenteB dovranno approvare solo l'ambiente Dev. La distribuzione in Test verrà approvata automaticamente. Se la distribuzione di Test viene attivata manualmente, perché il processo di approvazione si svolga correttamente, l'approvazione esplicita prima della distribuzione sarà invece necessaria.

Approvazioni a livello di versione

(Figura 52) Approvazioni a livello di versione

Distribuire in Azure Government Cloud

I clienti con sottoscrizioni di Azure in Government Clouds possono ora configurare l'endpoint di servizio Azure Resource Manager per l'uso di cloud nazionali come destinazioni.

In questo modo è ora possibile usare Release Management per distribuire qualsiasi applicazione a risorse di Azure ospitate nei cloud per enti pubblici tramite le stesse attività di distribuzione (Figura 53).

Cloud per enti pubblici

(Figura 53) Cloud per enti pubblici

Impostare il numero massimo di distribuzioni parallele

Questa funzionalità consente di controllare il numero di versioni in sospeso da distribuire in un ambiente specifico (Figura 54). Se ad esempio la pipeline di versione esegue la convalida delle compilazioni in un ambiente di controllo di qualità e la frequenza di generazione delle compilazioni è maggiore della velocità di completamento delle distribuzioni, è possibile configurare un certo numero di agenti e lo stesso numero di compilazioni da convalidare in parallelo. Ciò significa che ognuna delle compilazioni generate viene convalidata e che il tempo di attesa dipende dal numero di agenti disponibili. Questa funzionalità consente di ottimizzare il processo di convalida, poiché permette di convalidare le n compilazioni più recenti in parallelo e di annullare le richieste di distribuzione precedenti.

Distribuzioni parallele

(Figura 54) Distribuzioni parallele

Miglioramenti relativi al timeout per l'attività Intervento manuale

L'attività Intervento manuale può ora essere rifiutata o ripresa automaticamente dopo che è rimasta in sospeso per il periodo di timeout specificato o per 60 giorni, a seconda di quale dei due periodi si conclude per primo. È possibile specificare il valore di timeout nella sezione delle opzioni di controllo dell'attività.

Esecuzione parallela di Release Management

Release Management supporta ora l'opzione di esecuzione parallela per una fase (Figura 55). Selezionare questa opzione per effettuare il fan-out di una fase usando più configurazioni o più agenti come opzione di moltiplicatore della fase.

Supporto dell'esecuzione parallela

(Figura 55) Supporto dell'esecuzione parallela

Più configurazioni: selezionare questa opzione per eseguire la fase per ogni valore di configurazione. Se ad esempio si vuole eseguire la distribuzione in due aree geografiche diverse nello stesso momento, l'uso della variabile ReleasePlatform definita nella scheda Variabili con i valori "east-US, west-US" consente di eseguire la fase in parallelo, in un caso con il valore "east-US" e nell'altro con il valore "west-US". Più agenti: selezionare questa opzione per eseguire la fase con una o più attività in più agenti in parallelo.

Cronologia della distribuzione di app Web nel portale di Azure

La gestione del rilascio ora aggiorna i log di distribuzione del servizio app di Azure quando viene eseguita una distribuzione tramite l'attività di distribuzione del servizio app. È possibile visualizzare la cronologia di distribuzione nel portale di Azure selezionando l'opzione Recapito continuo nel pannello Servizio App.

Miglioramenti ai test

Eseguire test tramite fasi agente

Tramite l'attività Test di Visual Studio è ora possibile eseguire test automatizzati usando fasi agente (Figura 56).

Viene ora usato un agente di automazione unificato per compilazione, versione e test, con i vantaggi seguenti:

  1. È possibile sfruttare un pool di agenti per le esigenze del test.
  2. È possibile eseguire i test in modalità diverse usando la stessa attività Test di Visual Studio: esecuzione basata su un unico agente, esecuzione di test distribuiti basati su più agenti oppure esecuzione basata su più configurazioni che consenta, ad esempio, di eseguire test con browser diversi.

Eseguire test tramite fasi agente

(Figura 56) Eseguire test tramite fasi agente

Per altre informazioni, fare riferimento a questo post in Microsoft Application Lifecycle Management.

Attivazione di test automatizzati su richiesta

L'hub Test ora supporta il trigger di test case automatizzati da piani di test e gruppi di test (Figura 57). L'esecuzione di test automatizzati dall'hub Test richiede una configurazione simile a quella usata per eseguire test pianificati in ambienti di versione. Per eseguire test automatizzati, nella definizione di versione è necessario configurare un ambiente usando il modello Run automated tests from test plans (Esegui test automatizzati da piani di test) e associare il piano di test. Vedere la documentazione per le linee guida dettagliate su come configurare gli ambienti ed eseguire test automatizzati dall'hub Test.

Trigger di test automatizzati su richiesta

(Figura 57) Trigger di test automatizzati su richiesta

Miglioramenti all'amministrazione

Combinazione dei destinatari per le notifiche tramite posta elettronica

I destinatari della stessa notifica tramite posta elettronica sono ora inclusi tutti insieme nella riga A: e viene inviato un unico messaggio di posta elettronica. In precedenza, venivano inviati messaggi singoli a ogni destinatario. Ciò rendeva difficile sapere chi avesse ricevuto la notifica e stabilire una conversazione sull'evento tramite posta elettronica. Questa funzionalità si applica alle sottoscrizioni sia predefinite che di team, purché siano indirizzabili a più destinatari. A tutti i revisori di una richiesta pull, ad esempio, viene ora inviato un unico messaggio di posta elettronica quando viene apportata una modifica alla richiesta pull stessa.

Altre informazioni sulla combinazione di destinatari di posta elettronica.

Notifiche predefinite

Gli utenti e i team ricevono ora una notifica automatica tramite posta elettronica quando vengono eseguite attività nell'ambito di un account a cui sono direttamente interessati, ad esempio:

  • quando un elemento di lavoro viene assegnato a un utente;
  • quando un utente o un team viene aggiunto come revisore a una richiesta pull;
  • quando un utente o un team è revisore di una richiesta pull che viene aggiornata;
  • quando un altro utente risponde a un commento su una richiesta pull;
  • quando viene completata una compilazione richiesta da un utente;
  • quando un'estensione viene installata o richiesta (solo amministratori).

Gli utenti possono annullare ognuna di queste sottoscrizioni passando alle impostazioni Notifica disponibili dal menu del profilo utente e quindi disattivando l'opzione o le opzioni corrispondenti.

Un account amministratore può disabilitare una o più di queste sottoscrizioni automatiche passando all'hub Notifiche a livello di raccolta tramite l'icona delle impostazioni. Per disabilitare ognuna di queste sottoscrizioni, fare clic su Disabilita nell'azione "…". Una volta disabilitata, una sottoscrizione non compare più nella pagina delle impostazioni delle notifiche personali di ogni utente.

Altre informazioni sulle notifiche predefinite.

Autorizzazioni di gestione delle estensioni

Un amministratore può ora concedere ad altri utenti e a gruppi l'autorizzazione a gestire le estensioni per la raccolta (Figura 58). In precedenza solo gli amministratori delle raccolte (ad esempio i membri del gruppo Project Collection Administrators) potevano esaminare le richieste di estensione e installare, disabilitare o disinstallare estensioni.

Per concedere questa autorizzazione, un amministratore può passare all'hub di amministrazione delle estensioni aprendo il menu Marketplace, selezionando Gestisci le estensioni e quindi facendo clic sul pulsante Sicurezza:

Autorizzazioni di gestione delle estensioni

(Figura 58) Autorizzazioni di gestione delle estensioni

Ricevere notifiche quando le estensioni vengono installate, richiedono attenzione e così via

Gli amministratori o gli utenti in grado di gestire le estensioni ricevono ora una notifica automatica quando un'estensione viene installata, disinstallata, abilitata o disabilitata oppure quando richiede l'attenzione dell'utente. Questa funzionalità è particolarmente utile nelle distribuzioni di grandi dimensioni, in cui la responsabilità della gestione delle estensioni è condivisa da più utenti. Gli amministratori possono disattivare le notifiche nelle impostazioni Notifica disponibili dal menu del profilo disattivando l'opzione relativa alle estensioni.

Gli amministratori possono anche definire sottoscrizioni personalizzate per gli eventi correlati alle estensioni. Un amministratore, ad esempio, può ricevere una notifica ogni volta che un'estensione viene aggiornata.

Ora gli utenti possono anche disattivare le notifiche automatiche relative alle proprie richieste relative alle estensioni.

Autorizzazione agli amministratori TFS per l'aggiunta di sottoscrittori al livello di accesso avanzato

Il livello di accesso Avanzato verrà rimosso dalle versioni future di Team Foundation Server. Fino a quel momento, tuttavia, gli amministratori TFS avranno la facoltà di aggiungere sottoscrittori della piattaforma MSDN e di Visual Studio Test Professional al livello di accesso Avanzato con Update 2.

I sottoscrittori di Visual Studio Enterprise devono essere aggiunti al livello di accesso di Visual Studio Enterprise anziché al livello di accesso Avanzato. Se si è acquistata l'estensione Test Manager, continuare a gestirla nell'hub Utenti all'interno del progetto team da cui l'acquisto è stato effettuato.


Problemi noti

Il rendering dei form dell'elemento di lavoro non viene eseguito correttamente nel Web

  • Problema:

    Se si ha un controllo personalizzato, ad esempio il controllo multivalore, installato per il client Visual Studio ma non per il client Web, non viene eseguito il rendering dei form dell'elemento di lavoro nel Web.

  • Soluzione temporanea:

    È necessario eseguire l'aggiornamento alla versione più recente del controllo. È necessario aggiungere un layout Web che non contenga l'elemento del controllo mancante. È possibile trovare il controllo multivalore più recente per l'aggiornamento a TFS 2017 nella pagina Custom Controls for TFS Work Item Tracking (Controlli personalizzati per la verifica di elementi di lavoro TFS). Per altre informazioni sul layout, vedere la pagina All FORM XML elements reference (TFS 2015) (Informazioni di riferimento su tutti gli elementi XML FORM (TFS 2015)).


The Developer Community Portal Vedere i problemi segnalati dai clienti per Team Foundation Server 2017.