Uno dei punti cardine di un buon processo di sviluppo è stabilire chiaramente cosa significhi che un qualcosa sia completato.

La cosiddetta Definition of Done [DoD] nasce in Scrum, ma è evidente che può, anzi deve, essere adattata a qualunque processo per raggiungere dei risultati accettabili

Sostanzialmente si tratta di una lista di attività, che vanno dallo scrivere codice, al testing, arrivando fino alle release note che aggiungono valore al prodotto. In Scrum è estremamente enfatizzata, cosiccome dalla Continuous Delivery, che quindi pretende che done corrisponda a shippable.

Naturalmente non esiste una DoD universale: va adattata in base allo scenario, al processo utilizzato e soprattutto al livello in cui la stiamo applicando: una DoD di un check-in non corrisponde alla DoD di uno sprint o di un backlog.

E’ essenziale che sia trasparente a tutti i membri del team, e tutti i criteri della DoD devono essere soddisfatti per ogni Product Backlog Item.

Modellare la DoD sul processo significa sostanzialmente utilizzare gli strumenti a disposizione per far si che il workflow di lavoro vada a configurarsi per seguire i passaggi della DoD del team.

Team Foundation Server ci aiuta in vari modi: innanzitutto con le Check-In Policy. Rispettare una serie di Check-In Policy significa dover rispettare alcune regole, quindi aderire alla DoD. Queste regole raggiungono il loro apice con un Gated Check-In, che funge da barriera netta: dentro o fuori. Ovviamente è possibile scrivere altre policy oltre a quelle presenti di default in TFS oppure utilizzare il Check-In Policy Pack for TFS, disponibile su CodePlex.

Nel caso in cui il check-in sia rigettato, è possibile eseguire uno shelve (che purtroppo vedo ancora poco utilizzato in molti casi). Con lo shelve, oltre a poter accantonare quel determinato task e quindi essere pronti per eseguirne un altro in attesa di nuovi sviluppi, si hanno molti piacevoli side effects.

Il primo è sempre in ombra ma in realtà estremamente importante: il backup. Infatti tutti gli shelveset sono coperti dal backup di Team Foundation Server.
Inoltre uno shelveset può essere oggetto di Code Review (in vari modi, a breve dedicherò un post alla nuova funzionalità in Visual Studio 11) da parte di altri membri del team, a tutto vantaggio della qualità.
Senza contare poi che gli shelveset rimangono proprietà intellettuale del proprietario, non essendo solamente un pezzo di codice che rimane lato client ma comunque qualcosa che rimane lato server e quindi all’interno dell’organizzazione.

Voglio spiegarvi rapidamente come configurare il TFSPS Feature Pack, visto che risorse in italiano (eccezion fatta per la machine translation di MSDN) non esistono.

Innanzitutto, fondamentale: non usare Network Service come service account di TFS. Non funziona con Project Server, tira fuori errori in fase di configurazione.

Una volta installato il Feature Pack (configurando i permessi degli account su Team Foundation Server e Project Server, ed installando materialmente i bit), bisogna effettuare la configurazione.

Sono quattro step da eseguire lato TFS, che elenco di seguito.

Innanzitutto registro il Project Web Access con l’istanza di TFS che ho a disposizione:

A seguire mappo il PWA alla Project Collection:

Dopodichè carico il mapping per i campi:

Ed infine mappo l’Enterprise Project al Team Project:

Questo è tutto ciò di cui c’è bisogno. Magicamente () inizierà a materializzarsi la tab per Project Server nei Work Item.

Se vi capitano errori strani dopo aver configurato Team Foundation Server per utilizzare una farm SharePoint, tipo..

TF30270: The following team project site cannot be created because it already exists: <nome del progetto>.

…ma ovviamente non possono avere senso perchè magari un sito <nome del progetto> non esiste, fate attenzione ad una cosa in fase di configurazione.

Il grant delle Extensions for SharePoint Products, e gli URL nella Team Foundation Administration Console NON devono essere degli FQDN.

Quindi:

• SI –> http://server
• NO –> http://server.domain.tld

Se dovete utilizzare gli FQDN, fatelo a livello di DNS

Anche quest’anno mi è stato rinnovato l’MVP Award, per il terzo anno di fila!

Ci sarà molto di cui parlare in questo anno: TFSPS Feature Pack, Visual Studio ALM 11, strumenti e metodologie.

Buon anno a tutti!

Rilasciati poco fa i nuovi PowerTools per Team Foundation Server, essenziale complemento per chi usa la soluzione di ALM di Microsoft.

La modifica più notabile è che in Eclipse questi PowerTools aggiungono diverse funzionalità come gli Alert, la ricerca nel codice sorgente e la creazione di Work Item da template.

Per ulteriori dettagli, Mr. Brian Harry e qui il download.

Se vi dovesse capitare di provare ad avviare una macchina virtuale in Hyper-V (su una macchina di sviluppo, una workstation, dove vengono fatti girare molti software e non solo VM) e di vedere un simpatico errore che vi dice che la memoria è insufficiente per avviarla, ma in realtà ne avete a disposizione, vi consiglio di controllare quali applicazioni avete in esecuzione.

Mi spiego meglio: semplificando (Raf perdonami se scrivo castronerie) ogni applicazione ha una dimensione minima e massima delle pagine di memoria occupabile (chiamato Working Set).

Mi trovavo nella situazione di avere 6GB di RAM liberi e non poter avviare una macchina da 2GB. Intollerabile.

Ricercando nella KB ho trovato questa patch qui, che però non era applicabile al mio Windows Server 2008 R2. Mi sono armato di Windows Internals, perchè quel “When you try to start a Hyper-V virtual machine, the operation may fail because of a memory allocation issue.” puzzava di bruciato da morire.

Leggendo la sezione relativa al Memory Management e ai Working Set, mi è venuto in mente di cercare dove potessi trovare dei dati espliciti senza iniziare a ravanare coi tools di Sysinternals, ed ho ricordato che in System Information (msinfo32.exe) c’era molto di quello che cercavo.

Infatti, ecco il colpevole:

Quel simpaticone di MetroTwit ha un Max Working Set di 4GB (è in kb il valore)!

Quindi MetroTwit verrà probabilmente rimpiazzato, e io mi sono guadagnato il rancio serale

PS.: Per ulteriori informazioni qui.

Poche ore fa è stato rilasciato il primo aggiornamento di Team Foundation Service, che introduce molte novità (principalmente di frontend) ed è il primo passo verso la versione definitiva.

Prima di tutto, chiaramente, Metro UI:

salta immediatamente all’occhio come l’intera UI sia stata ridisegnata in pieno stile Metro UI e molto più coerente con Windows Phone, Windows 8 rispetto alla precedente UI sempre Metro ma meno ‘strict’.

La nuova zona di ricerca…

…permette di cercare rapidamente all’interno della propria Team Project Collection i Team Project (ricordo, una per utente con un numero illimitato di Team Project fino a circa 16GB di spazio).

Completamente ridisegnata anche la homepage del Team Project, che ora permette di accedere rapidamente ai dati essenziali del progetto ma anche alla board (vedremo fra pochissimo) e al backlog. I nuovi tasti permettono di creare rapidamente workitem.

Le tiles sono completamente editabili direttamente, senza bisogno di passare da ulteriori menù.

Nuova è la possibilità di visualizzare gli shelveset:

E i changeset:

Nei profili utente, a grande richiesta () è stata aggiunta la possibilità di inserire delle foto:

oltre a predisporre la possibilità di una gestione dei temi per utente (attualmente disabilitata).

Altra novità sono gli alert:

E’ stata introdotta una utile funzionalità chiamata Forecast Lines che permette di avere un’idea della durata dello sprint

Questo è tutto per quello che riguarda il lato utente.

Per quanto riguarda l’amministrazione invece, abbiamo un nuovo Control Panel:

La gestione della Team Project Collection e dei Team Project è completamente separata, e soprattutto il Team Project ha ricevuto il maggior numero di novità

Elemento di spicco sono di nuovo gli alert, che possono essere customizzati a piacimento partendo da una ventina di template già pronti.

Questa milestone rappresenta un netto passo in avanti. Infatti nel team sono riusciti a rendere il ciclo di sviluppo, test e QA della durata di una settimana.

Ovviamente non tutti gli aggiornamenti sono come questo, e Brian Harry ci dice che major upgrades come questo sono stati effettuati su base trimestrale, finora. Da ora in avanti l’intenzione è di ‘accorciare’ questa base a un mese circa. Domani dovrebbe postare un nuovo codice di invito per chi ancora non lo ha, ergo…stay tuned!

Per quanto riguarda i feedback, fondamentali: fatevi sentire. Si tratta di un prodotto in continua evoluzione, e i feedback rendono la vita più facile ai team nell’implementare quello che desiderate (ove possibile). Mandateli a me via mail, via commento al blog, alle conferenze, al team tramite UserVoice…insomma, fatevi sentire

Una delle novità di peso della versione 11 di Visual Studio Team Lab Management sono gli Standard Environment.

Rappresentano ad oggi il primo passo verso l’adozione di tecnologie di virtualizzazione di terze parti per quanto riguarda il VSTLM, infatti ci permette di utilizzare macchine Windows ospitate su qualsivoglia hypervisor (VMWare anyone?) o macchina fisica.

Il concetto è molto semplice: ho delle macchine? Ci installo automaticamente gli agent e le uso per il test. Non ho a disposizione feature come snapshot da Microsoft Test Manager, rewind, ecc ma sono cose che posso (per ora) implementare “fuori” da MTM.

Ma vediamo quindi come fare Il prerequisito è di avere un TFS11 con Team Build, anche Team Foundation Service va benissimo, visto che il Build Server va installato on premise.

Installiamo quindi il Test Controller…

A seguire configuriamo il Test Controller, il minimo sindacale è di indicare la Team Project Collection di riferimento.

Finalmente possiamo utilizzare il nuovo MTM per creare uno Standard Environment!

Creo il nuovo Standard Environment:

Inserisco il nome della macchina, le credenziali per l’utente di test (sto usando per comodità lo stesso del setup, ma comunque deve essere amministratore locale sulla macchina di test) ed indico il ruolo che questa macchina ricopre (ce ne sono diversi: client, server, web server, web client, domain controller, database server).
Se necessario posso inserire dei tag.

Ed ora configuro le capability di test. Posso indicare solo il Test Controller per permettere l’esecuzione di test automatizzati oppure indicare anche la configurazione per i Coded UI Test.

Ricontrollo e confermo: farà qualche controllo sui prerequisiti…

Ed infine vedrò la preparazione e la configurazione della macchina.

L’installazione degli agent richiede qualche minuto, niente paura

Finito! Andando sulla macchina indicata prima troverò questo:

che mi indica lo status dei miei test.

Per utilizzare questa macchina per un ciclo di Build – Deploy – Test ovviamente dovrò selezionare il template della Team Build appropriato.

Parliamo dei limiti: è una Developer Preview (per quanto di qualità molto alta IMHO, soprattutto paragonata alla prima CTP dell’allora Codename Rosario – Visual Studio 2010 o la sua prima beta installabile, che era un vero pianto), quindi ad oggi ci sono alcuni limiti imposti:

• Macchine Windows Server 2008, Windows Server 2008 R2, Windows 7. Il supporto a Windows 8 e Windows Server 8 arriverà a seguire.
• Le macchine utilizzate per i test devono essere nel dominio Active Directory, in quanto c’è bisogno di una relazione di trust con il Test Controller per installare automaticamente gli agent. Per usare macchine in workgroup è necessario creare degli shadow account.

Infine, un link alla documentazione

Piccolo tip per chi si sta cimentando con Project Server e Team Foundation Server 2010.

Può capitare di incappare in questa situazione impostando una regola di accept automativo per le attività, e aprendo Project su un Enterprise Project lasciato in check-out per errore/crash/eventuali.

Compare questo avviso…

…ma il progetto non si apre più.

Si risolve facilmente. Basta andare nelle proprietà del server dal Project Web Access:

e selezionare “Force Check-in Enterprise Project.”. Avremo davanti una lista di cosa è rimasto in check-out, e ne potremo forzare il check-in.

Se non si fa questo, il PM si arrabbia perchè non vede più niente ergo, ai posteri!

PS.:

A proposito: il 23 Novembre sarò a blaterare di questa roba a WPC2011. Se ci siete, fatevi riconoscere

Una delle novità più rilevanti per quanto riguarda il Version Control di Team Foundation Server 11 è l’introduzione dei Local Workspace.

Quante volte, lavorando offline, capita di vedere questo avviso?

E soprattutto, modificando un file…

Tutto questo con Team Foundation Server 11 non ci sarà più: ecco a voi i Local Workspace!

Sono l’evoluzione dei workspace serverside, primo passo di Team Foundation Server verso un paradigma che strizzi l’occhio al DVCS*.

Possiamo eseguire modifiche offline senza preoccuparci della connessione al server, infatti i file non sono più readonly, ma totalmente sbloccati.

Riconnettendosi al Team Foundation Server automaticamente verranno evidenziati come in checkout (e in pending change) i file modificati, esattamente come se si fosse sempre stati collegati.

Il trucco consiste in una cartella nascosta che tiene traccia di tutte le nostre modifiche, e che verranno poi rimandate in push al server non appena possibile.

Ovviamente i classici workspace esistono ancora, ma di default alla creazione di un nuovo workspace ne sarà creato uno di tipo Local.

Per chi li avesse già visti, no, non è un DVCS. Non si può fare checkin offline. Non si può consultare la history, ne tantomeno eseguire branch e merge.

* =”DVCS is definitely in our future and this is a step in that direction but there’s another step yet to take.” Brian Harry