Confronto di server CI? [chiuso]

Sto cercando un confronto tra diversi server di integrazione continua (CI) (specialmente concentrandosi su .NET) e non sono riuscito a trovarne nessuno.

Vorrei quindi sapere cosa ne pensate delle diverse soluzioni disponibili, quali sono i pro ei contro, quali sono i requisiti di hosting e perché CI Server XY è il Server che preferite.

Sono interessato ai tuoi pensieri su (sentiti libero di commentare gli altri su):

• Hudson
• Regolazione automatica della velocità
• CruiseControl.NET
• Teamcity
• CIFactory (utilizza CruiseControl.NET)

I punti di interesse sono:

• Configurazione (facile, flessibile)
• Integrazione con SCM (specialmente DSVC come git o hg)
• Integrazione con sistemi di compilazione (MSBuild, NAnt, Rake)
• Integrazione con Testing Frameworks
• Integrazione con Source Anaylsis (Simian, NDepend, FxCop, NCover ecc.)
• WebInterface / Dashboard
• Requisiti infrastrutturali

Nessuna domanda come questa è completa senza un collegamento alla grande matrice di funzionalità CI (archivio Web) che elenca quasi tutte le opzioni CI disponibili.

Ma penso che sia importante guardare avanti all'ambito di ciò che si desidera includere nel proprio sistema CI. Saranno solo build o porterai altri elementi come analisi statica, dipendenze tra progetti, distribuzioni, test funzionali, ecc. Per aiutare con quella pianificazione ho creato questo wallchart su Elements of Enterprise CI (PDF ; nessuna registrazione richiesta). Per favore, non lasciatevi scoraggiare dalla "parola elettronica"; Intendo solo cose oltre la build CI di base con feedback rapido. :)

Non è specifico per lo strumento, ma elenca una varietà di pratiche che potresti prendere in considerazione durante le fasi di pianificazione / valutazione.

Niente di utile in:

• Qualcosa di meglio di CruiseControl per .NET CI?
• Server di integrazione continua
• Hudson o Teamcity per l'integrazione continua?
• Qual è la tua esperienza con il supporto git del server CI (Windows)?
• Server di compilazione e test automatizzato indipendente dalla lingua per più progetti
• Scegliere il server CI corretto per le mie esigenze.
• Crociera contro TeamCity contro CruiseControl.NET
• CruiseControl [.NET] vs TeamCity per l'integrazione continua?
• ecc. ecc. ecc

EDIT : A sottolineato da Jonik in un commento, mi sono perso Qual è la differenza tra Hudson e CruiseControl per i progetti Java? e come e perché si configura una macchina di compilazione C #? . Troverai risposte molto perspicaci. In altre parole, penso che tutto ciò che stai cercando sia già su Stack Overflow.

TeamCity ha la meravigliosa caratteristica di consentire allo sviluppatore di eseguire una build personale prima di impegnarsi. Molto utile!

CruiseControl.NET è il nonno del gruppo ed è quindi un po 'datato visivamente ecc. Poiché esiste da un po' di tempo, Google sa come risolvere molti problemi che incontrerai.

Per questi motivi (tra gli altri), utilizzo CruiseControl.NET al lavoro e TeamCity a casa e nella mia vita open source :)

Sono un utente di CruiseControl.NET fino in fondo. I miei team lo usano al lavoro e io lo uso a casa per progetti personali.

In particolare, CruiseControl.NET mi consente di eseguire l'intero processo CI: build, aggiornamento della versione, test di unità e integrazione, archiviazione del sorgente o del candidato di rilascio, copertura del codice, persino distribuzione al nostro sistema di test al lavoro. È altamente personalizzabile, funziona bene con MSBuild e NAnt e ha anche un'architettura plug-in estensibile.

Fa praticamente tutto ciò di cui ho bisogno.

Il più grande svantaggio: la configurazione a volte è un problema e può richiedere tempo. Ma una volta fatto, è fatto, e come ha detto un altro poster, mi piace vedere il segnale di "build riuscita" perché so che non solo la build stessa ha funzionato, ma anche che la mia unità e i test di integrazione sono stati tutti eseguiti correttamente.

Team Foundation Build è un'opzione e interagisce molto bene con Team Foundation Server. È gratuito fintanto che hai concesso in licenza TFS.

Usiamo Hudson al lavoro. Il motivo principale è che è molto facile da configurare. Puoi eseguire direttamente il war (è un jar eseguibile) o distribuirlo in qualsiasi servlet-container. E sei pronto per iniziare. Inoltre Hudson supporta molti strumenti ed è estensibile tramite il suo sistema di plugin.

Siamo passati da CruiseControl.NET a TeamCity principalmente per la facilità di configurazione. TeamCity ha anche più funzionalità, ma il motivo principale è che una bella interfaccia utente Web è più semplice da usare rispetto ai file di configurazione XML.

EDIT: la maggior parte delle attività che TeamCity farà fuori dagli schemi; quando necessario usiamo NAnt.

CruiseControl.NET: può essere un po 'complicato da configurare (come la maggior parte dei sistemi CI), ma vale la pena perseverare. Al momento l'ho configurato per eseguire test unitari al termine delle build e per produrre installatori Wix su richiesta. Come ha detto Dan, sembra un po 'datato, ma non importa, in quanto ti fornisce molte informazioni facili da trovare e facili da leggere.

Una cosa: assicurati che tutti i tuoi sviluppatori abbiano CC Tray installato, in esecuzione e che punti alle loro build. È una sensazione fantastica ricevere "Un'altra build di successo" nella barra delle notifiche.

Stiamo usando ccnet al lavoro, che va bene per la maggior parte delle nostre esigenze (abbiamo circa 50 build automatizzate), ma ha bisogno di una persona per la messa a punto e la riparazione a tempo pieno.

Se stai partendo da zero, dai un'occhiata a Bamboo. Lo abbiamo esaminato e sembra davvero promettente, ma non soddisfa completamente le nostre esigenze e abbiamo investito troppo tempo in ccnet per passare a Bamboo ora.

Saluti,

Sebastiaan

Ho ereditato un server luntbuild. Non è una buona opzione per un progetto .NET. Se ti accorgi di ricorrere costantemente all'utilizzo del server di compilazione per eseguire attività generiche da riga di comando, allora qualcosa non va. Un buon server di compilazione aveva una buona conoscenza dell'output degli unit test e delle attività di msbuild come comandi più che opachi da eseguire quando il sistema di controllo del codice sorgente cambia.

Mi piace migrare a Team City.

Sono abbastanza nuovo nella scena CI e ho concentrato i miei sforzi su CruiseControl.NET, utilizzando NAnt e Ivy per costruire i miei progetti .NET.

Ho scoperto che CruiseControl.NET è molto adattabile a molti altri strumenti, come NCover / NUnit / ecc. Tutti si collegano a questo e integrano i risultati per un processo di costruzione combinato.

Prossimamente esaminerò TeamCity per il mio interesse, ma penso che CruiseControl faccia un buon lavoro, ma buono solo quanto i tuoi script di build! Se questi sono pantaloni, allora ci si può aspettare che le tue build siano così buone.

Ma in sintesi, CruiseControl.NET è una buona soluzione, ma devo ancora scoprire quanto sia buona la concorrenza in confronto.

Siamo contenti di Hudson . Non ho nulla con cui confrontarlo, ma è stato semplice da configurare e da avviare. Al momento crea solo progetti Win32 C ++ e un programma di installazione, ma stiamo effettuando il porting su Linux e dovrebbe funzionare anche con quello.

Ottiene i repository di Subversion senza problemi e invia avvisi tramite posta, ecc. Finora ci piace. Di nuovo, abbiamo un'esperienza limitata con i confronti.

Lavoro con CruiseControl.NET, TFS 2012 e TeamCity 7.x da diversi anni e credo che TeamCity sia il MIGLIORE grazie alla sua facilità d'uso, all'interfaccia utente comoda e informativa e ad altre fantastiche funzionalità come le dipendenze di compilazione e molto altro. Funziona e basta, lo adoro.