Server di build continua (cc.net, hudson, bamboo, ecc ...) esperienza di build remota?

9

Attualmente utilizziamo il server cc.net una volta per il nostro processo di compilazione, che crea sia .net (usando msbuild & nant) che java (usando maven e ant).

CC.net monitora il controllo del codice sorgente e attiva una build remota in esecuzione su un server separato. CC.net quindi raccoglie i risultati.

Quando eseguiamo la build remota, in genere:

esegue nunit o junit o simili usando dati derisi
opzionalmente esegue uno script DB per creare una nuova istanza del database o ripristinare un database da una posizione nota.
esegue selenio o simile all'interfaccia utente di test
esegue emma o ncover per la copertura del codice
costruisce il sistema per vari ambienti di distribuzione (test, accettazione, produzione)

Potremmo avere diverse build in esecuzione contemporaneamente, alcune .net e alcune java (di diversi team di progetto).

È piuttosto dispendioso in termini di tempo per far funzionare le build remote quando creiamo un nuovo progetto e riteniamo che ci debba essere qualcosa di più adatto alle build remote rispetto a cc.net.

Qualcuno ha esperienza con build remote con sistemi di integrazione continua?
Non voglio davvero elenchi di funzionalità di server CI, apprezzerei molto di più sapere come li hai usati in un ambiente multi lingua e multi server.

continuous-integration builds

— Chris Buckett
fonte

8

Hudson (Aggiornamento: nel mondo di oggi, userei Jenkins, una forchetta di Hudson.)

Ho usato hudson in ambienti enterprise sia Java che .NET per progetti ad alta visibilità (probabilmente sei stato in alcuni dei siti). Hudson è solido fin dall'inizio, ma la parte migliore è che ci sono molti plugin da fare per qualsiasi cosa tu voglia. Hudson è altamente configurabile, ha una grande comunità ed è davvero facile da configurare in un ambiente cluster se hai bisogno di più build contemporaneamente. È il mio server CI preferito di tutti quelli che ho usato (CC.NET, Hudson e TFS).

Inoltre, puoi usare il plugin ChuckNorris per farti dare il pollice in su o in giù.

— Ryan Hayes
fonte

1

Hudson è una buona scelta se non stai facendo qualcosa di esotico, ma alla fine della giornata se non puoi fare ciò che stai cercando di fare in uno script batch, è improbabile che Hudson lo faccia altrettanto bene.

— Bill

Hudson ha trasformato Jenkins e Oracle Hudson. Vuoi condividere quale utilizzare?

1

@ Thorbjørn: sono pro-Jenkins. Ci sono diversi motivi , ma quello per me è che Jenkins sta ottenendo uno sviluppo più attivo, soprattutto perché Kohsuke Kawaguchi, il ragazzo principale dietro Hudson, è nel campo di Jenkins. E sembra che Jenkins sia la vera continuazione del progetto che ha iniziato . Oh, e infine, Jenkins ha un logo che non è la clip art di Microsoft!

— Tom Anderson,

@ Thorbjørn - Sono d'accordo con Tom. Non uso Hudson da circa un anno (attualmente uso TFS), ma questo è il consenso generale che ho sentito dire che Jenkins è la strada da percorrere. Ancora una volta, non ho usato neanche da quando sono stati biforcati, ma se dovessi riprenderlo, probabilmente seguirei la via Jenkins.

— Ryan Hayes,

7

Stavamo affrontando questa domanda qualche tempo fa e abbiamo deciso di andare con TeamCity . Abbiamo esaminato solo Hudson, CC e TeamCity. La scelta è stata semplice: TeamCity è diventato il nostro server di build. Si noti che non sono un professionista in questo ed è stata la mia prima esperienza con i server di build in quel momento.

Hudson - Non avevo idea di cosa fare e dove leggere al riguardo. E anche se potevo capire qualcosa lì, non era un'opzione: troppo lavoro. Ho deciso di dare un'occhiata a CC.

Cruise control - lo stesso di Hudson, ma in modo leggermente diverso. Assolutamente nulla può essere compreso lì senza un manuale e un sacco di aiuto da parte di Google. Ho continuato a dare un'occhiata a TC.

TeamCity - TeamCity sembrava il paradiso dopo i primi due. È il più utilizzabile di quei tre. Installa, vai al pannello di amministrazione, configura un progetto (mostra dove si trova SVN, punta a creare file, specifica copertura / test unitari ecc.) E inizia a divertirti. E anche se non posso dire di non aver utilizzato Google, il 95% del processo di installazione è stato molto semplice e chiaro. Consiglio vivamente questo strumento. Vai a dare un'occhiata. Ti farà risparmiare un sacco di nervi e tempo :)

Dovrei anche notare che TC non è gratuito. Sebbene abbiano un'edizione gratuita che può essere utilizzata in progetti commerciali con alcune limitazioni (max build configs 20), dai un'occhiata alla loro pagina dei prezzi.

PS: suono come se lavorassi per TC, ma davvero non :)

— Jefim
fonte

3

Usiamo CC.NET 1.4.

Stiamo provando a passare a 1.6 ... che incubo.

È potente ... ma SOLO se lo usi correttamente e capisci come tutto combacia. Il che è molto da chiedere a tutto il team. Abbiamo "buildmaster" che hanno accesso al server e possono cambiare le configurazioni. Anche così, c'è un sacco di google per quanto riguarda ccnet e l'intero business è diventato un casino enorme.

Personalmente voglio passare a TeamCity.

Ti consiglio di evitare ccnet.

— Nessuno
fonte

1

buona domanda. Attualmente stiamo anche cercando di scoprire quale strumento si adatta meglio a noi. Quindi potrò solo raccontarti una piccola esperienza. Ma saremmo molto interessati a quale sistema CI hai scelto ora e per quali motivi. Quindi, ti preghiamo di tenerci informati.

Sono rimasto molto colpito da quanto sia alto il livello del tuo CI. Devo ammettere che abbiamo meno requisiti perché non eseguiamo ancora test dell'interfaccia utente e non creiamo istanze di database o simili, usiamo solo mock per i nostri test unitari.

Ora alle nostre esperienze fino ad ora:

Per i progetti Java stiamo usando Bamboo che funziona benissimo usando JUnit ed Emma. E non ci sono molti sforzi per creare un nuovo progetto.

Per i progetti .NET stiamo ancora cercando la soluzione migliore

Cruise Control: non siamo ancora riusciti a farlo funzionare a causa di problemi con la connessione al nostro repository
TFS:

a) Vi sono alcuni passaggi di configurazione necessari per poter eseguire il primo build.

b) Ci sono alcune insidie in cui devi superare i diritti di accesso. Ci sono molti ruoli che puoi definire e devi sapere esattamente quali diritti hanno il tuo processo di costruzione e quali hanno il tuo account di accesso personale. Ma se hai abbastanza tempo per gestire, puoi definire ogni particolare granularità di cui hai bisogno.

c) Per quanto riguarda le librerie di riferimento ci sono anche alcune cose da gestire se si desidera condividere le librerie per molti progetti e non si desidera gestirle in ogni singolo progetto

d) Eseguire il test NUnit non è così facile come pensavamo. È semplice solo se si utilizza l'esecuzione del test fornita da Visual Studio, ma questa non è NUnit

e) Non abbiamo ancora provato a eseguire NCover (prima cosa :-))
Hudson: strumento successivo che proveremo. Sembra avere un plugin davvero buono e facile per .NET, ti farò sapere come ha funzionato
Bamboo: Prima previsione che abbiamo ottenuto: "Troppo specifico per Java". Ma forse proveremo comunque il plugin .NET, te lo farò sapere

Spero di poter continuare questa discussione e scambiare esperienze.

Andy