Con quale frequenza dovremmo avviare l'analisi SONAR?

Question

Con quale frequenza dovremmo avviare l'analisi SONAR?

#1 da (5 voti)

3

Ho installato con successo Jenkins e poi Sonar per l'integrazione continua. I primi rapporti non sono così buoni in termini di violazioni delle regole, commenti, duplicazione del codice ...

Ho impostato Jenkins per ottenere lezioni java, eseguire test con cobertura e poi lanciare SONAR una volta ogni notte durante i giorni della settimana.

Ho quindi chiesto agli sviluppatori di dedicare un po 'di tempo e impegno alla correzione delle violazioni delle regole e provare a ridimensionare il codice utilizzando i dati SONAR. Comunque sembra che vorrebbero vedere le loro correzioni in SONAR quasi come le commettono.

Quindi ho avuto scelte diverse:

Lascia che SONAR si avvii una volta al giorno
Permetti agli sviluppatori di avviare da soli l'attività sonar
Diminuisci il tempo tra le build di Jenkins (come ogni 1h)

Seconda soluzione: ho paura del numero di istantanee che appariranno nella storia di SONAR e del fatto che renderà il "confronto dall'ultima build" molto meno utile.

Terza soluzione: un po 'dei problemi della seconda soluzione, aggiungendo che Jenkins avrà un sacco di build, la maggior parte dei quali irrilevanti.

Quali sono le tue esperienze su questi problemi? Grazie

code-quality continuous-integration jenkins

posta Michael Laffargue 01.08.2012 - 13:57

fonte

1 risposta

Leggi altre domande sui tag code-quality continuous-integration jenkins

Design pattern per l'accesso al database ad albero in Java? Numero ragionevole di nodi e spigoli del grafico orientato

score 5 · Accepted Answer

È logico che i tuoi sviluppatori vogliano vedere le loro modifiche non appena le fanno. Molto come se di solito costruisci ed esegui test unitari prima di effettuare il check-in (o unire upstream), è una buona idea eseguire analisi statiche prima di effettuare il check-in (o, ancora, unire upstream). Hanno tutti lo stesso scopo di alto livello: assicurati di non aver introdotto nuovi problemi o di reintrodurre un vecchio problema.

Non so quanto tempo ci vuole per costruire il tuo sistema, ma alcune organizzazioni hanno successo con l'esecuzione di una build e un test ad ogni check in. Se hai un team che esegue spesso il check-in o la fusione o se la build / il ciclo di test / analisi richiede troppo tempo, potrebbe non funzionare per te. Inoltre, come hai accennato, riduce la funzionalità "Confronta dall'ultima build" poiché sospetto che molti dei check in e delle build siano modifiche piuttosto piccole.

Penso che l'opzione migliore sarebbe probabilmente quella di consentire agli sviluppatori di eseguire SONAR localmente come parte del loro processo pre-commit build / test / merge. Ciò sarebbe particolarmente utile se mirano a un particolare problema identificato da SONAR. Prima di effettuare il check-in e la fusione, uno sviluppatore può essere sicuro di aver risolto il problema a cui era destinato senza introdurre nuovi (o più elevati) problemi. Questo eviterebbe anche di ingombrare il tuo ambiente notturno con un gran numero di build: ogni build dovrebbe riflettere il lavoro di una giornata per il tuo team.