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