FoxyBlog

Se volete migliorare il vostro status di frustrati utilizzatori di VisualSourceSafe 6, ma TeamSystem vi pare troppo (siete un team di soli 2-3 sviluppatori) avete due opzioni (free, e molto usate):

• CVS
• SubVersion

A mio avviso SubVersion è decisamente migliore di CVS, per svariati motivi, tra i quali i checkin atomici, l'uso di http (e ssl) per la connessione al repository, una miglior gestione dei tags e dei branches, la possibilità di lavorare sia in modalità "merge" (come CVS) o "lock" (come VSS, e motivo per il quale molti rimangono ancora fossilizzati su quell'atroce stumento), un plugin quasi funzionante per VS.NET...
Hanno però in comune una cosa: è abbastanza complesso installarli e configurarli su Windows... e anche su Linux non è uno scherzo...

Ma visto che in azienda siamo masochisti, anche se SVN è decisamente meglio, abbiamo deciso cmq di installare CVS, e per di più su Ubuntu: e un mio collega ha appena scritto sul suo blog come farlo... due giorni di lavoro racchiusi in 2 scroll di monitor... andate a vederlo ... ma se volete un consiglio.... se vi dovesse capitare, installate SVN

powered by IMHO 1.3

La Build Machine per SubText è quasi completata, ora manca solo il trasfermento tramite FolderShare al membro del team che la hosterà nella sua farm.

Cosa fa questa build machine?

1. ogni 2 minuti verifica sul repository SVN hostato da SourceForge la presenza di aggiornamenti al codice
2. se è stato fatto una modifica aspetta altri 5 minuti nel caso avvenga un'altro check-in (così si evita di fare due build troppo ravvicinate)
3. se sono passati 5 minuti senza nessun check-in viene attivato, con NAnt, il processo di build che consiste in:
   1. cancellazione di tutte le directory \bin e \obj (così da avere una build pulita) e dei precedenti file di log
   2. aggiornamento del numero di versione in base al numero di build progressivo
   3. build in modalità Debug di tutti i progetti VS che compongono l'applicativo
   4. build in modalità debug del progetto di test
   5. esecuzione di test MbUnit all'interno del processo di NCover : si esegue così lo unit testing e se ne calcola contemporaneamente il code coverage
   6. analisi degli assembly usando FxCop: questo sicuramente è un modo per deprimersi... ma porta ad un miglior codice.. forse
   7. build in modalità di Release
   8. archiviazione della build di Release in un file zip nominato subtext-major.minor.revision.build.zip
   9. viene fatto il calcolo della complessità e della metrica del codice, usando Vil
   10. e in ultimo viene generato un report riassuntivo del code coverage (sapere precisamente le righe coperte dai test è un po' troppo per il report web)
4. terminato il processo di build viene fatto il merge di tutti i file di log e questo gigantesco file viene archiviato come stato della build
5. viene mandata una mail a tutti gli sviluppatori ogni volta che cambia lo stato della build (quando da successfull passa a failed e viceversa)

Per rendere la cosa più complessa ora sul server sta girando la versione 1.1.0.2185 di CCNET, cioè l'ultima build disponibile. Vi chiederete perchè mai ho deciso di usare l'ultima build e non l'ultima versione rilasciata?

Fondamentalmente perchè ha due feature aggiuntive molto interessanti: la prima è che CCTray, l'applicativo per monitorare l'andamento delle build funziona anche via http (banalmente accede ad un file XML con l'elenco dello stato delle ultime build) e non solo via remoting come invece accade con la 1.0.x. E poi perchè è in corso lo sviluppo di un grafico con l'andamento delle build, a mio avviso molto utile per capire lo stato di salute del progetto.

Alla prossima per la procedura d'installazione step-by-step

PS: FolderShare è stato comprato da Microsoft a Novembre 2005, e fa ora parte della loro strategia per Windows Live

powered by IMHO 1.3