CruiseControl [.Net] vs TeamCity per l'integrazione continua?

Question

Vorrei chiederti quale ambiente di costruzione automatizzato consideri meglio, in base all'esperienza pratica. Sto pianificando di fare un po 'di sviluppo .Net e Java, quindi vorrei avere uno strumento che supporti entrambe queste piattaforme.

Ho letto e scoperto CruiseControl.NET , utilizzato sullo sviluppo dello stackoverflow e TeamCity con il suo supporto per gli agenti di build su piattaforme OS diverse e basato su linguaggi di programmazione diversi. Quindi, se hai qualche esperienza pratica su entrambi, quale preferisci e perché?

Attualmente, sono principalmente interessato alla facilità d'uso e alla gestione dello strumento, tanto meno al fatto che CC è open source e TC è soggetto a licenze a un certo punto quando hai molti progetti da eseguire ( perché ne ho bisogno per una piccola quantità di progetti).

Inoltre, se esiste un altro strumento che soddisfa i criteri sopra menzionati e ritieni che valga la pena consigliarti, sentiti libero di includerlo nella discussione.

Answer 1

Ho lavorato su e con gli strumenti di integrazione continua da quello che ha generato Cruise Control (versione java). Ho provato quasi tutti a un certo punto. Non sono mai stato più felice di me con TeamCity. È molto semplice da installare e fornisce ancora molta potenza. La pagina delle statistiche di costruzione che mostra i tempi di costruzione, il conteggio dei test unitari, la velocità di passaggio ecc. È molto bella. Anche la home page del progetto TeamCity è molto preziosa. Per semplici progetti .NET puoi semplicemente dire a TeamCity dove si trova la soluzione e quali assembly hanno i test e tutto ciò di cui ha bisogno (tranne la posizione di controllo del codice sorgente). Abbiamo anche usato alcuni complicati script di MSBuild e fatto il concatenamento di build. Ho anche subito due aggiornamenti di TeamCity ed erano indolori.

CruiseControl.NET funziona anche bene. È più complicato da configurare, ma ha una storia più lunga, quindi è facile trovare soluzioni sul web. Dato che CruiseControl.NET è open source, hai anche la possibilità di aggiungere o modificare quello che ti piace. Avevo usato CruiseControl.NET dalla sua uscita e ho scritto alcuni dei primi codici per cc.tray (per fortuna riscritto da qualcuno che conosceva meglio).

Anche Cruise, di ThoughtWorks, sembra abbastanza buono, ma non vedo un motivo convincente per me cambiare. Se avessi avviato un nuovo progetto, potrei provarlo, ma TeamCity ha fatto un ottimo lavoro nel rendere semplici le cose semplici rendendo il complesso abbastanza indolore.

Modifica: Abbiamo appena eseguito l'aggiornamento a TeamCity 5.0 alcune settimane fa ed è stato un altro aggiornamento indolore. Ci consente di sfruttare le migliori capacità di copertura del codice e il supporto GIT. Ora stiamo anche utilizzando le funzionalità di compilazione personale e pre-testate che esistono da un po 'di tempo. Ho pensato di aggiornare la risposta per indicare che TeamCity continua a migliorare ed è ancora facile da usare.

Answer 2

Ero / sono un grande fan di CC.NET. Al momento abbiamo 5 progetti in CruiseControl e funziona alla grande. Scrivere file di configurazione con la mano può essere doloroso ma va bene.

ma .

Dopo il Kona: integrazione continua e test unitari migliori screencast (il primo 1/3 su TeamCity) Controllerò anche TeamCity. Adoro la dashboard di unit test integrata e l'interfaccia di configurazione.

Penso che tutti dovrebbero guardare questo video prima di scegliere CC.NET o TeamCity.

p.s .: Spero che ci sia anche un prezioso video CC.NET in rete.

Answer 3

Di gran lunga il mio server CI preferito è Hudson. Facile da configurare e gestire, molti bei grafici per mostrare le tendenze a sviluppatori e non sviluppatori e gratuito.

Attualmente sto usando TeamCity su un progetto e in genere ne sono soddisfatto, ma molti dei grafici che genera non sono particolarmente utili ed è più complicato da configurare rispetto a Hudson.

Detto questo, TeamCity è potente, gratuito per molti usi e ha una caratteristica killer: Remote Run. Puoi " preimpegnare " il tuo check-in direttamente da IDEA o Eclipse, esegui una o più configurazioni di build sul server TeamCity e esegui il commit delle modifiche solo se la build ha esito positivo (ad es. compilazioni e tutti i test superano).

Dato che potresti avere sia TeamCity che Hudson attivi in ??poche ore, potrebbe valere la pena afferrarli entrambi e farli funzionare fianco a fianco, insieme a tutti gli altri (come CruiseControl) a cui puoi pensare. Se non riesci a installare rapidamente un server CI per fare un confronto affiancato, almeno hai un punto dati per una facile installazione e / o configurazione.

Answer 4

Li ho usati entrambi con successo su diversi progetti. Dal punto di vista dell'installazione e dell'amministrazione, Team City è molto più facile da gestire. Non devi andare in giro con i file .config come fai con CC e l'installazione è un gioco da ragazzi. Dato che non hai molti progetti, consiglierei Team City su CC fino a quando non arriverai al punto in cui Team City costa $$.

Answer 5

Ho usato sia CC.net che TeamCity. Ho il compito di impostare e installare TeamCity per la mia organizzazione (5 sviluppatori). La nostra organizzazione utilizza alcune pratiche e strumenti non comuni (almeno, per organizzazioni di nostra dimensione), come Perforce per il controllo del codice sorgente e più agenti di build in esecuzione su sistemi operativi eterogenei, che hanno causato alcuni mal di testa iniziali di installazione. Tuttavia, il supporto via e-mail è stato assolutamente di prim'ordine nel configurare tutto. Ho ricevuto risposte alle mie stupide domande in pochi minuti.

L'interfaccia è intuitiva e reattiva, oltre che ricca di funzionalità. Il prodotto sembra molto costoso. La configurazione è semplice e l'interfaccia Web è abbastanza intelligente da aggiornarsi senza alcun riavvio dell'agente o dei servizi del server o persino l'aggiornamento della pagina.

Sento che stiamo usando quasi tutte le funzionalità avanzate del prodotto e finora non abbiamo trovato alcun bug. Integrazione di Ndepend, script NAnt nidificati, etichettatura della versione di Perforce, tu lo chiami, lo stiamo facendo.

Consiglio vivamente TeamCity a chiunque cerchi un server di integrazione continua, o qualsiasi server di compilazione, in realtà.

Answer 6

Senza voler lanciarti strumenti alternativi :-)

Hudson è un'ottima alternativa open source, ho usato CC e CC.net e confesso di ritenere che siano strumenti fantastici. Sto riflettendo sul passaggio a Hudson in quanto sembra molto più facile da configurare e mantenere.

https://hudson.dev.java.net/

Answer 7

Assicurati che il sistema che decidi ridimensiona in base al numero di progetti che ti serviranno per gestire ...

Uso CruiseControl.Net ma non lo consiglierei per la creazione di molti progetti ... Ho una disposizione (forse leggermente strana) in cui ho molte librerie statiche C ++ che compongo in applicazioni. Ogni libreria dipende da altre librerie e le app inseriscono un set di librerie e compilano. Ogni lib ha una suite di test. Ogni app ha una suite di test. Costruisco per 5 compilatori e varianti di piattaforme (Windows).

La prima cosa che ho scoperto è che i trigger di progetto di CC.Net non sono proprio ciò di cui hai bisogno e il multi-trigger non funziona bene con i trigger di progetto. Il modo in cui i trigger di progetto funzionano (usano i telecomandi per connettersi al server in cui è archiviato il progetto (anche se si tratta di un progetto gestito dalla stessa istanza di CC.Net) e quindi estrarre tutti i progetti da quel server e cercare l'elenco in sequenza cercare il progetto che ti interessa ...) significa che non si adattano bene. Una volta superato un certo numero di progetti, scoprirai che CC.Net sta prendendo la maggior parte della CPU per il tuo computer di generazione.

Certo, è open source, quindi puoi sistemarlo ... E, sono sicuro che vada bene per un numero limitato di progetti non interdipendenti.

Per maggiori dettagli sui problemi che ho riscontrato e alcune patch per CC.Net vedere qui http://www.lenholgate.com/archives/cat_ccnet.html

Answer 8

Ho recentemente installato cc .net. È un'ottima applicazione ma richiede un po 'di pazienza. Modificherai molti file di configurazione nel blocco note :)

È in circolazione da un po 'di tempo, quindi è ben supportato e di solito puoi trovare qualcuno che ha fatto quello che volevi fare prima. L'interfaccia web è .net e questo è stato un vantaggio per noi in quanto siamo un negozio Microsoft.

Non ho mai usato TeamCity ma ne ho ascoltate alcune raccomandazioni e sembra carino.

Answer 9

Ho avuto un'esperienza nell'impostazione e nell'esecuzione di CruiseControl (versione Java) su Linux durante la mia precedente azienda. Come molte persone suggeriscono, non è la cosa più banale da configurare. È necessario capirne il quadro al fine di elaborare la configurazione praticabile / gestibile. Tuttavia, una volta superata quella gobba, sento che CruiseControl è abbastanza flessibile da permetterti di fare diversi tipi di cose per adattarsi a diversi scenari.

Inoltre, la documentazione di CruiseControl, la sua pagina wiki contiene anche alcune informazioni utili .

Non ho un'esperienza diretta con TeamCity. Sebbene la sua funzione di commit pre-test sia abbastanza interessante.

L'altro strumento CC a cui potresti dare un'occhiata è Bamboo di Atlassian. È molto più semplice da configurare e l'interfaccia è più bella. Tuttavia, non è flessibile come offre CruiseControl.

Answer 10

Una terza opzione che potresti prendere in considerazione: la crociera di Thoughtworks. È basato su CruiseControl, ma offre molte più funzioni, una configurazione più semplice, ecc. Non gratuito (o open source).

http://studios.thoughtworks.com/cruise-continuous-integration

Answer 11

Uso Teamcity negli ultimi 1 anno e mezzo e sto vivendo un'ottima esperienza. Ho integrato una serie di progetti .Net e Java e utilizzato strumenti come MSBuild, Maven ecc. Ho trovato Teamcity abbastanza semplice da configurare e con cui lavorare. Sono riuscito a far funzionare CI anche per alcuni progetti sql, il che è stato un po 'un incubo che avrebbe potuto andare peggio con altri strumenti di CI.
Recentemente aggiornato a Teamcity 8.0.6 che era indolore. Inoltre Teamcity fornisce una API REST che è molto utile per alcuni scenari. Se si utilizza PowerShell per l'automazione di build, sono disponibili numerosi script di integrazione Psake / Teamcity su GitHub