Author Archives: Matteo Emili

Aggiungere livelli sopra le Feature in Agile Portfolio Management

Sebbene sia documentato su MSDN, volevo mostrare un ulteriore modo di aggiungere livelli sopra le Feature (Theme ad esempio), che non utilizzi witadmin e utilizzando il buon vecchio Visual Studio 2012 con i suoi Power Tools, limitando quindi le modifiche ai file XML al minimo essenziale.

Ovviamente questo non è possibile con Team Foundation Service – il quale non prevede customizzazioni del genere per ovvi motivi.

Prima di tutto, scarichiamo il Process Template a cui vogliamo aggiungere livelli dal nostro server.

Aprendolo con il Process Template Editor, notiamo subito che le tab Agile e Common Process Settings sono vuote!

image

Il motivo è dato dal fatto che Microsoft ha cambiato la struttura del Process Settings, unendo tutto in un file ProcessConfiguration.xml. Non è un problema comunque, lo sistemeremo.

Quindi, copiamo e incolliamo il Work Item Type Feature.xml, rinominandolo in Themes.xml, e ovviamente modificandone il nome nel WORKITEMTYPE:

image

Importiamolo nel Process Template:

image

Ora possiamo creare una nuova Category usando l’IDE, ed aggiungendo il Theme di cui sopra. Usiamo Custom.ThemeCategory come Reference Name, o qualunque cosa possa andare bene per identificare la Category custom:

image

Torniamo al file Theme.xml. Dobbiamo modificare la Implementation Hierarchy. Questo è molto importante per poter selezionare le Feature come work item figli.

image

Ora, cancelliamo qualunque cosa non sia ProcessConfiguration.xml nella cartella \WorkItem Tracking\Process, e correggiamo come di seguito il file WorkItems.xml dentro \WorkItem Tracking:

image

Creiamo la gerarchia, aggiungendo un nodo alla sezione PortfolioBacklogs del ProcessConfiguration.xml.

image

E’ sufficiente copiare ed incollare quello della Feature, ma è poi molto importante aggiungere parent=”Custom.ThemeCategory” alla Feature preesistente, in modo da tenere la gerarchia lineare ed evitare questo errore in fase di creazione del Team Project: “The following element contains an error: PortfolioBacklogs. TF401096: This element defines the hierarchy relationship between portfolio backlogs and must define a linear hierarchy from bottom to top. The specified hierarchy is invalid.”

image

Inoltre aggiungiamo un nodo alla sezione WorkItemColor, ricordando di seguire il pattern di colori. Qualunque colore andrà bene, ma deve rimanere nella forma di quelli di default altrimenti il Process Template non verrà uploadato.

image

Finito! Ora si può uploadare il Process Template e si otterrà un nuovo livello Themes al di sopra delle Feature, con tutte le funzionalità associate (board, etc.)

Configurare la Hosted Team Build per apps Windows 8.1

Una delle ragioni per usare Team Foundation Service e altri servizi cloud e’ non doversi preoccupare degli update tecnologici, visto che sono eseguiti dal provider.

Team Foundation Service non fa eccezione e oggi, con la Preview release di Visual Studio 2013 e Windows 8.1, gli Hosted Build Server sono upgradati a Windows 8.1!

Ma non si potranno selezionare immediatamente in Visual Studio. Si dovra’ andare nella propria istanza di Team Foundation Service ed abilitarli per il progetto richiesto:

image

Dopo averlo fatto potremo selezionare il Build Controller:

image

Stessa cosa nella Build Definition stessa:

image

Epic e Theme in Agile Portfolio Management

Oltre alla tecnologia in se, l’introduzione della funzionalita’ di Agile Portfolio Management in Team Foundation Server e Service ha un grosso impatto sulla superficie che si va a coprire con il progetto.

Attenzione: in molti casi parlo di progetti medio-grandi. Introdurre concetti come questo in progetti piccoli potrebbe essere controproducente.

image

Fino ad oggi, il modo piu’ comune di approcciare l’agile backlog management e’ stato quelo di creare delle User Story e in seguito suddividerle in task unitari. Questo va benone e non sta cambiando, ma a volte ci si trova di fronte al seguente problema: la User Story e’ troppo grande per essere inclusa in uno sprint.

A volte capita, sfortunatamente. Per risolvere questo problema, ci viene in aiuto il concetto di Epic.

Un’ Epic e’ sostanzialmente una grande User Story, che e’ a sua volta divisa in diverse sottostorie il cui effort e’ compatibile con la durata dello sprint. Si puo’ rappresentare come un obiettivo funzionale. Una Epic contiene una o piu’ User Story tenute insieme da un tema comune. Non si terminera’ mai in uno sprint, solitamente un’Epic e’ una grossa feature (spesso una killer feature) del nostro prodotto. Si gestisce on top, perche’ potrebbe avere impatti anche su altri prodotti nell’organizzazione.

Il Theme e’ in coma a tutto quanto. Parlando in termini di progetto, potrebbe essere una major release. E’ una iniziativa, una pietra angolare del progetto stesso. I Theme guidano la strategia ed esprimono una direzione, per questo sono generalmente non specifici.

Al momento in Team Foundation Service (e presto in Team Foundation Server 2013) si avra’ il concetto di Epic out-of-the-box. Ma come Brian Harry ci ha detto nel suo post, e’ possibile effettuare delle customizzazioni con un basso effort per modificare l’esperienza d’uso e modellare in modo ancora piu’ fedele il processo.

Un salto verso l’Agile Portfolio Management

Fino a ieri, volendo gestire qualcosa in piu’ di User Story e Task, Bug, etc. si doveva usare un certo livello di astrazione e l’uso di tool specifici come Project Server, spesso forzati ad un comportamento ai limiti del consentito.

Con le nuove feature rivelate ieri per l’Agile Portfolio Management possiamo evitare di scomodare Project Server per compiti nei quali sarebbe eccessivo, ma comunque potremo integrarlo con TFS 2013 se necessario.

Prendiamo questo esempio: vogliamo creare un sistema, e una delle sue feaure e’ il cestino dei rifiuti. Quindi creiamo la feature con il nuovo Work Item Type, e la vediamo nel backlog filtrando per feature:

image image

Ovviamente questa feaure avra’ delle user story al suo interno. Diciamo che vogliamo mettere roba nel cestino e svuotare il cestino quando necessario.

Queste sono Product Backlog Item, o Requirement a seconda del  Process Template che si utilizza. Sto usando MSF for CMMI, quindi sono requisiti – ora posso nuovamente cambiare il filtro per visualizzarli:

image image

Ovviamente questi Requirement saranno suddivisi in una serie di Task, non ci sono differenze rispetto al passato. Ecco cosa vedo cambiando ancora il filtro:

image image

Questa vista e’ esattamente quello che vogliamo ottenere. Ed e’ molto piu’ semplice da capire e visualizzare. piuttosto che usare altri strumenti magari in modo improprio.

Allarghiamo questo concetto: puo’ essere utile se si hanno diversi team Scrum a lavorare sullo stesso backlog? E se si hanno backlog differenti (anche se non si dovrebbe…) perche’ non unire tutto nello stesso backlog in questo modo? Era dura spiegare ad alcuni manager come il progetto sta progredendo in termini di feature e copertura del mercato. Ora non lo e’ usando il Work Item Type Feature come una astrazione sul lavoro che stanno svolgendo i team. Ed e’ out-of-the-box, il che non e’ mai male.

Come Brian ha detto, e’ solo l’inizio…c’e’ sicuramente molto ancora da aggiungere qui.

Team Room in Team Foundation Service

Non sono solo uno strumento di chat all’interno del team, le appena annunciate Team Room sono un ottimo tool per arricchire la comunicazione all’interno del team.

Possiamo innanzitutto configurarle per fornire comunicazioni broadcast per specifici eventi, come una build particolare o una specifica modifica nel codice.

image

image

image

image

Ma il meglio arriva con i due tag specifici per la collaborazione: @ e #.

Il tag @ serve per taggare un utente: image  che sara’ poi notificato a riguardo.

il tag # invece serve per menzionare uno specifico work item.

image

Dopo aver cliccato sull’ hyperlink si aprira’ una nuova tab con il work item linkato.

Potra’ sembrare stupido e semplicistico, ma e’ davvero un ausilio utile ed aggiunge valore anche a quelle discussioni ‘informali’ che si trascinano via email, oltre al fatto che essendo salvate su TFS rappresentano informazioni utili al team recuperabili a piacimento.

Migrare branch distribuite da Git a TFS con Git-Tf

Se dovete migrare un grosso repository Git a Team Foundation Server, e’ molto probabile che vi scontrerete contro uno dei problemi piu’ comuni quandi si migra un DVCS verso un centralizzato: capire il ciclo di vita delle branch.

Brevemente, in un DVCS non si ha il concetto di branch che si trova in un VCS come quello di TFS, a causa della natura distribuita, che tende ad avere un numero di branch maggiore, e che permette relazioni fra le branch differenti [molti parent per un’unica child]. Questa struttura non e’ migrabile in Team Foundation Server, che e’ invece un VCS centralizzato e gerarchico.

Si puo’ raggiungere un buon compromesso utilizzando Git-Tf, il tool Microsoft per migrare Git a Team Foundation Server. Dopo aver configurato il repository, si deve eseguire il comando git-tf checkin –deep per replicare ogni changeset invece di un grosso unico commit. Ma si otterra’ un errore:

image

Ecco cosa intendo: se si hanno piu’ parent per una branch figlia,  non si puo’ replicare in Team Foundation Server. Se si effettua un rebase, si modifica la history, e quindi non sarebbe molto corretto da un punto di vista di fedelta’ del dato

Quindi? Si deve utilizzare il comando –autosquash, che andra’ a creare una storia lineare senza modificarla. Come? Analizza le HEAD revision per trovare quella piu’ “vicina” alla branch parent gerarchica. Ovviamente non tutte le gerarchie possono essere replicate da Git a TFS, ma questa soluzione permette un buon livello di fedelta’ alla soluzione originale.

Errore di sincronizzazione dei Work Item con TFS 2012 Update 2

Dopo aver installato Team Foundation Server 2012 Update 2 puo’ succedere che il Work Item Tracking Synchronization Service improvvisamente si blocchi, e che quindi non si vedano piu aree ed iterazioni aggiornate in Visual Studio, Web Access, Excel, etc.

Questi sono i sintomi…

error

image

Ovviamente per fare troubleshooting di questo bug, i log della pagina amministrativa _oi sono essenziali:

image  Vediamo che da un certo momento in poi, un certo numero di job Work Item Tracking Integration Synchronization falliscono…

image …e nella Job History Details troviamo un System.NullReferenceException. Ecco il problema!

Nella RC del Team Foundation Server 2012 Update 3 troviamo una fix  per questo, come dettagliato nel changelog (paragrafo Work Item Tracking nelle fix per Team Foundation Server).

Un chiarimento sul supporto della TFS Integration Platform

Spesso molti pensano che la siccome la Team Foundation Server Integration Platform e’ un progetto open-source non abbia supporto.
 
SBAGLIATO!

E’ l’unica soluzione di migrazione e sincronizzazione supportata da Microsoft. Ma solo se si scarica il package dalla Visual Studio Library, che e’ quello della versione stabile e supportata. Se avete un problema, potete chiamare il Customer Support Service e chiedere supporto.

Invece se si scarica il package da Codeplex (che contiene anche il codice sorgente) potreste avere delle beta, o delle version diverse da quelle supportate, che quindi non vengono coperte dal CSS.

Spero che questo chiarisca le cose su questo argomento molto importante

Smile

Tf undo: risolvere problemi per conto di altri

A volte capita che l’amministratore del TFS deve risolvere problemi causati da utenti inesperti (o che non hanno effettuato un training), e forse il problema piu’ comune e’ quello di effettuare l’undo di “check-out fantasma”.

Ecco la risposta: Attrice Corporation Team Foundation Sidekicks. Bello. Ma a volte non si possono utilizzare tool di terze parti, e quindi ci si deve accontentare di cio’ che Microsoft propone out-of-the-box nell’installazione di Team Foundation Server.

Ecco quindi la vera risposta, sin da Team Foundation Server 2005: aprire il Developer Command Prompt, e lanciare il commando tf undo con gli switch appropriati.

Qui trovate la relativa documentazione.

DevOps per principianti:IntelliTrace alla riscossa!

Abbiamo visto come ridurre il divario tra team di sviluppo e team di Operations in un modo rapido e veloce. C’è molto di più da fare, e tonnellate di strumenti che ci possono aiutare: il principale è, per eccellenza, IntelliTrace.

Quando creiamo un Operational Issue, un log di IntelliTrace è allegato automaticamente al Work Item:
image

ma è dotato solo di un sottoinsieme minimo di informazioni relative alla segnalazione, e probabilmente non contiene tutto il necessario.
Il primo modo sarebbe ottenere manualmente un file .iTrace con la nostra configurazione custom per raccogliere dati. Niente di così difficile, ma se il motto principale di DevOps è “automatizzare tutto”, stiamo andando contro di esso.

O – meglio – posso chiedere ad Operations di registrare un log IntelliTrace dettagliato, naturalmente il tutto integrato con Team Foundation Server.

Si deve solo impostare il Work Item in “Awaiting evidence”, con una nota di risoluzione dicendo di fornirme un file .iTrace.

devops5

Per raccogliere queste informazioni, basta far partire il Collector dalla console di SCOM ed eseguire l’applicazione incriminata. Facilissimo Smile

image

Cosi si può raccogliere uno snapshot dello stato attuale del pool di applicazioni coinvolto, replicando / facendo replicare lo scenario dell’utente, e quindi il nuovo file IntelliTrace puo’ essere allegato al Work Item correlato

Tutti i file di IntelliTrace possono essere memorizzati in una share di rete, una cartella per ogni alert, quindi ricordatevi di tenere d’occhio la dimensione dei file salvati!