Ci sono diversi framework CI (Continuous Integration) diversi là fuori e mi chiedo quale sia il più popolare. Quali strutture hai utilizzato nelle aziende in cui lavori?
C'è qualche ragione per cui un framework CI è più popolare di un altro - forse questo ha a che fare con le funzionalità che offre, con le cose che si integrano o forse con il suo marketing?
Sembra che l'integrazione continua sia usata di più nei mondi Java e .net di quanto dicono ruby o python. Perché è questo?
Hudson o Jenkins (il quest'ultimo è un fork del precedente). Motivo: è semplice (semplice da installare e da usare) e ha una grande flessibilità. I plugin aggiungono quasi tutte le funzionalità a cui riesco a pensare.
Alcuni anni fa ho usato damagecontrol . Era anche semplice da usare, ma non aveva i plugin. Ma l'autore ha deciso che avrebbe rinunciato alla soluzione semplice e ha iniziato lo sviluppo di una nuova versione, che consisteva di server diversi che comunicano tra loro (che diavolo?). Ciò non ha funzionato bene e il progetto è stato abbandonato. Ero alla ricerca da qualche tempo, ma né cruisecontrol (troppo complicato) né continuum mi hanno davvero preso. Fino a quando hudson, che ha funzionato dal primo momento per me.
Uso TeamCity al lavoro ea casa. Ha un grande supporto per una varietà di build runner ed è estendibile tramite plugin.
Non trattare con pile di XML per la configurazione è un vantaggio enorme nei miei libri e la versione gratuita è sufficiente per le mie esigenze domestiche.
Un problema che ho riscontrato con TeamCity riguarda il tentativo di scaricarlo automaticamente negli assembly .NET della versione. Ho dovuto impostare una soluzione relativamente complicata, ma una volta installato, ha funzionato come un incantesimo.
Personalmente, ho sempre usato CruiseControl e CruiseControl.Net. La ragione per questo ha a che fare con l'economia. Sono ragionevolmente stabili e una volta impostati, c'è davvero poco da fare per mantenerlo. La comunità degli utenti è di solito molto utile e può essere estesa alle tue esigenze.
Detto questo, ci sono un paio di offerte commerciali disponibili di cui sono a conoscenza (una di JetBrains, l'altra di Atlassian) che offrono una migliore esperienza di installazione e supporto commerciale. Ho intenzione di provare queste offerte, ma in realtà non ho ancora avuto una possibilità.
Gli strumenti CI hanno un ruolo più importante da giocare con le lingue compilate rispetto alle lingue interpretate, ma ciò non vuol dire che lo strumento CI sia sprecato nelle lingue interpretate. Quando hai diversi progetti che dipendono l'uno dall'altro, e vuoi assicurarti che una modifica non interrompa accidentalmente le sue dipendenze: gli strumenti CI hanno un valore inestimabile.
Esistono tre classi generali di problemi che gli strumenti CI possono aiutarti a individuare:
Le lingue interpretate non sono compilate, quindi non ci sono errori di compilazione da catturare. Tuttavia, gli altri due problemi sono abbastanza comuni che gli strumenti CI sono utili per i progetti in Ruby / Python / Perl / etc.
La parola chiave negli errori logici e nei punti di test di accettazione è il test "automatizzato". Se non si dispone di una serie di test eseguibili da una macchina, in realtà non si dispone dei maggiori vantaggi degli strumenti CI. Le suite automatizzate possono essere create con il tempo, quindi puoi iniziare in piccolo.
Modifica
Guarda questo bel grafico per il confronto delle caratteristiche di un gran numero di strumenti CI (molti dei quali non sapevo):
CI solido, integrazione stretta con Visual Studio e Git come controllo della versione . Ho visto CI Server più flessibili, come Hudson, ma la stretta integrazione di TFS con altri prodotti rende l'esperienza così perfetta che ha senso per il mio team.
Uso sia CruiseControl.NET che Hudson . Alcune delle mie build sono su una di esse e altre sull'altra.
Perché? Perché non sono l'ingegnere di costruzione e chi è l'ingegnere di produzione li ha impostati in questo modo!
Non ho alcun problema con il modo in cui sono configurate le mie build o le lamentele su entrambi i prodotti. Ti sto riferendo come sono le cose qui, in modo pratico e spero che tu apprezzi questa prospettiva!
AGGIORNAMENTO: Da quando ho postato la risposta, Hudson è stato biforcuto e diventato Jenkins . La suddetta raccomandazione si applica a Jenkins.
Pulse . Fondamentalmente funziona solo, che per un ingenioso ingegnere di costruzione è un grosso problema. Hanno anche un eccellente supporto tecnico. La ragione principale per cui mi piace così tanto è che abbiamo più di 250 progetti e li gestisce senza intoppi; Non posso dire lo stesso per Hudson.
Il nostro team lavora principalmente in Python, C ++ e Java. Usiamo Buildbot per CI. Inizialmente l'abbiamo iniziato perché si integrava con Trac e perché sembrava semplice e diretto. Credo che sia il framework CI di scelta nel mondo Python.
Hudson. A volte è un po 'buggy, e alcuni dei plugin più interessanti in realtà non funzionano, ma con un piccolo manipolo è piuttosto utilizzabile.
Probabilmente userò Pulse, ma se hai bisogno di costruire su piattaforme multiple è > $ 5k, che è un po 'troppo.
CruiseControl.NET per l'integrazione continua. Funziona piuttosto bene, anche se con l'enorme numero di progetti di build che abbiamo creato in CruiseControl, l'app per desktop CCTray è orribilmente non reattiva, anche con lunghi intervalli di aggiornamento.
NAnt è per gli script di build che vengono eseguiti nei progetti CruiseControl. Per script di compilazione più complessi, abbiamo esteso NAnt con attività C # NAnt personalizzate, il che è molto bello: scrivere codice in C # è molto più piacevole della creazione di script NAnt.
Siamo un negozio Microsoft e in teoria passeremo a Microsoft Team Build 2010 una volta migrato il nostro ambiente Team Foundation Server al 2010.
Nota che dovresti essere in grado di creare la tua applicazione dalla riga di comando indipendentemente dal fatto che tu abbia o meno un motore CI in esecuzione.
Questo significa che tutto il motore CI sta sistemando le tue invocazioni di build e puoi scegliere il motore che si adatta meglio alle tue particolari esigenze.
Mi piace soprattutto Hudson perché "si sente" bello, ma so che se tutto fallisce, posso passare a un altro senza troppi sforzi. Se è così, probabilmente dovrei prima indagare su quello fatto da Atlassian, dal momento che mi piace il "sentire" degli altri programmi che fanno.
Si noti che l'intercambiabilità implica che non importa in che lingua sono scritti. Credo che Java sia stato scelto per molti motori perché le numerose piattaforme supportate, combinate con i numerosi blocchi facilmente disponibili. Hai bisogno di un server web: prendine uno. Sono necessari molti thread simultanei: basta usarli. Hai bisogno di estensibilità, inserisci un barattolo.
Prima di aver mai sentito il termine "integrazione continua" (questo era nel 2002 o 2003), ho scritto uno script di compilazione serale collegato a cvs, ho preso una copia pulita del progetto principale e dei cinque sottoprogetti più piccoli, costruito tutti i jar tramite ant e poi costruito e ridistribuito un file WAR tramite un secondo script ant che utilizzava le attività di tomcat ant.
È stato trasmesso via cron alle 19:00 e inviato email con un gruppo di file di output allegati. Lo abbiamo utilizzato per tutti i 7 mesi del progetto e è rimasto in uso per i successivi 20 mesi di manutenzione e miglioramenti.
Ha funzionato bene ma preferisce ancora hudson su script di bash, cron e ant.
Leggi altre domande sui tag development-process c# builds java