Quale framework di integrazione continua usi e perché? [chiuso]

Esistono diversi framework di integrazione continua (CI) e mi chiedo quale sia il più popolare. Quali framework hai usato 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, le cose che si integrano in esso o forse il suo solo marketing?

Sembra che l'integrazione continua sia usata più nei mondi Java e .net che non ruby ​​o python. Perchè è questo?

Hudson o Jenkins (quest'ultimo è un fork del primo). Motivo: è semplice (semplice da installare e da utilizzare) e ha una grande flessibilità. I plugin aggiungono quasi tutte le funzionalità che mi vengono in mente.

Alcuni anni fa ho usato Damagecontrol . Era anche semplice da usare, ma non aveva i plugin. Ma l'autore decise che avrebbe rinunciato alla soluzione semplice e iniziò lo sviluppo di una nuova versione, che consisteva in diversi server che comunicavano tra loro (che diavolo?). Non ha funzionato bene e il progetto è stato abbandonato. Ero alla ricerca da un po 'di tempo, ma né cruisecontrol (troppo complicato) né continuum mi hanno davvero conquistato. Fino a Hudson, ha funzionato fin dal primo momento per me.

Uso TeamCity al lavoro ea casa. Ha un ottimo supporto per una varietà di runner di build ed è estensibile tramite plugin.

Non avere a che fare con pile di XML per la configurazione è un grande vantaggio nei miei libri e la versione gratuita è sufficiente per le mie esigenze domestiche.

Un problema che ho riscontrato con TeamCity ha a che fare con il tentativo di ottenere automaticamente la versione degli assembly .NET. Ho dovuto impostare una soluzione relativamente complicata, ma una volta che è stato a posto, ha funzionato come un fascino.

Personalmente, ho sempre usato CruiseControl e CruiseControl.Net. La ragione di ciò ha a che fare con l'economia. Sono ragionevolmente stabili e una volta impostati, c'è davvero poco da fare per mantenerlo. La comunità di utenti è generalmente molto utile e può essere estesa alle tue esigenze.

Detto questo, ci sono un paio di offerte commerciali 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 davvero non ho ancora avuto occasione.

Gli strumenti CI hanno un ruolo più importante da svolgere con le lingue compilate rispetto alle lingue interpretate, ma ciò non significa che lo strumento CI sia sprecato in lingue interpretate. Quando hai diversi progetti che dipendono l'uno dall'altro e vuoi assicurarti che una modifica non rompa accidentalmente le sue dipendenze, gli strumenti di CI sono inestimabili.

Esistono tre classi generali di problemi che gli strumenti CI possono aiutarti a rilevare:

1. Errori di compilazione: se la firma di una classe cambia in modo tale da spezzare le dipendenze, è meglio conoscerla prima delle ore trascorse di un deliverable.
2. Errori logici: se il comportamento di una classe cambia in modo da interrompere le dipendenze, è meglio conoscerlo in anticipo. Questo deve essere verificato da una sorta di test automatizzato, più comunemente test unitari.
3. Test di accettazione: se si dispone di una suite automatizzata di test da eseguire sul prodotto finito, è consigliabile eseguirli spesso.

Le lingue interpretate non vengono compilate, quindi non ci sono errori di compilazione da rilevare. Tuttavia, gli altri due problemi sono abbastanza comuni che gli strumenti CI sono utili per i progetti in Ruby / Python / Perl / ecc.

La parola chiave sia negli errori logici che nei punti di collaudo è il test "automatizzato". Se non disponi di una serie di test che una macchina può eseguire, allora manchi davvero i maggiori vantaggi degli strumenti CI. Le suite automatizzate possono essere costruite con il tempo, in modo da poter iniziare in piccolo.

modificare

Vedi questo bel grafico per i confronti di funzionalità di un gran numero di strumenti CI (molti dei quali non sapevo):

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix

Team Foundation Server

Solido CI, stretta integrazione con Visual Studio e Git come controllo della versione . Ho visto server CI più flessibili, come Hudson, ma la stretta integrazione di TFS con altri prodotti rende l'esperienza così semplice 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é io non sono l'ingegnere edile e colui che è l'ingegnere edile li ha sistemati in questo modo!

Non ho problemi con il modo in cui le mie build sono configurate o i reclami su entrambi i prodotti. Vi sto riferendo come sono le cose qui, in modo pratico e spero che apprezziate questa prospettiva!

AGGIORNAMENTO: Da quando ho pubblicato la risposta, Hudson è stato biforcuto ed è diventato Jenkins . La raccomandazione di cui sopra si applica a Jenkins.

Pulse . Fondamentalmente funziona solo, che per un ingegnere impegnato è un grosso problema. Hanno anche un supporto tecnico davvero eccellente. Il motivo principale per cui mi piace così tanto è che abbiamo oltre 250 progetti e li gestisce senza problemi; Non posso dire lo stesso per Hudson.

Il nostro team lavora principalmente in Python, C ++ e Java. Usiamo Buildbot per CI. Inizialmente abbiamo iniziato con esso perché si integra con Trac e perché sembrava semplice e diretto. Credo che sia il framework CI preferito nel mondo Python.

Hudson. A volte è un po 'difettoso e alcuni dei plug-in più interessanti in realtà non funzionano, ma con un po' di mano è abbastanza utilizzabile.

Probabilmente userei Pulse invece, ma se hai bisogno di costruire su più piattaforme è> $ 5k, che è un po 'troppo.

CruiseControl.NET per l'integrazione continua. Funziona abbastanza bene, anche se con il gran numero di progetti di build che abbiamo impostato in CruiseControl, l'app desktop tray CCTray è orribilmente non reattiva, anche con lunghi intervalli di aggiornamento.

NAnt è per gli script di build eseguiti nei progetti CruiseControl. Per script di compilazione più complessi, abbiamo esteso NAnt con attività personalizzate NA # NAnt, il che è molto bello: scrivere codice in C # è molto più divertente che creare script NAnt.

Siamo un negozio Microsoft e teoricamente passeremo al Team Build 2010 di Microsoft 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 un motore CI in esecuzione o meno.

Ciò significa che tutto il motore CI non fa altro che sistemare le tue invocazioni di build e puoi scegliere il motore più adatto alle tue esigenze particolari.

PErsonally: mi piace Hudson principalmente perché "sembra" bello, ma so che se tutto fallisce, posso passare a un altro senza troppi sforzi. In tal caso, probabilmente prima analizzerei quello realizzato da Atlassian, poiché mi piace la "sensazione" degli altri programmi che realizzano.

Si noti che l'intercambiabilità implica che non importa in quale lingua sono scritti. Credo che Java sia stato scelto per molti motori perché le molte piattaforme supportate, combinate con i numerosi blocchi predefiniti facilmente disponibili. Hai bisogno di un server web: prendine uno. Hai bisogno di molti thread simultanei: basta usarli. Hai bisogno di estensibilità - lascia cadere un barattolo.

Prima di aver mai sentito il termine "integrazione continua" (risale al 2002 o al 2003) ho scritto uno script notturno di build che si collegava ai cv, ho preso una copia pulita del progetto principale e dei cinque sottoprogetti più piccoli, ho costruito tutti i i barattoli tramite formica quindi creavano e ridistribuivano un file WAR tramite un secondo script di formica che utilizzava le attività formica tomcat.

Funzionava via cron alle 19:00 e inviava e-mail con un mucchio di file di output allegati. Lo abbiamo usato per tutti i 7 mesi del progetto ed è rimasto in uso per i successivi 20 mesi di manutenzione e miglioramenti.

Ha funzionato bene, ma preferisce ancora Hudson rispetto a script bash, cron e formica.