DA2, Enterprise Architecture Strategies

La necessità di avere una figura che possa essere da raccordo delle diverse iniziative IT da un punto di vista architetturale è già abbondantemente evidente e discussa in Disciplined Agile Delivery, tanto da introdurre il ruolo dell’Architecture Owner e il concetto di enterprise awareness (ovvero una consapevolezza architetturale a livello aziendale).

Anche qui è doverosa una nota: in generale con Enterprise Architecture si intende l’organizzazione aziendale nel suo complesso vista nei processi, ruoli, strutture, ecc.. DA2, invece, ne limita il perimetro all’ambito IT, esattamente come per il Portfolio, approccio si rileva decisamente efficace nel percorso di adozione di Disciplined DevOps, rafforzandolo con una serie di strategie a supporto:

  • Reuse mindset, si tratta di promuovere e stimolare il riuso dei diversi assett, dai sevizi, ai componenti ai framework, in modo da creare una architettura solida e riutilizzabile che possa essere riutilizzabile nel tempo. Il “come” i vari assett vengano riutilizzati è oggetto di governance da parte dell’azione del process blade di Reuse Engineering;
  • Technical-debt mindset, si tratta di avere ben chiaro il concetto di “debito tecnico” che, per quanto possa essere ridotto al minimo, è comunque sempre presente nei propri prodotti. Esistono diverse strategie per “pagare” il debito tecnico, a partire dall’utilizzo delle pratiche atte a promuovere la qualità del codice, fino a quelle che prevedono liberamente di tollerare un certo “debito” per raggiungere determinati obiettivi temporali. In ogni caso è necessario sempre puntare alla sua riduzione costante, onde evitare di raggiungere il punto di massa critica e non poter più attuare alcuna azione di miglioramento;
  • Development guidelines, l’obiettivo è quello di definire le “linee guida” (development of guidelines) di riferimento per le attività di tutti i team. Standard di Codifica e Gestione della Sicurezza sono due esempi evidenti di cosa ciò voglia dire e di come la loro condivisione e standardizzazione sia di ausilio anche al delivery e quindi all’ottica DevOps. Resta da evidenziare la necessità di far evolvere costantemente le diverse linee guida per evitare che la loro adozione si trasformi in un vincolo per la crescita e l’evoluzione dei team;
  • Technical roadmaps, è necessario creare un piano per lo sviluppo e l’evoluzione degli aspetti tecnici. Ciò incide praticamente su tutti i livelli aziendali e diventa abilitante per sfruttare nuovi approcci e soluzioni tecnologiche che migliorano i diversi aspetti, dallo sviluppo al continuous delivery. Il punto di partenza è la big picture attuale da cui partire per ipotizzare una serie specifica di evoluzioni che porteranno alle opportune trasformazioni. In particolare è fondamentale analizzare gli aspetti relativi all’Infrastruttura IT nel suo insieme (network, servizi, server, middleware, data source, ecc) e decidere dove posizionarsi nell’IT Infrastructure Strategies Quadrant.

 

da2 it infrastructure quadrant

IT Infrastructure strategies Quadrant

<

p style=”margin: 6pt 0cm 0.0001pt 30px; line-height: 150%;”>Come è ben visibile dalla figura, due sono le dimensioni di rilievo: Ownership, che evidenzia il livello di outsourcing dell’infrastruttura, e Virtualization, che ne sottende la specializzazione.

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.

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

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

DA2, Release Management Strategies

In ambito enterprise, dove più team possono afferire a più progetti, viene a crearsi una rete di Increment da integrare e validare prima di poter procedere alle attività di delivery.

In questo contesto risulta estremamente evidente come adottare un’opportuna strategia di Release Management sia fondamentale per poter gestire con successo i nuovi rilasci, garantendo la disponibilità del sistema e la possibilità di ripristino in caso di problemi bloccanti.

DA2 suggerisce un approccio basto su due differenti insieme di strategie: uno relativo allo scheduling e uno alle azioni di management annesse.

Per quanto riguarda lo scheduling, si incontrano le seguenti opzioni:

  • Slow Cadence Release Windows, si tratta della strategia più datata in cui viene individuata una finestra temporale che consente ai diversi team di effettuare il deploy. Il problema odierno, richiedendo costantemente una disponibilità 24/7 dei servizi, è quello di individuare una finestra temporale opportuna, evitando che gli slot di attività disponibili si saturino prima di aver completato il tutto, fattore che rappresenta un vero e proprio collo di bottiglia per i progetti legati a team multipli. A ciò si aggiunge il fatto che la distanza tra una finestra e la successiva è importante (slow cadence) per cui bisogna attendere molto per poter mettere in produzione le novità. Questi motivi spingono caldamente a sconsigliare questa strategia, anche se possono esistere contesti dove resta necessario impiegarla;
  • Release Train, questa strategia abbraccia la metafora del treno. Il treno rappresenta l’attività di sviluppo nel complesso, mentre le stazioni sono i momenti di rilascio programmato in cui ogni team può effettuare il dispiegamento di quanto realizzato. In sostanza, ogni volta che si raggiunge la stazione (data) di rilascio, tutti i team pronti possono farlo, mentre chi perde la fermata dovrà attendere la successiva. Questo approccio nella pratica risulta decisamente efficace, soprattutto per sincronizzare il rilascio contemporaneo di funzionalità o componenti dipendenti da loro. Uno dei punti più delicati è che, nel caso di rilasci cross-team aggregati per necessità, il team più lento diventa il collo di bottiglia che “sceglie” la stazione di rilascio. Resta, inoltre, il problema di non poter supportare adeguatamente politiche di continuous delivery;
  • Quick Candence Release Windows, è un primo approccio alla riduzione degli intervalli di release in ottica di continuous delivery, mitigando i problemi della slow cadence e di release train;
  • Continuous release availability, non esisto le finestre temporali: semplicemente il team rilascia quando è pronto. Per raggiungere questo obiettivo è fondamentale adottare un approccio DevOps, automatizzando gli aspetti di continuous integration e delivery.

Le azioni di management sono invece caratterizzabili dalle seguenti strategie:

  • Integrated deployment planning, è fondamentale condividere il planning di rilascio tra tutti gli attori interessati, abbattendo i diversi silos, in particolare quelli tra Dev e Ops. In questo aspetto gli Ops sono più abituati a dover condividere le azioni con i Dev, mentre quest’ultimi tipicamente considerano il loro lavoro terminato una volta effettuata la build (se non prima!);
  • Standard development and testing environments based on production, una efficace azione di delivery passa necessariamente attraverso la standardizzazione e la congruenza degli ambienti di test, pre-prod e produzione. Questo richiede un giusto mix di bilanciamento tra le necessità dei differenti team di Dev ed Ops, ma garantisce ottimi risultanti in funzione della robustezza dei processi di delivery;
  • Release service streams, diversi team tipicamente hanno diverse necessità e competenze in relazione alle attività, sia di produzione che di rilascio. Questo implica che un opportuno approccio alla delivery deve tener conto di diverse esigenze, creando stream diversi (ma limitati) per poter supportare i diversi team: da quello che ha necessità di essere assistito dai release manager engineers a quello completamente automatizzato;
  • Release blackout periods, in chiave opposta a quanto visto in precedenze, può essere necessario per alcune realtà identificare i diversi intervalli dove non è assolutamente possibile procedere a nuovi delivery. È il caso, ad esempio, di momenti particolarmente critici come la chiusura dell’anno fiscale;
  • Shared release practices, si tratta di un caposaldo della comunicazione tra tutti coloro che sono coinvolti nel processo, atto a condividere i successi e gli insuccessi per migliorare l’azione complessiva.

È interessante evidenziare che per raggiungere un efficace azione di Continuous Delivery, il software deve avere un’architettura adeguata da poter consentire il deploy di singole funzionalità che inglobano tutti i differenti layer logici. Un esempio molto efficace sono i microservices.

In generale le aziende sono progressivamente passate dalla Slow Cadence alla Fast Cadence, supportate dall’adozione delle metodologie Agile che, a loro volta, con i framework di scaling (OpenUP e SAFe in primis) hanno reso popolari l’approccio release train fino alla nuova frontiera del continuous delivery e deployment.

 

Stary Tuned

DA2, Support (Help Desk) strategies

Riprendiamo il nostro viaggio attraverso le strategie a supporto di Disciplend DevOps, partendo da quelle relative al Supporto alla soluzione. Si tratta di aspetti spesso non tenuti debitamente in conto, ma fondamentali per il successo concreto del proprio prodotto:

  • Online information, si tratta di settare le opportune risorse online che consentono di evitare il noioso e costoso TAGRI (They Ain’t Gonna Read It), ovvero il dover ripetere più e più volte le stesse cose. FAQ, manuali online, video training, sono alcuni esempi di risorse che rientrano in questo ambito;
  • Online discussion forums, viene istituito un forum ufficiale in cui discutere delle problematiche. Lo stesso e’ tipicamente supportato e moderato dai dev stessi e dai “power users” afferenti alle diverse aree. Attenzione a tenere sotto controllo il forum e all’impegno indiretto/atteso di risolvere prontamente i problemi segnalati;
  • Asynchronous support, classico supporto su richiesta tramite email o l’utilizzo di una pagina sul web site ufficiale. Normalmente la richiesta viene presa in carico da un sistema di ticketing e processata anche in relazione dagli eventuali SLA garantiti al cliente;
  • Synchronous support, si tratta del supporto real-time operato tramite telefono, sistemi di messaggistica o video telefono. Il vantaggio e’ che l’utente viene supportato immediatamente, anche se i costi per l’azienda sono rilevanti e il risultato non e’ sempre dei migliori, soprattutto se il servizio viene dato in outsourcing;
  • Support alerts, si tratta di un servizio legato all’eventuale processo di self-recovering grazie al quale il sistema e’ in grado di auto-rilevare eventuali problemi, evidenziarli all’utente e lasciargli la possibilità di entrare in contatto con il supporto dedicato;
  • Developer-led support, il supporto viene effettuato direttamente dal team di DevOps responsabile dell’applicazione.

Il supporto, nelle sue diverse forme, richiede che sia disponibile un Ambiente in cui riprodurre le problematiche evidenziate e sperimentare le possibili soluzioni. In quest’ottica e’ possibile utilizzare:

  • Production, se non sussistono problematiche di sicurezza o di altro tipo che impediscono di effettuare le prove direttamente sugli ambienti di erogazione, gli stessi possono essere utilizzati per lo scopo. Questo consente di operare sullo stesso sistema utilizzato dall’utente finale;
  • Pre-production test sand-box: il team di supporto può sfruttare l’ambiente di pre-produzione per le proprie attività. Se da un lato questo mette al riparo da eventuali rischi per l’ambiente di produzione, dall’altro si basa su un ambiente diverso che potrebbe non essere allineato;
  • Support sandbox, e’ possibile creare un ambiente apposito per eseguire quanto necessario a supporto delle differenti azioni di help-desk. I problemi sono, chiaramente, gli stessi del caso si pre-prod con l’overhead si dover gestire un ambiente ad-hocz.

A proposito della Build di Xamarin (di nuovo)

In aprile, in uno dei miei post (leggilo qui) avevo spiegato come non fosse più necessario aggiungere lo step “Xamarin License” per effettuare la build di una soluzione Xamarin con gli Hosted Agents.
A partire da ora, non è più necessario includere quello step su qualsiasi build Xamarin, sia che si tratti di agenti installati on premises sia con gli agenti Hosted.
Infatti, come riportato sulle note di rilascio del nuovo update di Visual Studio Team Service: 

The Xamarin License step is no longer necessary and has been removed from the build templates shipped with VSTS and TFS 15. As part of this effort we will also deprecate the task. All build definitions that use this task should be updated to remove it in order to prevent any disruption when the task is finally removed.

Buone build a tutti 😉

Novit&agrave; 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.

Welcome Disciplined Agile 2.1

Il mese di agosto e’ stato particolarmente proficuo per DA, tanto che Ambler e Lines hanno presentato una evoluzione del Poster di DA 2 (ora 2.1), che riportiamo di seguito.

da21 poster roles beta

 

Il framework è rimasto praticamente immutato, anche se sul Poster live del sito sono comparsi una serie di ruoli specifici annessi a diverse funzioni. Attualmente essi sono ancora in versione “beta”, ma non mancheremo di parlarne nel prosieguo.

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.

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