Alkampfer's Place

Il blog di Gian Maria Ricci
posts - 648, comments - 870, trackbacks - 79

My Links

News

Gian Maria Ricci Mvp Logo CCSVI in Multiple Sclerosis

English Blog

Tag Cloud

Article Categories

Archives

Post Categories

Image Galleries

I miei siti

Siti utili

sabato 24 settembre 2016

Process template Ereditati in VSTS

 

Precedenti post sulla personalizzazione Work Item in TFS

1 – Tfs e customizzazione del process template
2 – Customizzare il Process Template, le basi
3 – Customizzare il process Template, aggiungere un campo ad un Work Item
4 – Customizzare il process template, regole per i campi aggiuntivi dei WI
5 – Personalizzare i Work Item di TFS, ancora qualche regola interessante
6 – Stati e transizioni
7 – Approfondiamo stati e transizioni

Post su personalizzazione VSTS

1- Personalizzare il process template in VSTS

Come detto nel precedente post, la personalizzazione dei Process Template in TFS porta con se il rischio di dovere poi effettuare aggiornamenti manuali dopo un upgrade ad una nuova versione di TFS. In VSTS questa situazione è inaccettabile, dato che non è pensabile che ogni tre settimane, dopo che è stato rilasciato il nuovo sprint, qualcuno debba andare ad effettuare operazioni manuali di aggiornamento.

Per ovviare a questo problema Microsoft ha introdotto una struttura di personalizzazione completamente nuova per VSTS e che sarà in futuro disponibile anche per TFS. Il concetto alla base di questa nuova modalità si chiama Process Template Ereditato, che permette di personalizzare un template senza cambiare quello base (evitando il problema degli aggiornamenti) fornendo inoltre una interfaccia di personalizzazione completamente Web.

Il primo passo è aprire la sezione di amministrazione dei processi, raggiungibile dal menu “Process”

image

Da questa pagina si può notare che ogni processo ha un menù contestuale che contiene alcune opzioni ammissibili su quello specifico processo. Di base quindi l’accesso ai process template non si effettua più tramite i vecchi file XML ma si ha pieno supporto tramite una interfaccia grafica che guida l’utente.

image

La voce New team project permette la creazione di un nuovo Team Project basato su questo processo, export permette invece di esportare il processo in uno Zip, esattamente come avviene per TFS, ma in questo caso  è di scarsa utilità perché non è chiaramente presente una funzione di “import”. Non è infatti possibile modificare un process Template base, per evitare appunto problemi durante l’aggiornamento. Su un template base si può solamente

  • Disabilitarlo (non è possibile più creare Team Process con questo template)
  • Impostarlo come default (verrà presentato come processo di default nel Wizard di creazione nuovo Team Project)

Come detto non è possibile andare a modificare un processo base (l’icona del lucchetto è evocativa). Per quanto riguarda la voce “Change team project to use xxxx” purtroppo si intende un cambio di processo tra processi ereditati; non è ancora possibile convertire un Team Project tra CMMI o Agile o SCRUM o viceversa. E’ quindi ancora impossibile convertire un Team Project passando da uno dei processi base ad un altro.

La voce che interessa è la “create inherited process” che permette di creare un nuovo process template basato su un processo base e che può poi essere personalizzato. Il concetto è infatti quello di creare un nuovo progetto che eredita dal base, effettuare su di esso le personalizzazioni per non intaccare il progetto base. In questo modo ogni aggiornamento del processo base con  un upgrade, si rifletterà nel processo ereditato. Inoltre l’engine di VSTS / TFS è a conoscenza di tutte le personalizzazioni fatte nel processo ereditato, e può quindi sempre sapere come comportarsi.

image

Come si può vedere la creazione di un nuovo processo ereditato è molto semplice, basta fornire un nome ed una descrizione ed il gioco è fatto. Una volta che si è creato un nuovo processo ereditato, è possibile creare nuovi Team Project basati su di esso.

image

Se si hanno già invece dei Team Project che sono stati creati sulla base di un Process Template base (in questo caso CMMI) è possibile cambiare process template assegnando un process template ereditato.

image

In questo caso la voce “Change team projects to use Custom CMMI”, che mostrerà una lista di Team Project basati su CMMI che possono essere migrati al nuovo processo “Custom CMMI”. Si ricordi che se un Team Project è stato creato con SCRUM o Agile non può utilizzare un custom process che è ereditato da CMMI e viceversa.

image

Non è possibile gestire processi che ereditano da un processo ereditato, la gerarchia è per ora limitata ad un solo livello. Non è inoltre nemmeno possibile migrare un Team Project direttamente tra due processi ereditati dallo stesso processo padre.

Una nota a parte merita la security, che permette di definire chi può cancellare, editare ed amministrare la sicurezza dei processi ereditati, in questo modo è possibile restringere le utenze che hanno la possibilità di andare a personalizzare i process template.

image

Concludendo, in VSTS non è possibile editare direttamente un Process Template base, ma è possibile creare un Process Template ereditato e creare nuovi Team Project basati su di esso, oppure migrare Team Project esistenti al nuovo processo (solamente se i processi sono stati creati partendo dal processo base).

Nei prossimi post verranno mostrate le personalizzazioni disponibili in per un process template ereditato.

Gian Maria.

posted @ sabato 24 settembre 2016 11.14 | Feedback (0) | Filed Under [ ALM ]

sabato 10 settembre 2016

Personalizzare il Process Template in VSTS

Sono passati alcuni anni da quando ho fatto una serie di post sulla personalizzazione dei Process Template in Team Foundation Server. Potete trovare tutti i vecchi post in questa lista:

1 – Tfs e customizzazione del process template
2 – Customizzare il Process Template, le basi
3 – Customizzare il process Template, aggiungere un campo ad un Work Item
4 - Customizzare il process template, regole per i campi aggiuntivi dei WI
5 - Personalizzare i Work Item di TFS, ancora qualche regola interessante
6 – Stati e transizioni
7 – Approfondiamo stati e transizioni

Sebbene questa serie di post non copra in modo esaustivo tutte le personalizzazioni possibili, costituisce una buona introduzione da cui partire per personalizzare la gestione dei Work Item in TFS.

La barriera maggiore che si incontra è pero il rischio di incontrare difficoltà nell’aggiornamento di TFS ad una nuova versione. In realtà si può sempre aggiornare indipendentemente dalla personalizzazione dei processi, ma dopo avere fatto l’aggiornamento del server, è necessario andare ad aggiornare (eventualmente) tutti i processi di tutti i Team Project. Questo accade perchè alcune nuove funzionalità introdotte nelle nuove versioni si basano su novità introdotte nei template. Essendo i template di fatto dei file XML, il sistema può aggiornare in maniera automatica i vecchi processi se essi non sono stati modificati (conosce il vecchio XML sa come portarlo al nuovo XML). Purtroppo invece, in caso di modifica, non è detto che l’aggiornamento automatico riesca, dato che il tool non è più in grado di riconoscere il formato originale. In questo caso l’aggiornamento deve essere fatto manualmente.

In realtà l’intervento manuale non è che sia eccessivamente complicato, se si è lavorato bene si dovrebbe possedere nel source control tutta la storia delle proprie modifiche al process template, e la situazione peggiore che si può presentare è quella in cui voi dobbiate

  • Scaricare il template aggiornato dopo l’aggiornamento di TFS
  • Riapplicare al template tutte le modifiche effettuate.

Ad esempio se siete partiti dalla versione X dello scrum, ed avete effettuato su di esso una serie di modifiche, dopo avere aggiornato TFS all’ultima versione vi trovate nella situazione in cui l’aggiornamento automatico del template non riesce. La soluzione è:

  • scaricate in locale la nuova definizione del template Scrum, ora in versione Y dove Y > X
  • procedete applicando le stesse modifiche che avete fatto al vecchio template (le avete nel source control vero?? :) )

Nel caso abbiate effettuato veramente tante modifiche, potete seguire la strada inversa, ovvero leggere da MSDN i cambiamenti fatti al template e riapplicarli sulla vostra versione personalizzata.

Il processo è descritto qui (https://www.visualstudio.com/en-us/docs/work/customize/update-customized-process-template), ed anche se non difficile, è spesso temuto da molti amministratori di TFS. Il problema principale che si incontra è che, a meno di non essere in una grande realtà, dove si hanno amministratori dedicati del proprio TFS, e che conoscono lo strumento molto approfonditamente, nelle piccole realtà l’amministratore del TFS è “causale” e spesso teme di poter generare problemi nell’upgrade manuale. Da quì deriva sicuramente una reticenza alla personalizzazione del template, perdendo quindi uno dei pregi maggiori di TFS.

Fortunatamente questi problemi stanno per finire, dato che in VSTS è stata già introdotta una differente metodologia di personalizzazione del template effettuabile direttamente da UI e che non impatta gli aggiornamenti. Questa funzionalità, verrà introdotta in una versione successiva (purtroppo ancora non definita) di TFS on-premise, come si può vedere dalla feature timeline.

image

Dato che con l’ultimo aggiornamento è possibile in VSTS andare ad aggiungere i propri Tipi Personalizzati di Work Items, siamo arrivati al punto in cui, per quanto riguarda la personalizzazione del process template, molto probabilmente chi usa VSTS è avvantaggiato rispetto a chi usa TFS on-premise. Dato che per anni la mancanza di personalizzazione del process template è stata probabilmente la maggiore mancanza di VSTS, è giunto il momento di effettuare una serie di post per introdurre il nuovo modello di personalizzazione di VSTS.

I vantaggi maggiori sono indubbiamente

  • Personalizzazione effettuata da UI WEB (Addio editing manuale di file XML)
  • Azzerare le problematiche di aggiornamenti
  • Spostare i Team Project tra differenti tipi di processo (per ora solamente tra processi ereditati come vedremo in seguito)

Stay tuned.

Gian Maria

posted @ sabato 24 settembre 2016 10.27 | Feedback (0) | Filed Under [ ALM ]

sabato 3 settembre 2016

Novità in VSTS nella release del 2 settembre

In questa nuova release le novità sono veramente succose, sintomo che il team lavora sodo anche durante l’estate. Indubbiamente la prima importante novità è la possibilità di creare nuovi tipi di Work Item, funzionalità che va a ridurre sempre più il gap di personalizzazione che si ha in VSTS rispetto ad una installazione TFS on premises.

La novità è cosi succosa che ha un post dedicato dove verrete guidati nella creazione di un nuovo Work Item Type nel vostro account VSTS. L’aspetto interessante è la possibilità di includere il nuovo Work Item Type nelle varie board, dando cosi la possibilità di personalizzare molto il vostro account.

custom wit 5

Proseguiamo invece con le altre novità “minori”, come ad esempio la sezione history dei Work Item completamente ridisegnata per una maggiore leggibilità. Ora le modifiche sono raggruppate per range di date ed hanno una navigabilità decisamente migliore, per cui è possibile scegliere una modifica nella history e vedere il dettaglio in un pannello separato.

 

Redesigned work item history tab

Per quanto riguarda la build, la visualizzazione delle code è stata migliorata, in modo da visualizzare in maniera più chiara le build in coda.

Redesigned Queued Builds page

 

Tra le modifiche interessanti troviamo anche la possibilità di richiedere un feedback direttamente dal menù dei work item di tipo feature o PBI Questo permette in maniera molto veloce di creare una richiesta di feedback verso uno StakeHolder.

The new Request Feedback form

Questo scatenerà una richiesta di feedback, che verrà poi eseguita direttamente con lo strumento di Exploratory Testing presente come addin di Chrome.

Creating a new feedback response

Per chi come me ha usato molto i Database Project per Sql Server abbiamo ora la possibilità di eseguire script di deploy verso Sql Azure.

The enhanced Azure SQL Database deployment task

Come sempre queste non sono tutte le novità, per cui vi rimando al post ufficiale.

Happy TFS.

posted @ sabato 3 settembre 2016 10.33 | Feedback (0) | Filed Under [ ALM ]

martedì 30 agosto 2016

Questo è un post di test

Questo è un post di test, non consideratelo. :)

posted @ martedì 30 agosto 2016 19.52 | Feedback (24) | Filed Under [ Testing ]

venerdì 19 agosto 2016

Novità di VSTS nell’aggiornamento del 17 Agosto

Anche se molti saranno in vacanza, gli aggiornamenti di VSTS non si fermano, ed il 17 agosto è stato rilasciato il nuovo sprint. Come sempre i dettagli si trovano nel sito ufficiale a questo indirizzo https://www.visualstudio.com/en-us/news/2016-aug-17-vso.

In questo aggiornamento sono state fatte numerose modifiche alla UI ed alle funzionalità delle pull request, ad indicare come Git è sempre più importante nel processo di sviluppo. Una delle modifiche più carine riguarda la possibilità di visualizzare tutte le modifiche fatte ad un file durante una pull request.

Viewing changes on a pull request

In questo modo è immediatamente evidente il lavoro che viene fatto durante la pull request, in modo da verificare che eventuali suggerimenti o richieste fatte, siano effettivamente portate a conclusione.

La possibilità di commentare inline il codice è decisamente interessante, e finalmente si ha la possibilità di utilizzare Markdown e quindi anche di poter inserire snippet di codice, funzionalità decisamente interessante quando si sta commentando del codice, perché è utilissima per fornire alternative.

Comments

Tra le altre novità interessanti vi sono i Template per i Work Items, funzionalità raggiungibile direttamente dal Work Item

image

Come potete vedere si può creare un nuovo template partendo da un Work Item oppure direttamente gestirli dalle configurazione del progetto. Il capture template vi permette di partire da un Work Item già popolato e scegliere quali campi includere nel template.

image

Una volta che il template è stato creato, vi viene proposto immediatamente il link per il template, tramite il quale è possibile andare a creare un work item basato su quel template.

image

Tutti i template possono essere comodamente gestiti dalla pagine di amministrazione del progetto.

image

Queste sono le due funzionalità più interessanti a mio avviso, ma vi suggerisco di andare a leggere l’articolo ufficiale per una descrizione completa https://www.visualstudio.com/en-us/news/2016-aug-17-vso .

Happy VSTS.

posted @ venerdì 19 agosto 2016 10.26 | Feedback (0) |

martedì 16 agosto 2016

Pillole di TFS/VSTS: pubblicazione risultati test in una build

Dall’introduzione del Visual Studio Test Runner, estendibile con plugin, non si ha più la difficoltà di eseguire Unit Test differenti da MSTest durante una build. Tradizionalmente le difficoltà incontrate erano due

-) Eseguire i test a riga di comando con una personalizzazione della build
-) Convertire il risultato dei test nel formato MSTest affinché potesse essere incluso nel risultato di una build.

Ora che i test NUnit o xUnit possono essere eseguiti direttamente con il test runner standard, si può utilizzare l’azione di esecuzione test nella build, avendo l’accortezza di avere incluso il package Nuget per il test runner apposito nel progetto di test.

image

E’ sufficiente aggiungere il package Nuget del test runner ad un progetto di test ed utilizzare il task build standard Test Assemblies per eseguire gli Unit Test durante la build.

Nel nuovo TFS / VSTS, la parte di esplorazione dei risultati dei test è stata molto migliorata, ed è quindi fondamentale che il risultato degli Unit Test sia correttamente associato alla build.

image

Ma cosa succede se per qualsiasi ragione non sia possibile utilizzare l’azione standard di esecuzione test? Ad esempio i test potrebbero essere eseguiti in altre macchine direttamente da riga di comando con esecuzione remota, oppure i test potrebbero essere eseguiti con un framework custom.

Nel nuovo sistema di build è presente un task dedicato appositamente all’upload dei risultati di test verso VSTS / TFS, chiamato appunto Publish Test Results.

image

L’aspetto più interessante di questo task è che comprende molteplici formati di output, tra cui NUnit JUnit e XUNit nativo.

image

In questo modo, anche se avete un framework di Unit Test custom per soddisfare esigenze particolari è sufficiente ad esempio fornire un output standard di tipo NUnit (https://github.com/nunit/docs/wiki/Test-Result-XML-Format) per poterlo associare direttamente alle vostre build.

Gian Maria.

posted @ martedì 16 agosto 2016 11.47 | Feedback (0) | Filed Under [ ALM ]

sabato 16 luglio 2016

Creare un clone dell’istallazione di produzione di TFS con TFS “15”

Ho appena bloggato nel blog inglese una grossa novità dell’installer della nuova versione di TFS, che per ora è identificata con il nome TFS “15”. Nel nuovo wizard è presente una opzione per automatizzare tutte le procedure di creazione di un clone o istanza di Pre-Produzione del vostro TFS.

La necessità di clonare l’ambiente è necessaria in molti scenari, prima di tutto vi permette di validare le procedure di upgrade, in questo caso create un clone del vostro TFS, eseguite le procedure di upgrade sul clone e poi con tutta calma potete verificare che dopo l’upgrade tutto funzioni correttamente.

Un altro scenario tipico è lo sviluppo di estensioni per TFS, perchè con un ambiente Clonato potete sviluppare e testare i vostri plugin o il vostro software su un clone esatto dei dati di produzione, senza interagire con il server di Produzione.

Potete leggere il post integrale nel mio blog inglese che trovate a questo indirizzo, nel quale ho aggiunto anche altri semplici consigli per minimizzare il rischio che l’ambiente Clonato possa interagire con l’ambiente di Produzione generando confusione e problemi.

Gian Maria.

posted @ sabato 16 luglio 2016 11.22 | Feedback (0) | Filed Under [ ALM ]

mercoledì 13 luglio 2016

Nuovo update di VSTS–7 luglio

Un altro sprint è stato deployato in Visual Studio Team Services il 7 luglio e dovrebbe ora essere disponibile per tutti gli account. Come sempre il team ha pubblicato un post con tutte le novità, ed in questo sprint sono state fatte molte modifiche alla ui ed alla usabilità.

Un aspetto interessante è l’inclusione del code coverage dei test eseguiti durante la build, metrica interessante per tutti i team che fanno uso estensivo di unit testing.

Tutte le restanti modifiche sono relativamente piccoli miglioramenti e potete quindi leggerli nel post originale.

Gian Maria.

posted @ mercoledì 13 luglio 2016 8.49 | Feedback (0) | Filed Under [ ALM ]

martedì 21 giugno 2016

Aggiornamento VSTS del 17 giugno

Questa volta l’aggiornamento è stato più rapido del previsto, il 17 giugno abbiamo avuto un altra wave di aggiornamenti su Visual Studio Team Service. Come sempre potete leggere tutti i dettagli nel blog ufficiale, qui vi farò un riassunto delle mie nuove funzionalità preferite.

Innanzitutto se avete un team corposo ed usate GitFlow è possibile che il numero delle branch in Git diventi elevato, per questo nel tab delle branches è ora disponibile una sezione “my branches” dove vedrete le branch che avete creato voi o a cui avete contribuito. In questo modo è immediato distinguere le vostre branch da quelle di altri componenti del team.

Branch picker featuring Mine

Un’altra importante novità è un nuovo header per la form dei Work Item, in particolare è ora presente in molta evidenza il bottone “Save & Close” che sicuramente è quello più utilizzato, dato che molto spesso dopo che si apre un Work Item se lo si modifica si vuole semplicemente chiudere salvando le modifiche effettuate.

Improved work item header

Per tutti coloro che usano le funzionalità di Test ed in particolare le exploratory sessions, è ora finalmente possibile avere una visualizzazione chiara di tutte le exploratory session effettuate sul progetto.

Insights in exploratory testing

Nell’addin di Chrome è ora possibile anche richiedere la registrazione del desktop da includere in un eventuale bug.

Un’altra interessantissima funzionalità è la possibilità di vedere l’andamento dei test per singole branch, questo è molto importante perché cosi si ha la chiara indicazione della qualità delle varie branch

History tab in the result summary page

La funzionalità sicuramente più corposa è però data dalla possibilità di personalizzare il Process Template introducendo stati custom. Questa funzionalità ha un intero post dedicato all’argomento, e costituisce un ulteriore importante passo verso la parità di funzionalità tra VSTS e TFS. Questo permette quindi di avere colonne personalizzabili nella Task Board, grazie alla possibilità di aggiungere stati al Work Item di tipo Task. Non è ancora possibile personalizzare in maniera avanzata le transizioni tra stati (con regole o decidere quali transizioni sono possibili), ma già questa funzionalità rende possibile personalizzare VSTS in modo che si adatti maggiormente alle vostre esigenze.

Per chi sviluppa Java invece è ora possibile effettuare analisi di codice direttamente da un task Maven, senza la necessità di impostare un server Sonar Qube, anche questa funzionalità è abbastanza corposa e descritta in dettaglio in un post dedicato.

Vi invito comunque a leggere il post ufficiale in modo da vedere tutte le novità disponibili.

Gian Maria.

posted @ martedì 21 giugno 2016 19.54 | Feedback (0) | Filed Under [ ALM ]

venerdì 17 giugno 2016

Usare Azure come PAAS e non come IAAS

Si parla tanto di Cloud in questi periodi, e spesso purtroppo l’adozione del Cloud non viene fatto, a mio avviso, nel modo giusto.

Ad esempio, parlando di Azure, se si inizia l’approccio spostando e creando Virtual Machines su Azure il risultato non sempre è piacevole. Se una azienda ha già il suo sistema di virtualizzazione (vmware o Hyper-V) l’avere le VM su Azure non da vantaggi tangibili, soprattutto considerando la banda che abbiamo in Italia.

Se si vuole veramente avvantaggiarsi del Cloud, bisogna approcciare il problema da un punto di vista differente. Per fare un esempio prendo un post scritto dal caro amico Matteo (http://mattvsts.blogspot.it/2016/06/a-simple-vsts-based-pipeline-for-java.html) che spiega come creare una pipeline di Build –> Test –> Release di una app Java in un Azure Web Site.

In questo caso ci stiamo avvantaggiando del cloud in molti punti, e l’esperienza di Matteo è stata molto positiva dal punto di vista dell’operational. Pur non essendo un esperto in java, ma avendo semplicemente un progetto Java con una build di Maven è riuscito in poco tempo a mettere in produzione il prodotto automatizzando tutto il processo.

I vantaggi sono molti

1) Usiamo VSTS, per cui non più sorgenti in casa, abbiamo tutti i tool che servono per la pipeline di sviluppo nel cloud, zero manutenzione
2) Stiamo adottando un approccio DevOps, dove abbiamo automatizzato tutta la pipeline, senza dover mettere nulla in casa.
3) Stiamo rilasciando una applicazione Java standard (un War) per cui non ci stiamo legando a nessuna tecnologia proprietaria che deriva dal Cloud che abbiamo scelto (Azure).
4) Non dobbiamo gestire Tomcat perchè usiamo un approccio PAAS con Azure Web Sites.

Il punto 4 è quello che ci da vantaggio, non dobbiamo installare, manutenere Tomcat, non dobbiamo pensare a creare una infrastruttura di hosting ridondante che ci permetta di essere online 24/7 e soprattutto possiamo modificare le risorse del website a piacimento. Se abbiamo un ecommerce, nel periodo di Natale possiamo semplicemente aumentare le risorse e siamo a posto.

Se al contrario approcciamo il problema installando una VM su Azure dove mettere Tomcat … abbiamo perso in partenza, perchè non stiamo veramente sfruttando il cloud.

Gian Maria.

posted @ venerdì 17 giugno 2016 9.14 | Feedback (0) | Filed Under [ ALM ]

Powered by: