stavo per rispondere a
questo post, poi mi sono accorto che e' disabilitato il feedback, quindi posto qui il mio commento.
in realta' non hai *risolto* il problema, prima o poi qualcuno dovra' fixare il codice che ha 'rotto' la build. hai soltanto aggiunto un ritardo tra quando il problema e' stato introdotto (durante la scrittura del codice), a quando il problema sara' visibile (la build di CC.NET che fallira').
in realta' chi notera' che la build si e' rotta potresti non essere tu (o chi ha aggiunto il codice incriminato) e quindi sara' piu' difficile localizzare e correggere l`errore. 5 minuti non mi sembrano affatto molti, prova a considerare i vantaggi che hai nel feedback immediato sulla correttezza del tuo codice, rispetto a dover correggere a posteriori l`errore di qualcun`altro.
in azienda noi seguiamo una politica di questo tipo: mentre sviluppi esegui solo i test della parte che *pensi* sia influenzata dal nuovo codice (classi correlate e qualche test di accettazione che tocca quella parte), ma poi prima di integrare e committare le modifiche viene eseguita tutta la suite di test, due volte: la prima solo sulla propria versione del codice, la seconda dopo aver prelevato le modifiche dal repository e corretto i conflitti.
questo perche' la rottura di una build e' una cosa seria: in alcune aziende ci sono riti di fustigazione pubblica dei colpevoli (cappelloni ridicoli da dover indossare per tutto il giorno) o sirene di allarme che suonano per l`ufficio! questa invece e' una
lava-lamp collegata a CC.NET
ciao!
-papo-