Negli ultimi giorni si parla quasi solo di Build, la conferenza, come recitano anche le newsletter di Microsoft che presenterà il futuro di Windows.
Noi di DevLeap saremo ad Anheim per seguire direttamente l’evento e, con l’occasione vedere qualche vecchia conoscenza.
L’idea, se riusciamo come tempi, è registrare al termine di ogni giornata un mini-video per fare il rendiconto della giornata.
Stay tuned
In questi giorni sono fuori per varie consulenze su TFS e ho notato che in pochi conoscono la funzionalità nativa “Follow History”. Spesso capita di rinominare dei file a fronte di una operazione di refactoring (oppure anche solamente per il gusto di farlo…): in un paio di occasioni i file non venivano rinominati per paura di perdere la storia delle modifiche del file stesso.
TFS in realtà si “ricorda” il vecchio nome del file quindi non ci sono problemi a rinominare file di un progetto, così come è possibile rinominare un intero progetto e persino le solution.
E’ anche possibile seguire la storia di un file quando viene creato un branch del progetto; anche una operazione di merge fra due branch non fa perdere “una virgola” alla storia del file.
Oggi, da un cliente abbiamo fatto il conto della serva….questo per “convincerlo” che la cosa più importante per un team di sviluppo, seconda solo al controllo sorgenti, è un sistema di Build automatica.
Uno sviluppatore bravo rompe una build (fa check-in di qualcosa che non fa funzionare la solution) 5 volte l’anno….se ci sono 10 persone nel team…la build si rompe più o meno ogni 4 (QUATTRO) giorni !!!
E in un team non ci sono solo sviluppatori bravi :-)
Anche se ha ormai 3 anni, rivedendo alcune API per estendere TFS…mi sono ritrovato con una slide contentente questo video.
E’ il regalo perfetto per chiunque sia in ansia da Build in Continous Integration….
Ricondivido
Nel 80% delle consulenze su TFS, ho notato che la tendenza è creare un Team Project per ogni applicazione: questo consente di “tenere insieme” le varie informazioni sul progetto come ad esempio Task e Bug, report sull’andamento dello sviluppo e, non ultimo, il repository del controllo sorgenti.
Nei progetti che seguiamo come DevLeap o anche solo come ThinkAhead, spesso, usiamo questo approccio. Almeno il 50% dei progetti sono destinati a software house che poi porteranno avanti il progetto in autonomia.
A fianco dei progetti che rappresentano le applicazioni, spesso si crea un progetto per ogni libreria, che, giustamente vive di vita propria avendo le sue varie versioni, rilasci, test da eseguire, report sul suo ciclo di vita e così via.
Se questo approccio, oltre ad essere il più comune, è spesso il più corretto per team di dimensioni relative e quando stiamo parlando di una applicazione che inizia e termina in un tempo relativamente breve : è semplice tenere sott’occhio le varie informazioni di un progetto/applicazione. Dopo il ciclo di sviluppo, test, deploy, l’applicazione viene manutenuta per risolvere bug e aggiungere piccole funzionalità. Stiamo rientrando nel 50% di progetti che seguiamo.
Ad esempio nel nostro Team Foundation Server, molti progetti (Dompe.LigandBase, Microgate.Lucien, Edisoftware.Navigator ad esempio) rappresentano una applicazione che ha un ciclo di vita che non prevede, almeno per adesso, nuove release che stravolgano la struttura: non voglio dire che non si può fare una nuova aggiunta importante oppure modificare pesantemente uno dei layer, voglio dire che nel momento in cui si arriva a creare una versione completamente nuova (una major release se preferite il termine), potrebbe convenire adottare un approccio diverso.
Se il team è particolarmente grande e/o lavora su un progetto molto lungo (si pensi ad un gestionale che viene portato avanti per anni e che viene spesso “stravolto” come user interface oppure come accesso ai dati), è probabile che l’approccio Team Project per ogni release sia più efficace: si può partire con l’approccio classico e poi creare, al termine di una major relese, un nuovo team project.
Ad esempio, ThinkAhead.SaveThePlanet è una nostra applicazione per Windows Phone 7: stiamo portando l’applicazione su Mango, aggiungendo alcune feature importanti. Abbiamo così creato un nuovo Team Project congelando la versione 1 che resta attiva per risolvere bug sulla versione attuale e rilasciata. Il progetto attuale viaggia così versione la versione 2.
Avere un progetto diverso consente di riorganizzare la struttura della solution, modificare I template di progetto per accogliere altri dati o modificare la metodologia utilizzata. Ad esempio potremmo capire che è il caso di definire nuove Project Area per identificare attività comuni a tutto il progetto (Security ad esempio) e ottenere report più precisi sulle varie fasi di sviluppo. Modificare queste informazioni sul team project originale “sballerebbe” molte delle statistiche.
Per piccoli team di sviluppo (< 50 persone) potrebbe invece avere senso creare un team project per team: questo approccio si adatta bene quandole persone fanno più cose in contemporanea, come ad esempio durante le consulenze su diversi progetti, che utilizzano più librerie condivise. L’approccio è indicato anche su progetti di breve durata (mesi e non anni) che quindi richiedono interventi che si chiudono “presto”.
L’obiettivo di questo corso è quello di approfondire tutte le 5 aree tematiche necessarie per le certificazioni internazionali IASA sulla professione dell’architetto IT. Stiamo quindi parlando di: Business Technology Strategy - Design – Quality Attributes – IT Environments – Human Dynamics.
Maggiori info sul post di Mario Fontana: http://www.linkedin.com/groupItem?view=&gid=2567658&type=member&item=60299568&qid=b1cfc1b1-2095-4ce7-9095-81a294e25d4d&trk=group_most_popular-0-b-ttl&goback=%2Egmp_2567658