Nant e la Continuous Integration

Ogni macchina di integrazione continua non è altro che un software che esegue queste macro operazioni:

1. Verificare se è stato effettuato un nuovo check-in
2. In caso il punto uno sia affermativo scaricare l’ultima codebase
3. Eseguire uno script di integrazione
4. Pubblicare i risultati

Tutto il lavoro viene fatto nel punto tre, è infatti compito dello script svolgere tutte le operazioni di integrazione richieste. Le attività possono essere molte, ma senza dubbio la più importante e imprescindibile è la compilazione di tutti i progetti, grazie alla quale si può sapere se il progetto è in uno stato compilabile.

Una build che non compila viene solitamente detta Broken Build e da questo stato è necessario uscire il prima possibile. Una broken build blocca infatti tutto il team, che per poter lavorare sul progetto è costretto solitamente ad annullare le modifiche, perdendo cosi tempo e rischiando di generare ulteriori problemi.

Lo scenario tipico di una broken build è il seguente (vissuto di persona dall’autore): è sabato mattina, già siete abbastanza stanchi per dovere lavorare il fine settimana, effettuate un get latest e trovate che il codice non compila più. Controllando i cambiamenti notate che sono stati effettuati almeno venti check-in dal vostro ultimo get latest, da altri otto sviluppatori differenti, che naturalmente di sabato sono irreperibili, purtroppo voi dovete effettuare una modifica urgente, ma prima di tutto dovete far compilare di nuovo il progetto.

Grazie all’integrazione continua un eventuale check-in che rompe la build viene individuato immediatamente, ed il “colpevole” può subito rimediare al suo errore. Grazie a strumenti come CcTray, o tramite azioni custom di Nant è possibile infatti reagire ad una broken build in vari modi, magari mandando una mail, oppure generando un alert sonoro e cosi via.

Altre azioni tipiche svolte dallo script di integrazione sono:

• l’esecuzione degli unit test
• l’analisi del codice tramite fxcop
• il calcolo di specifiche metriche, come ad esempio la duplicazione del codice tramite simian

Lo scopo finale è quello di produrre, ad ogni modifica del codice, un report del progetto dal quale è immediatamente possibile stabilire lo stato di salute della trunk.