In questo primo articolo di una serie dedicata a Team Foundation Server 2010 (TFS), parleremo dell'Application Lifecycle Management, ossia sulla gestione dell'intero ciclo di vita del software, mentre nel secondo vedremo un caso pratico di migrazione del codice da un repository SubVersion (SVN) a TFS tramite il tool svn2tfs, dando anche qualche sbirciatina al relativo codice.

Le origini

Negli ultimi anni gli sviluppatori di software si sono resi conto dell'utilità di strumenti che li aiutassero a pianificare i progetti, ad organizzare la stesura del codice assieme ai colleghi, e a tener traccia delle richieste del cliente. L'ingegneria del software ha preso sempre più piede e abbiamo assistito ad un'esplosione di CASE tools, ognuno specializzato nella risoluzione di un determinato problema.

Uno dei problemi più diffusi riguarda la tracciabilità del codice sorgente, per sapere quando è stata fatta una modifica, da chi, perché, e quale release implementa certe modifiche, e favorire il lavoro da parte di più sviluppatori sugli stessi sorgenti (quindi su macchine diverse). Queste problematiche vengono risolte con gli strumenti di version control (controllo del codice).
Solitamente questi strumenti assegnano un numero identificativo ad ogni modifica, tenendo traccia dell'autore e della data in cui questa è stata fatta.
Un tipico tool per il version control è il succitato SubVersion.

I team un po' più evoluti necessitano anche di tener traccia delle richieste del cliente, delle decisioni prese sulla loro implementazione e dei bug che emergono durante lo sviluppo.
Esistono vari tool di work item / bug tracking che permettono di far tutto questo; la maggior parte permette anche di esser integrato con i tool di version control e capire perché siano state effettuate le modifiche al codice: quante volte vi è capitato di leggere del codice e chiedervi perché sia stato scritto? Servirà? E se lo tolgo, rompo qualcosa?
Inoltre questi tool solitamente vengono estesi per tracciare informazioni aggiuntive, come ad esempio il tempo stimato ed il tempo speso per la risoluzione di un bug / task, utili per calcolare le metriche. Un esempio di tool per la gestione dei work item è trac.

Con l'evolversi del progetto diventa sempre più difficile testare a mano le varie componenti, per questo motivo sono stati creati i framework per i test, che permetto di scrivere sotto forma di codice i comportamenti attesi dalla nostra applicazione. In pochi secondi diventa possibile verificare che tutto stia funzionando come vogliamo.
Questa pratica rende molto più facile effettuare refactoring (cambiare il codice senza modificarne il funzionamento), inserire nuove funzionalità senza temere di aggiungere bug all'applicazione e inoltre aiuta i colleghi a capire cosa il codice vuole fare o come debba essere usato.
Ci sono vari test framework che possiamo trovare in Internet, uno fra i tanti è NUnit.

Un altro utile strumento è l'agente di build:  si tratta di un'applicazione eseguita frequentemente che come il nome suggerisce, prende il codice sorgente, lo compila in un ambiente neutro (solitamente un server privo di ambiente di sviluppo) e pubblica il prodotto (ad esempio in una shared folder, una pagina web, ecc...).
Lo scopo principale di questo tool è di verificare in continuazione che il codice non sia rotto (i.e. compili). Se si sta usando un test framework viene abbastanza naturale unire al processo di build anche l'esecuzione dei vari test, al fine di verificare che la nostra applicazione, oltre a compilare, funzioni.