Sono nuovo all'integrazione continua. Voglio un consiglio con quale strumento dovrei iniziare a trattare. Vedo che questo è il più grande strumento in questo momento: CruiseControl.NET, TeamCity e Visual Studio Team System.Integrazione continua - con cosa avviare: CruiseControl.NET vs TeamCity vs Visual Studio Team System
Sto usando questi strumenti: Visual Studio 2010, Mercurial, NAnt, NUnit.
Sia TeamCity che CruiseControl.NET funzioneranno correttamente per questo set di strumenti. Inoltre è possibile prendere in considerazione alternative:
La differenza è:
1) Prezzi CruiseControl.NET e Hudson sono gratuiti e open source, mentre Visual Studio Team System e TeamCity costano denaro (tuttavia Professional Edition di TeamCity è gratuita).
2) Processo di impostazione. Tutti i sistemi hanno un'interfaccia utente abbastanza semplice per ottenere processi di integrazione continua eccetto Cruise Control .NET - utilizza invece file di configurazione basati su XML (Example)
Essenzialmente tutto ciò che serve dal sistema di integrazione è solo per eseguire script nant su evento di commit e mostra rapporto. Ogni sistema di integrazione continua può farlo. Vorrei raccomandare Hudson perché è:
Mentre si dice che l'edizione Professional di TC è gratuita, sento che la stai travisando in modo un po 'scadente. Si consiglia Hudson perché è gratuito e facile da configurare, entrambi ugualmente veri per TC. Raggruppate TFS e TC nella stessa barca, quando uno costa denaro significativo e l'altro può essere libero con poche limitazioni, di cui per lo più riguardano i grandi clienti. Personalmente, suggerirei che TC, Hudson e CC.NET siano nella stessa categoria di prezzo, e TFS, FinalBuilder, Bamboo ecc. Nell'altro. –
Teamcity a meno che non ti piaccia modificare i file XML.
Suggerirei TeamCity - gratuito fino a tre agenti, 20 progetti e 20 utenti, gestisce una serie di costruttori (incluso NAnt) e possono analizzare i risultati di NUnit (anche Hudson può fare tutto questo, credo, ma non l'ho usato, quindi non posso parlare per esperienza).
Dopo aver lavorato con TFS, TeamCity, Bamboo e CC.NET, posso dire che TC era il più semplice da installare e in esecuzione, il più semplice da implementare più agenti remoti, ottenere informazioni sulle build e integrato perfettamente con jabber, email, studio visivo, vassoio attività Windows ecc. Mi sono sentito bene.
Ho appena installato teamcity per la prima volta per estrarre e creare un repository mercuriale su codeplex in circa 15 minuti. Sto ancora lavorando ai test ma ho un buon feeling a riguardo. –
10 minuti in più RTFMing e I sono in esecuzione uno stack CI completo. Stupefacente. Indolore. L'ultima volta che ho creato è stato CC.Net alcuni anni fa. Doloroso. –
Controllare anche Pulse http://zutubi.com/. Sembra essere un po 'caro però. Usiamo TeamCity e mi piace molto, la mia unica lamentela o osservazione è che è stato costruito prima di tutto per le build del codice Java. Con il passare del tempo l'hanno reso più generico, ma un'azienda che crea strumenti Java tende ad inclinarsi in un senso e in qualche modo si ottiene quel sentimento con TeamCity, anche se come dicevo oggigiorno non è tanto vero come alcuni anni fa. Lo usiamo da build Java a build di database SQL Server e funziona davvero bene.
Vedere this question su cc.net vs teamcity per ulteriori informazioni.
Se ti piace, puoi sempre usare easyCIS.È economico, facile da configurare e non devi mai sapere di cosa sono quegli script di costruzione. VS2010 è una funzionalità pianificata fino a quando non passa a RTM.
Visual Studio Team System è un altro contendente. http://en.wikipedia.org/wiki/Visual_Studio_Team_System –
In realtà sceglierei [Hudson] (http://wiki.hudson-ci.org/display/HUDSON/Meet+Hudson) su CC.NET, come [molti would] (http://stackoverflow.com/questions/582687/ci-hudson-with-net-vs-cruisecontrol-net) –
VSTS non è un'opzione per lui poiché usa Mercurial, NAnt e NUnit. TFS Build funziona con il controllo del codice sorgente TFS. –