Vantaggi di Hudson e Sonar rispetto a processi manuali o script homegrown

4

Il mio collega e io recentemente siamo entrati in un dibattito su un piano proposto sul nostro posto di lavoro. Abbiamo più o meno completato la transizione della nostra base di codici Java in una gestita e realizzata con Maven. Ora, vorrei che ci integrassimo con Hudson e Sonar o qualcosa di simile. Le mie ragioni per questo sono che fornirà un passo di build 'zero-click' per fornire ai tester nuove build sperimentali, che ci permetterà di distribuire applicazioni su un server più facilmente, che strumenti come Sonar ci forniranno metriche necessarie sulla copertura del codice, Javadoc, le dipendenze dei pacchetti e simili.

Pensa che il sovraccarico di arrivare alla velocità con due nuovi framework è inaccettabile e che dovremmo semplicemente raddoppiare la documentazione e creare i nostri script per l'implementazione. Dal momento che pianifichiamo alcune riscritture aggressive per ripagare il debito tecnico degli sviluppatori precedenti (uso gratuito dell'interfaccia Serializable di Java come meccanismo di archiviazione dei file che ci ha prevedibilmente azzannati), sostiene che possiamo documentare mentre andiamo, e che noi finirò comunque per cambiare una grande quantità di codice nel processo.

Io sostengo che avere metriche accurate che Sonar (o riempire il tuo strumento simile preferito) ci fornisce un buon punto di partenza per qualsiasi sforzo di refactoring, per non parlare della manutenzione generale - dopo tutto, sapendo quali sono le classi più scarse documentato, anche se è solo un punto di partenza, è meglio che indovinare da solo.

Mi sbaglio e sto cercando di introdurre più spese generali di quelle di cui abbiamo veramente bisogno? Qualche altro background: un alumni della nostra azienda ora sta lavorando in un laboratorio di ricerca della Marina e ha suggerito questi due strumenti in particolare come uno che hanno avuto un grande successo nell'uso. Il mio collega ed io abbiamo anche avuto la nostra parte di disaccordi amichevoli prima - lui è più del "CLI per tutti, compila Gentoo nel suo tempo libero e usa Git" e io sono più di un "Datemi un'interfaccia grafica intuitiva, gioca con XNA e va bene con il tipo "SVN", quindi qui c'è sicuramente un elemento alcuni di scontro culturale.

    
posta Tom G 11.01.2011 - 22:54
fonte

2 risposte

2

Pensa a cosa ti compra di più e quando.

La mia ipotesi è che si desidera utilizzare Hudson per un server di build e Sonar per fornire "parametri di qualità".

Il server di build è fondamentale ed essenziale! Dovresti solo inviare i binari fuori dalla casa costruiti e testati dal server di build direttamente dai sorgenti nel tuo sistema di controllo del codice sorgente. Per la manutenzione interna, il numero di build deve essere incorporato nei file binari inviati fuori casa. Il valore di questo semplicemente non può essere sopravvalutato!

Le "metriche di qualità" sono belle, ma tu hai bisogno di loro adesso? Mi aspetto che sia meno importante del motore di compilazione e quindi li rimanderò fino a quando il tuo collaboratore non sarà pronto per altro.

Lo troverai MOLTO facile da costruire con Hudson. Così fai, e salva Sonar per dopo.

Si noti che esistono RPM disponibili per i sistemi Linux basati su Redhat che prevedono aggiornamenti automatici con yum che è bello.

E solo per la cronaca: usa i prodotti per questo tipo di cose. Non non costruiscili tu stesso, specialmente per le creazioni di esperti.

    
risposta data 11.01.2011 - 23:54
fonte
1

L'impostazione di uno strumento di creazione continua non è difficile. È abbastanza facile con Cruise Control e la mia comprensione è che Hudson è ancora più semplice. Se hai già una build di un passo con Maven, è qualcosa che probabilmente potresti fare per lo più sul tuo laptop mentre aspetti che termini una riunione orribile. Non è nemmeno così difficile come avvolgere la tua mente nei confronti di Maven. Fallo, sulla tua scatola di sviluppo, se necessario, e dì loro quanto tempo ti ci è voluto. Nella maggior parte delle organizzazioni, avere qualcosa fatto supera qualsiasi teoria su quanto sarà difficile implementare o imparare per il resto della squadra.

Se imposti un obiettivo di implementazione di Maven, avrai anche qualcosa di simile alla distribuzione con un clic. È davvero, davvero carino. Ti renderà più sano di mente. Ho lavorato in posti che hanno tanta simpatia (o fatta da me, o da un ingegnere davvero bravo), e fa la differenza. Ottieni risultati, testati e risolti molto più facilmente, e temi di cambiare meno. È salutare per l'organizzazione.

    
risposta data 11.01.2011 - 23:56
fonte

Leggi altre domande sui tag