Hudson o Teamcity per l'integrazione continua? [chiuso]

100

Siamo un negozio Java alla ricerca di uno strumento CI da utilizzare. Sia Hudson che Teamcity sembrano essere liberi ma Teamcity sembra lucido e con più supporto.

Mi chiedevo perché si dovrebbe ancora usare Hudson e se qualcuno potesse fornire argomenti a favore / contro entrambi?

— pdeva
fonte

Si può essere interessati alle risposte qui: stackoverflow.com/questions/1200721/...

— ire_and_curses

Metterei CruiseControl nel mix, se non lo hai già considerato. Non posso commentare da un punto di vista java, avendo usato la versione .NET ma mi piace.

— AdaTheDev

3

@ire_and_curses nessuna delle risposte nel post fornisce un buon argomento per uno strumento rispetto all'altro

— pdeva

4

-1 per Cruise Control - MODO troppi file di configurazione che devono essere impostati manualmente "proprio così".

— Bevan

3

Per quanto posso vedere, l'esistenza di TeamCity gratuito rende CruiseControl defunto. Non vedo alcun motivo per utilizzare CruiseControl su TeamCity. E molte ragioni per il contrario.

— Niall Connaughton

113

Team City è di gran lunga il miglior server CI in circolazione. La sua caratteristica killer per me è la stretta integrazione con gli IDE (IntelliJ, Eclipse e VisualStudio). Può mostrarti, ad esempio, quando un file che stai modificando nell'IDE diventa obsoleto, chi lo ha modificato e cosa hanno cambiato. È possibile eseguire il commit dall'IDE al server CI, eseguire la comile e i test sulla griglia di compilazione, quindi il server CI eseguirà il commit se la compilazione ha esito positivo. È possibile fare clic su build report nell'app Web CI e aprirà i file appropriati nell'IDE.

Ci sono plugin disponibili (ne ho scritto uno: http://team-piazza.googlecode.com ), ma non molti.

— Nat
fonte

9

Esecuzione remota / commit pre-testato sono caratteristiche molto utili di TeamCity. In generale il TC può essere più conveniente se le tue build non sono veloci, perché in TeamCity ottieni un feedback continuo su ciò che accade nella tua build (quanti test sono stati superati, falliti, in quale fase si trova la build e così via). Anche le notifiche TC sono più sofisticate. Puoi configurare regole diverse per diversi tipi di build e per un'ampia gamma di notificatori (email, Jabber, vassoio di Windows).

— Pavel Sher

6

@Pavel: non conosco TeamCity così come Hudson, quindi non contesterò l'inizio del tuo commento. Ma, per quanto riguarda le notifiche, affermare che TC è più sofisticato è puro FUD a mio parere non così modesto. Tutti i canali di notifica menzionati sono disponibili su Hudson (puoi anche aggiungere Twitter). In realtà, scommetto che Hudson ha molti più plug-in di TC (controlla wiki.hudson-ci.org/display/HUDSON/Plugins ) e sono sicuro che TC abbia più limitazioni di Hudson.

— Pascal Thivent

3

Sono d'accordo sui canali (Hudson ha molti plugin), ma non sono d'accordo sulle regole. In TeamCity puoi iscriverti alle build con le tue modifiche, puoi scegliere di essere avvisato quando la build inizia a fallire (ad esempio quando il primo test inizia a fallire). Puoi chiedere di essere avvisato sulla prima build fallita dopo la sequenza di successo + sul primo successo dopo i fallimenti. E queste opzioni sono disponibili per tutti i canali di notifica. Uno di questi canali è il notificatore IDE: quando qualcosa va storto riceverai una notifica direttamente nel tuo IDE. Per quanto ricordo, le regole di notifica di Hudson erano molto più semplici.

— Pavel Sher,

2

Pavel - non voglio una partita di imbracatura qui, ma per impostazione predefinita Hudson ti invierà un'email solo se hai contribuito alla build fallita. Puoi anche iscriverti per essere informato di ogni build fallita, se lo desideri. Ci sono anche più opzioni nel plug-in email-ext. Non devi approvarlo, ma non travisarlo.

— Jim T,

4

Un rapido google ti mostrerà che ci sono plug-in per controllare i conigli nabaztag e altri simpatici dispositivi di Team City. Oppure potresti usare il plug-in a cui ho collegato nella mia risposta . Il vantaggio di una stretta integrazione IDE è un feedback molto più rapido e mirato sul codice su cui stai lavorando mentre lavori con esso. Non è necessario attendere una notifica, passare al browser tge, leggere il report, tornare all'IDE e aprire il file appropriato. Il riquadro dell'editor cambia mentre lavori per mostrare come gli altri membri del team hanno influenzato il codice.

— Nat

58

+1 per Hudson.

Hudson è un progetto molto attivo, ha un'ampia comunità di utenti e una mailing list di utenti attivi, è davvero facile da iniziare, è facile da usare, è stata utilizzata su progetti enormi, molto vasti (JBoss, JAX-WS, ecc.) E quindi ha comprovati record di successo, offre offerte avanzate molto belle caratteristiche (es. build matrix, build clustering, ecc.), è open source, ha molti plugin ...

~~E se il supporto è davvero una cosa importante, è possibile ottenere supporto commerciale da Sun . Ma FWIW, non ho mai affrontato alcun problema di blocco con Hudson.~~

Aggiornamento: come forse saprai, Kohsuke Kawaguchi (il creatore di Hudson) ha lasciato Sun / Oracle e ha fondato la sua compagnia per portare Hudson alla fase successiva . In altre parole, questa non è una minaccia per Hudson. E se stai cercando supporto, puoi ottenere una versione certificata di Hudson CI Server come parte di un piano di abbonamento (questa versione certificata raggruppa una versione di alta qualità di Hudson con un set predefinito di plugin più alcuni commerciali).

Aggiornamento: per illustrare la dimensione della rispettiva base di utenti, ecco un confronto delle tendenze di lavoro per diversi strumenti di CI su Indeed (query in tempo reale):

Ingegnere di costruzione Hudson, Ingegnere di costruzione CruiseControl, Ingegnere di costruzione Bamboo, Ingegnere di costruzione TeamCity Tendenze lavorative

Questo ovviamente non è un indicatore tecnico.

— Pascal Thivent
fonte

88

Forse TeamCity è così facile da usare, da non richiedere a nessuno specificatamente addetto di configurarlo?

— Henrik

3

@Henrik: L'interpretazione del grafico sopra è a tua discrezione. Ma sì, forse TeamCity è magico.

— Pascal Thivent

16

Se assumi un ingegnere di build a tempo pieno per eseguire la tua integrazione continua, ora hai due problemi: 1) Il tuo CI è difficile da lavorare, quindi i tuoi sviluppatori faranno fatica e la conoscenza risiederà nella testa di questa persona, 2) Stai pagando qualcuno per fare un lavoro che non dovrebbe essere necessario fare!

— Niall Connaughton

15

Se stavo selezionando un server CI, sceglierei quello che aveva le MINIME opportunità di lavoro per un ingegnere dedicato che lo amministrasse. È uno strumento per sviluppatori e gli sviluppatori dovrebbero essere in grado di gestirlo da soli. Se non possono, hai bisogno di uno strumento diverso o di sviluppatori diversi.

— Nat

Il grafico delle tendenze del lavoro non implica affatto +1 per hudson ...

— Sharique Abdullah

17

Abbiamo iniziato con Hudson per un paio di progetti Flex, poi siamo migrati a TeamCity, quando gli sviluppatori .NET si sono uniti ai nostri sforzi CI. Ora abbiamo sostituito di nuovo il server TeamCity, tornando a Hudson. Le ragioni principali sono: - La vivace comunità di Hudson, meglio del supporto. - L'enorme quantità di plugin per ogni tipo di attività. - L'open source. - Hudson è gratuito, TeamCity è gratuito solo per 10 progetti.

modifica: TeamCity è ora gratuito per 20 progetti.

— Subotnik
fonte

2

Le 10 restrizioni del progetto sono cadute, l'unico limite ora è di 20 configurazioni di build. Per progetti di piccole e medie dimensioni forse è sufficiente.

— frassini

4

Per curiosità, quali funzionalità erano disponibili tramite i plugin Jenkins mancavano nel mondo TeamCity?

— Behrang Saeedzadeh

14

TeamCity è fantastico perché consente a ogni sviluppatore di avere il proprio profilo di build e collegarsi ad esso dal proprio IDE. Che un solitario stia prendendo a calci. C'è anche il supporto per GIT, ecc. Dai un'occhiata seriamente. La versione professionale è gratuita.

— Beaumont Muni
fonte

5

GIT è supportato anche da Jenkins / Hudson

— CJBrew,

14

Il più grande argomento contro Hudson è che ogni versione introduce nuovi bug.

I rilasci sono molto frequenti, quindi devi aggiornare frequentemente per non rimanere indietro. Ciò significa che è necessario dedicare molto tempo alla diagnosi dei problemi e al ripristino delle versioni precedenti di Hudson. (A volte un rollback non è nemmeno possibile!)

Stiamo introducendo la distribuzione continua nel nostro negozio (quando si archivia il codice, viene distribuito sul sito live!) E dover lottare con Hudson ci sta costando troppo.

Stiamo attivamente cercando di migrare a TeamCity esclusivamente a causa del costo dei bug di Hudson.

— jdtangney
fonte

8

Solo perché è disponibile un aggiornamento non significa che devi eseguire l'aggiornamento. Preferirei che uscissero più che meno spesso. È la mia scelta quando aggiornare e di certo non lo faccio ogni settimana. Inoltre, i manutentori sono molto conservatori riguardo alla retrocompatibilità. I plugin generalmente non richiedono l'ultima versione di Hudson per funzionare. In effetti, 130 plugin disponibili ora sono costruiti contro versioni di Hudson che hanno più di un anno. Se sei ancora preoccupato, c'è un plug-in di rollback automatico in lavorazione ..;)

— Christopher Orr

1

Dalla mia esperienza, il problema è più con i plugin che con lo stesso Hudson, anche se questo non fa una grande differenza dal punto di vista dell'utente. Ma nulla ti obbliga ad aggiornare a meno che tu non stia affrontando un bug particolare o non puoi vivere senza una nuova funzionalità. Semplicemente non seguiamo ogni versione e non usiamo la versione definitiva per noi non è affatto un problema: "Se non è rotto, non aggiustarlo" .

— Pascal Thivent

2

Quando il committer principale invia un messaggio dicendo che un grave difetto di sicurezza è stato risolto, questo è un motivo per l'aggiornamento. Il mio punto è ancora valido: Hudson è semplicemente troppo instabile, anche senza plug-in aggiuntivi installati.

— jdtangney

1

Posso dire che dopo un anno e mezzo di utilizzo di Hudson / Jenkins su un progetto, sebbene sia un ottimo strumento - anche noi abbiamo sperimentato una qualità incoerente tra le versioni - e abbiamo aggiornato solo quando ne avevamo assolutamente bisogno. Abbiamo trovato soluzioni, incluso il frequente backup della configurazione. Non vedo l'ora di provare TeamCity nel mio ultimo progetto.

— JaysonRaymond

4

Perché gli aggiornamenti e la stabilità dovrebbero essere fattori opposti? Non indica solo una mancanza di qualità?

— Niall Connaughton

6

Mi è piaciuto molto Teamcity, ma nell'ambiente in cui ci sto lavorando, il tempo necessario per ottenere un ordine di acquisto per Teamcity attraverso i livelli di gestione avrebbe probabilmente superato il tempo necessario per migrare tutto su Hudson.

— sal
fonte

10

TeamCity professional è gratuito.

— Pavel Sher

6

@Pavel, abbiamo più di 20 utenti e molte più build di così.

— sal

22

@sal mi stupisce sempre come le aziende possano essere così preoccupate per un paio di migliaia di dollari per gli strumenti dei loro team di sviluppo e preferirebbero che sprechino centinaia di ore combinate che non avrebbero avuto con lo strumento.

— Chris Marisic

5

@Chris E se iniziassero con uno strumento gratuito open source perché solo per vedere come funziona qualcosa e 2 anni dopo si rendono conto che funziona ancora senza problemi? Suggeriresti comunque di spendere un paio di migliaia di dollari per passare a uno strumento commerciale che molto probabilmente fa esattamente la stessa cosa?

— stefanB

1

@stefan Se usi uno strumento da 2 anni e soddisfa le tue esigenze a meno che non ci sia featureX di cui hai bisogno da un altro strumento, perché dovresti passare a un altro strumento gratuito oa pagamento?

— Chris Marisic

2

Ho già utilizzato e configurato TeamCity e Jenkins (alias il nuovo Hudson) e anche se sarei d'accordo sul fatto che TeamCity è molto facile da configurare, è gratuito solo per team di 10 utenti o meno. Entrambi i sistemi sono molto facili da configurare e dispongono di un sistema di plugin ben supportato. La caratteristica killer in TeamCity è il flusso di lavoro pre-check-in in cui è possibile testare il codice prima di registrarlo nel controllo del codice sorgente e la gentilezza di Jenkins è che è completamente gratuito anche se si supera i 10 utenti e si creano agenti.

— runxc1 Bret Ferrier
fonte

Inoltre mi piace la visualizzazione grafica di Jenkins, ed è quello che mi manca in Teamcity. Inoltre sono d'accordo con il tuo commento!

— Danny Gloudemans

Se sei d'accordo con un commento

— votalo

1

Sto appena iniziando ad abituarmi a Hudson pronto a sperimentare e vedere come si adatterà al nostro ambiente attuale. Non ho assolutamente esperienza con Teamcity, quindi non posso commentare in merito, ma mi piace lavorare con Hudson finora.

Ci sono molti plugin per hudson e il sito hudson ti dà molti consigli per scrivere il tuo ( http://wiki.hudson-ci.org/display/HUDSON/Extend+Hudson ).

— Jake Worrell
fonte

1

Ho consigliato ai clienti di considerare Bamboo. Il motivo è che (ok, dalla lettura delle schede tecniche!) Ha una funzionalità molto simile impostata a TeamCity. Tuttavia, il vantaggio principale è l'integrazione molto stretta con JIRA, che è piuttosto popolare come sistema di tracciamento delle funzionalità / bug. La suite completa è JIRA, Greenhopper, Bamboo ed Eclipse. Alcuni clienti hanno anche un centro qualità HP e ci sono plugin che si aggiungono anche a JIRA. Mi piace anche il fatto che JIRA, Bamboo e GreenHopper provengano tutti da Atlassian.

— drekka
fonte

Dopo un uso estensivo di TeamCity, Jenkins sembra molto bare-metal. Sì, i plugin ti consentono di fare qualsiasi cosa, una volta installati. TeamCity ha un set di funzionalità mature che ti fa andare fuori dagli schemi. Tuttavia, a livello di consegna continua, entrambi lasciano una pipeline di staging adeguata non implementata. QuickBuild è un prodotto ancora più ricco di funzionalità che merita attenzione, è payware.

— bbaassssiiee

Avendo visto Bamboo in azione su un sito client, non ne sono più molto entusiasta. Ci sono alcune aree intorno allo scripting e al trasferimento di informazioni tra build che fatica a fare. I risultati tendono ad essere gli sviluppatori che inseriscono ogni sorta di cose nell'area delle variabili globali del CI che semplicemente non dovrebbero esserci.

— drekka