Il progetto piu' complesso che seguo ha repository su perforce.
E' un progetto multi gruppo, nel senso che ci sono piu' gruppi di lavoro che lavorano contemporaneamente per lo stesso sofwtare, con deadline diverse.
Esistono 2 Trunk sempre validi e potenzialmente rilasciabili in produzione in qualsiasi istante, uno per la parte server Java + script di Database, e uno per la parte Client GUI C#.
e infatti il software viene rilasciato in produzione con cadenza mensile.
All'inizio di ogni ciclo di ciascuno dei gruppi di lavoro, evento che puo' capitare capitare (e talvolta capita) in modo asincrono ai rilasci in produzione, viene creato dal trunk (dai 2 trunk, ma da qui in poi come se fosse uno solo) un branch privato per il gruppo, che lavorera' su questo branch.
Al termine del ciclo di lavoro, di durata anch'esso tipicamente mensile viene effettuato il merge del branch nel trunk.
Nella realizzazione di sotto-progetti parecchio complessi alcuni gruppi di lavoro hanno anche lavorato per 3 mesi, non quindi strettamente un mese solo.
Quando mancano 2 settimane dal rilascio in produzione, in maniera appunto asincrona con quello che i gruppi di lavoro fanno, viene preso un nuovo branch dal trunk che sara' il codice "frozen" per il rilascio in questione.
Su questo codice verranno effettuati i test pre-rilascio.
Una prima fase di regression test effettuata dai test server (2-3 giorni),
seguito da una seconda fase di test effettuata dal gruppo Quality Assurance (tipicamente 1 settimana)
poi una terza fase di User Acceptance Test effettuata dai clienti, di 3-4 giorni.
Nel frattempo il gruppo avra' gia' preso un nuovo branch ed avra' gia' iniziato un ciclo. Durante le prime fasi del nuovo ciclo puo' capitare che i test del ciclo precedente elevino un errore e qualcuno del gruppo dovra' switchare sul branch pre-rilascio per correggerli, e poi riportare le correzioni sia sul trunk che sul branch su cui sta' lavorando, e notificare gli altri gruppi di lavoro di integrare tale integrazione dal trunk nei loro rispettivi branch di lavoro.
Ogni gruppo di lavoro e' responsabile per la scrittura dei test automatici (Unit test + Functional Test) relativi al codice che hanno appena scritto. Tali test vengono considerati parte del codice, la certificazione che il codice che e' stato scritto esegue effetivamente le operazioni richieste.
Ogni volta che viene effettuato un commit su qualsiasi branch o sul trunk, tutti i test vengono eseguiti e se c'e' un problema da qualche parte il gruppo (o i gruppi nel caso del trunk) viene notificato relativamente al problema, nel giro di 10 -20 minuti.
Quando il gruppo di Quality Assurance termina la settimana di test manuali, inizia a scrivere i test automatici per coprire i nuovi test che ha appena dovuto effettuare, che andranno ad aggiungersi ai regression test automatici che vengono effettuati dalle macchine all'inizio ciclo di test
Questo relativo al progetto piu' complesso che seguo, che e' di circa 50-60 persone, 4-6 sottogruppi di lavoro a seconda del momento.
Gli altri progetti che seguo sono invece tipicamente costruiti da un unico singolo gruppo di lavoro, e quindi di organizzazione piu' semplice.
Non riesco ad immaginare problemi piu' complessi non coperti, che richiedano quindi un'organizzazione piu' complessa.
Forse per la stesura di grossi framework o sistemi operativi potrebbe essere necessario qualche passo in piu', dato che e' necessario il mantenimento di vecchie versioni di software che invece a noi non e' richiesto, ma le modifiche necessarie al processo non dovrebbero essere troppo invasive.
Ti ringrazio, esempio notevole.
Tuttavia per noi in azienda si tratta di progetti (anche quelli più grandi) molto più piccoli di quello da te esposto quindi credo, infine, di aver già individuato il flusso più appropriato per gestire il software su CVS/SVN.
Un'altra cosa: come vi comportate con il versioning dello schema del o dei DB? Mi sono accorto che questo può essere un problema se non integrato nello stesso modulo sul repository.
Lavoro da solo o in team su progetti Web/Server in Java (Spring framework) e solitamente usiamo MyBatis (ex IBatis) come data mapper, ho visto che ci sono le "migrations" come in Ruby on Rails che permetterebbero di tenere "versionizzati" anche i file di update (la singola migration) dello schema.
Esperienza vostra?
Thanks.
Login
Chat [0]
FAQ
Cerca
))
