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

Vorrei chiederti quale ambiente di build automatizzato consideri migliore, sulla base dell'esperienza pratica. Sto progettando di fare un po 'di sviluppo .Net e un po' di Java, quindi mi piacerebbe avere uno strumento che supporti entrambe queste piattaforme.

Ho letto e scoperto CruiseControl.NET , utilizzato per lo sviluppo di stackoverflow , e TeamCity con il suo supporto per gli agenti di compilazione su diverse piattaforme OS e basato su diversi linguaggi di programmazione. 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, molto meno al fatto che CC è open source e TC è soggetto a licenza a un certo punto quando hai molti progetti da eseguire (perché, io ne ho bisogno per una piccola quantità di progetti).

Inoltre, se c'è qualche altro strumento che soddisfa quanto sopra e ritieni che valga la pena di essere raccomandato, sentiti libero di includerlo nella discussione.

Ho lavorato su e con strumenti di integrazione continua da quello che ha generato Cruise Control (versione java). Ad un certo punto li ho provati quasi tutti. Non sono mai stato più felice di quanto lo sia con TeamCity. È molto semplice da configurare e fornisce comunque una grande potenza. La pagina delle statistiche di compilazione che mostra i tempi di compilazione, il conteggio degli unit test, la percentuale di passaggi ecc. È molto carina. 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 questo è tutto ciò di cui ha bisogno (oltre alla posizione del controllo del codice sorgente). Abbiamo anche usato alcuni complicati script MSBuild con esso e fatto costruire il concatenamento. Ho anche superato due aggiornamenti di TeamCity ed erano indolori.

Anche CruiseControl.NET funziona bene. È più complicato da configurare ma ha una cronologia più lunga, quindi è facile trovare soluzioni sul web. Poiché CruiseControl.NET è open source, hai anche la possibilità di aggiungere o modificare ciò che preferisci. Avevo usato CruiseControl.NET sin dal suo rilascio e ho scritto parte del codice iniziale per cc.tray (per fortuna riscritto da qualcuno che lo sapeva meglio).

Anche Cruise, di ThoughtWorks, sembra abbastanza buono ma non vedo un motivo convincente per cambiare. Se dovessi iniziare 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 poche settimane fa ed è stato un altro aggiornamento indolore. Ci ha consentito di sfruttare le capacità di copertura del codice migliorate e il supporto GIT. Ora stiamo anche utilizzando la build personale e le funzionalità di commit pre-testate che sono presenti da un po 'di tempo. Ho solo pensato di dover aggiornare la risposta per indicare che TeamCity continua a migliorare ed è ancora facile da usare.

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

Ma .

Dopo lo screencast Kona: Continuous Integration e Better Unit Testing (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.

ps: spero che in rete ci sia anche un prezioso video CC.NET.

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

Attualmente sto utilizzando TeamCity su un progetto e generalmente 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 funzione killer: Remote Run. Puoi effettuare il "pre-commit" del check in direttamente da IDEA o Eclipse, eseguire una o più configurazioni di build sul server TeamCity e eseguire il commit delle modifiche solo se la build ha esito positivo (ad esempio, la compilazione e tutti i test passano).

Dato che potresti far funzionare sia TeamCity che Hudson in poche ore, potrebbe valere la pena prenderli entrambi e eseguirli fianco a fianco, insieme a qualsiasi altro (come CruiseControl) a cui puoi pensare. Se non riesci a sostenere rapidamente un server CI per eseguire un confronto fianco a fianco, almeno hai un punto dati per una facile installazione e / o configurazione.

Li ho usati entrambi con successo su diversi progetti. Dal punto di vista della configurazione e dell'amministrazione, Team City è molto più facile da gestire. Non devi hackerare 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 finché non arrivi al punto che Team City costa $$.

Ho usato sia CC.net che TeamCity. Ho il compito di configurare e installare TeamCity per la mia organizzazione (5 sviluppatori). La nostra organizzazione utilizza alcune pratiche e strumenti non comuni (almeno per le organizzazioni delle nostre dimensioni), come Perforce per il controllo del codice sorgente e più agenti di compilazione in esecuzione su sistemi operativi eterogenei, che hanno causato alcuni problemi di configurazione iniziale. Tuttavia, il supporto via e-mail è stato assolutamente di prim'ordine per impostare 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 è sufficientemente intelligente da aggiornarsi senza dover riavviare l'agente o i servizi del server, o anche aggiornare la pagina.

Sento che stiamo utilizzando quasi tutte le funzionalità avanzate del prodotto e finora non abbiamo trovato alcun bug. Integrazione indipendente, script NAnt annidati, etichettatura della versione Perforce, lo chiami, lo stiamo facendo.

Consiglio vivamente TeamCity a chiunque cerchi un server di integrazione continua o qualsiasi server di build, davvero.

Senza volerti lanciare strumenti alternativi :-)

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

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

Assicurati che il sistema che decidi si adatti al numero di progetti che ti serviranno per gestire ...

Uso CruiseControl.Net ma non lo consiglierei per la costruzione di molti progetti ... Ho una disposizione (forse un po '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 build. Ogni libreria ha una suite di test. Ogni app ha una suite di test. Realizzo 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 funzionano i trigger del progetto (usano il telecomando per connettersi al server in cui è archiviato il progetto (anche se si tratta di un progetto gestito dalla stessa istanza di CC.Net), quindi estrarre tutti i progetti da quel server e cercare l'elenco in sequenza cercando 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 la tua macchina di compilazione.

Ovviamente è open source, quindi puoi risolverlo ... E sono sicuro che va bene per un piccolo numero di progetti non interdipendenti.

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

Recentemente ho installato cc .net. È un'ottima applicazione ma richiede un po 'di pazienza. Modificherai molto i file di configurazione nel blocco note :)

È in circolazione da un po 'di tempo quindi è ben supportato e normalmente puoi trovare qualcuno che ha fatto quello che vuoi fare prima. Anche l'interfaccia web è .net, il che è stato un vantaggio per noi dato che siamo un negozio Microsoft.

Non ho usato TeamCity ma ho sentito alcuni consigli su di esso e sembra carino.

Ho avuto un'esperienza nell'installazione e nell'esecuzione di CruiseControl (versione Java) su Linux durante la mia precedente azienda. Come la maggior parte delle persone suggerisce, non è la cosa più banale da configurare. È necessario comprendere il suo framework per trovare la configurazione funzionante / gestibile. Tuttavia, una volta superato quel gobbo, sento che CruiseControl è abbastanza flessibile da consentirti di fare diversi tipi di cose per adattarsi a diversi scenari.

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

Non ho un'esperienza diretta con TeamCity. Anche se la sua funzione di commit pre-test sembra abbastanza interessante.

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

Una terza opzione che potresti prendere in considerazione: Thoughtworks 'Cruise. È costruito su CruiseControl, ma offre molte più funzionalità, una configurazione più semplice, ecc. Ecc. Non gratuito (o open source).

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

Uso Teamcity da un anno e mezzo e ho una grande esperienza. Ho integrato una serie di progetti .Net e Java e ho utilizzato strumenti come MSBuild, Maven ecc. Ho trovato Teamcity piuttosto semplice da configurare e utilizzare. Sono riuscito a far funzionare CI anche per alcuni progetti sql, il che è stato un po 'un incubo che avrebbe potuto essere peggiore con altri strumenti CI.
Aggiornato di recente a Teamcity 8.0.6 che è stato indolore. Anche Teamcity fornisce un'API REST che è molto utile per alcuni scenari. Se utilizzi PowerShell per automatizzare le build, su GitHub sono disponibili numerosi script di integrazione Psake / Teamcity