Hudson ou Teamcity pour une intégration continue? [fermé]
100
Nous sommes une boutique Java à la recherche d'un outil CI à utiliser. Les deux Hudson et Teamcity semblent être libre , mais semble Teamcity Slicker et avec plus de soutien.
Je me demandais pourquoi on utiliserait encore Hudson et si quelqu'un pouvait fournir un argument pour / contre l'un ou l'autre?
Je jetterais CruiseControl dans le mélange - si vous ne l'avez pas déjà envisagé. Je ne peux pas commenter un point de vue java, ayant utilisé la version .NET mais j'aime ça.
AdaTheDev
3
@ire_and_curses aucune des réponses dans le message ne donne un bon argument pour l'un ou l'autre outil par rapport à l'autre
pdeva
4
-1 pour le régulateur de vitesse - BEAUCOUP trop de fichiers de configuration qui doivent être configurés manuellement "juste comme ça".
Bevan
3
Pour autant que je puisse voir, l'existence de TeamCity gratuit fait de CruiseControl un défunt. Je ne vois aucune raison d'utiliser CruiseControl sur TeamCity. Et de nombreuses raisons expliquent le contraire.
Niall Connaughton
Réponses:
113
Team City est de loin le meilleur serveur CI. Sa fonctionnalité qui tue pour moi est l'intégration étroite avec les IDE (IntelliJ, Eclipse et VisualStudio). Il peut vous montrer, par exemple, quand un fichier que vous éditez dans l'EDI devient obsolète, qui l'a changé et ce qu'il a changé. Vous pouvez valider à partir de l'EDI sur le serveur CI, exécuter la compilation et les tests sur la grille de génération, puis le serveur CI validera si la génération réussit. Vous pouvez cliquer sur créer des rapports dans l'application Web CI et cela ouvrira les fichiers appropriés dans l'EDI.
L'exécution à distance / la validation pré-testée sont des fonctionnalités très utiles de TeamCity. En général, TC peut être plus pratique si vos builds ne sont pas rapides, car dans TeamCity, vous obtenez des commentaires continus sur ce qui se passe dans votre build (combien de tests ont réussi, échoué, à quel stade la build est et ainsi de suite). Les notifications TC sont également plus sophistiquées. Vous pouvez configurer différentes règles pour différents types de builds et pour un large éventail de notificateurs (e-mail, Jabber, Windows).
Pavel Sher
6
@Pavel: Je ne connais pas TeamCity ni Hudson, donc je ne contesterai pas le début de votre commentaire. Mais, en ce qui concerne les notifications, prétendre que TC est plus sophistiqué est du pur FUD à mon avis pas si humble. Tous les canaux de notification mentionnés sont disponibles sur Hudson (vous pouvez même ajouter Twitter). En fait, je parie que Hudson a beaucoup plus de plugins que TC (consultez wiki.hudson-ci.org/display/HUDSON/Plugins ) et je suis sûr que TC a plus de limitations que Hudson.
Pascal Thivent
3
Je suis d'accord sur les canaux (Hudson a beaucoup de plugins), mais je ne suis pas d'accord sur les règles. Dans TeamCity, vous pouvez vous abonner aux builds avec vos modifications, vous pouvez choisir d'être averti lorsque la build commence à échouer (par exemple, lorsque le premier test commence à échouer). Vous pouvez demander à être notifié du premier échec de construction après la séquence de succès + du premier succès après des échecs. Et ces options sont disponibles pour tous les canaux de notification. L'un de ces canaux est le notificateur IDE: en cas de problème, vous recevrez une notification directement dans votre IDE. Si je me souviens bien, les règles de notification Hudson étaient beaucoup plus simples.
Pavel Sher
2
Pavel - ne voulant pas de match élancé ici, mais par défaut, Hudson ne vous enverra un e-mail que si vous avez contribué à l'échec de la construction. Vous pouvez également vous abonner pour être informé de chaque build échoué si vous le souhaitez. Il y a aussi plus d'options dans le plug-in email-ext. Vous n'êtes pas obligé de l'approuver, mais ne le déformez pas.
Jim T
4
Un rapide google vous montrera qu'il existe des plug-ins pour contrôler les lapins nabaztag et d'autres appareils mignons de Team City. Ou vous pouvez utiliser le plug-in auquel j'ai lié dans ma réponse . L'avantage d'une intégration IDE étroite est une rétroaction beaucoup plus rapide et plus ciblée sur le code sur lequel vous travaillez lorsque vous travaillez avec lui. Vous n'avez pas besoin d'attendre une notification, de basculer vers le navigateur tge, de lire le rapport, de revenir à l'EDI et d'ouvrir le fichier approprié. Le volet de l'éditeur change au fur et à mesure que vous travaillez pour montrer comment les autres membres de l'équipe ont affecté le code.
Nat
58
+1 pour Hudson.
Hudson est un projet très actif, a une large communauté d'utilisateurs et une liste de diffusion d'utilisateurs actifs, est vraiment facile à démarrer, est facile à utiliser, a été utilisé sur d'énormes, très énormes projets (JBoss, JAX-WS, etc.) et a donc fait ses preuves de succès, offre de très belles avancées fonctionnalités (par exemple, matrice de construction, clustering de construction, etc.), est open source, a beaucoup de plugins ...
Et si le soutien est vraiment une chose importante, vous pouvez obtenir un support commercial de Sun . Mais FWIW, je n'ai jamais rencontré de problème de blocage avec Hudson.
Mise à jour: Comme vous le savez peut-être, Kohsuke Kawaguchi (le créateur d'Hudson) a quitté Sun / Oracle et a créé sa propre entreprise pour amener Hudson à l'étape suivante . En d'autres termes, ce n'est pas une menace pour Hudson. Et si vous recherchez une assistance, vous pouvez obtenir une version certifiée de Hudson CI Server dans le cadre d'un plan d'abonnement (cette version certifiée regroupe une version de haute qualité de Hudson avec un ensemble prédéfini de plugins plus une version commerciale).
Mise à jour: pour illustrer la taille de leur base d'utilisateurs respective, voici une comparaison des tendances de l'emploi pour plusieurs outils de CI sur Indeed (requête en direct):
Ce n'est bien entendu pas un indicateur technique.
Peut-être TeamCity est-il si facile à utiliser, qu'il ne nécessite aucune personne spécifiquement employée pour le configurer?
Henrik
3
@Henrik: L'interprétation du graphique ci-dessus est à votre discrétion. Mais oui, peut-être que TeamCity est magique.
Pascal Thivent
16
Si vous embauchez un ingénieur de construction à plein temps pour gérer votre intégration continue, vous avez maintenant deux problèmes: 1) Votre CI est difficile à travailler, donc vos développeurs auront du mal avec cela et les connaissances resteront dans la tête de cette personne, 2) Vous payez quelqu'un pour faire un travail qui ne devrait pas être fait!
Niall Connaughton
15
Si je sélectionnais un serveur CI, je choisirais celui qui avait le MOINS d'offres d'emploi pour un ingénieur dédié pour l'administrer. C'est un outil de développement et les développeurs devraient être capables de le gérer eux-mêmes. S'ils ne le peuvent pas, vous avez besoin d'un outil différent ou de développeurs différents.
Nat
Le graphique des tendances de l'emploi n'implique pas du tout +1 pour
Hudson
17
Nous avons commencé avec Hudson pour quelques projets Flex, puis nous avons migré vers TeamCity, lorsque les développeurs .NET ont rejoint nos efforts CI. Maintenant, nous avons à nouveau remplacé le serveur TeamCity, de retour à Hudson. Les principales raisons sont: - La communauté Hudson dynamique, mieux que le soutien. - L'énorme quantité de plugins pour chaque type de tâches. - L'open source. - Hudson est gratuit, TeamCity n'est gratuit que pour 10 projets.
edit: TeamCity est désormais gratuit pour 20 projets.
Les 10 restrictions de projet sont tombées, la seule limite est maintenant de 20 configurations de construction. Pour les projets de petite à moyenne taille peut-être suffisant.
frêne
4
Par curiosité, quelles fonctionnalités disponibles via les plugins Jenkins manquaient dans le monde TeamCity?
Behrang Saeedzadeh
14
TeamCity est génial car il permet à chaque développeur d'avoir son propre profil de build et de s'y connecter à partir de son IDE. Qu'un solitaire est «butt-kickin». Il existe également un support pour GIT, etc. Jetez-y un coup d'œil. La version professionnelle est gratuite.
Le principal argument contre Hudson est que chaque version introduit de nouveaux bogues.
Les versions sont très fréquentes, vous devez donc mettre à jour fréquemment pour ne pas prendre de retard. Cela signifie que vous devez consacrer beaucoup de temps au diagnostic des problèmes et à la restauration des versions précédentes d'Hudson. (Parfois, une restauration n'est même pas possible!)
Nous introduisons le déploiement continu dans notre boutique (lorsque vous enregistrez le code, il est déployé sur le site en direct!) Et avoir à lutter avec Hudson nous coûte trop cher.
Nous cherchons activement à migrer vers TeamCity uniquement en raison du coût des bogues d'Hudson.
Ce n'est pas parce qu'une mise à jour est disponible que vous devez mettre à niveau. Je préfère qu'ils sortent plus que moins souvent. C'est mon choix de mettre à niveau et je ne le fais certainement pas toutes les semaines. De plus, les responsables sont très prudents sur la compatibilité ascendante. Les plugins n'ont généralement pas besoin de la dernière version d'Hudson pour fonctionner. En fait, 130 plugins disponibles actuellement sont construits avec des versions d'Hudson datant de plus d'un an. Si vous êtes toujours inquiet, un plugin de restauration automatique est en préparation ..;)
Christopher Orr
1
D'après mon expérience, le problème concerne plus les plugins que Hudson lui-même, bien que cela ne fasse pas une énorme différence du point de vue de l'utilisateur. Mais rien ne vous oblige à mettre à niveau à moins que vous ne soyez confronté à un bogue particulier ou que vous ne puissiez pas vivre sans une nouvelle fonctionnalité. Nous ne suivons simplement pas chaque version et ne pas utiliser la version ultime n'est pas du tout un problème pour nous: "Si ce n'est pas cassé, ne le réparez pas" .
Pascal Thivent
2
Lorsque le committer principal envoie un message indiquant qu'une faille de sécurité majeure a été corrigée, c'est une raison de mettre à jour. Mon point est toujours valable: Hudson est tout simplement trop floconneux - même sans plugins supplémentaires installés.
jdtangney
1
Je peux dire qu'après un an et demi d'utilisation de Hudson / Jenkins sur un projet, bien que ce soit un excellent outil - nous avons également connu une qualité incohérente entre les versions - et nous n'avons mis à niveau que lorsque nous en avions absolument besoin. Nous avons trouvé des solutions, y compris une sauvegarde fréquente de la configuration. J'ai hâte d'essayer TeamCity sur mon dernier projet.
JaysonRaymond
4
Pourquoi les mises à jour et la stabilité devraient-elles être des facteurs opposés? Cela ne signifie-t-il pas simplement un manque de qualité?
Niall Connaughton
6
J'ai beaucoup aimé Teamcity mais dans l'environnement dans lequel je travaille, le temps qu'il faudrait pour obtenir un bon de commande pour Teamcity via les couches de gestion aurait probablement dépassé le temps nécessaire pour tout migrer vers Hudson.
@Pavel, nous avons plus de 20 utilisateurs et bien plus de builds que cela.
sal
22
@sal, je suis toujours étonné de voir à quel point les entreprises peuvent être si préoccupées par les outils de leurs équipes de développement et préféreraient qu'elles gaspillent des centaines d'heures combinées qu'elles n'auraient pas eues avec l'outil.
Chris Marisic
5
@Chris Et s'ils commençaient avec un outil gratuit open source parce que juste pour voir comment quelque chose fonctionne et 2 ans plus tard se rendre compte que cela fonctionne toujours sans aucun problème? Souhaitez-vous toujours dépenser quelques milliers de dollars pour passer à un outil commercial qui fait très probablement exactement la même chose?
stefanB
1
@stefan Si vous avez utilisé un outil pendant 2 ans et qu'il répond à vos besoins à moins qu'il y ait featureX dont vous avez besoin d'un autre outil, pourquoi passeriez-vous à un autre outil gratuit ou payant?
Chris Marisic
2
J'ai déjà utilisé et configuré TeamCity et Jenkins (alias le nouveau Hudson) et même si je conviens que TeamCity est beaucoup plus facile à configurer, il n'est gratuit que pour les équipes de 10 utilisateurs ou moins. Les deux systèmes sont très faciles à configurer et disposent d'un système de plugins bien pris en charge. La fonctionnalité qui tue dans TeamCity est le flux de travail de pré-enregistrement où vous pouvez tester le code avant de le vérifier dans le contrôle de code source et la gentillesse de Jenkins est qu'il est complètement gratuit même si vous dépassez les 10 utilisateurs et créez des agents.
J'aime aussi la vue graphique de Jenkins, et c'est ce qui me manque dans Teamcity. De plus je suis d'accord avec votre commentaire!
Danny Gloudemans
Si vous êtes d'accord avec un commentaire, votez pour :)
runxc1 Bret Ferrier
1
Je commence tout juste à m'habituer à Hudson, prêt à expérimenter et à voir comment cela s'intégrera dans notre environnement actuel. Je n'ai absolument aucune expérience avec Teamcity, je ne peux donc pas faire de commentaire à ce sujet, mais j'aime travailler avec hudson jusqu'à présent.
J'ai recommandé aux clients d'envisager Bamboo. La raison en est que (ok, après avoir lu les fiches techniques!), Il a un ensemble de fonctionnalités très similaire à TeamCity. Cependant, le principal avantage est une intégration très étroite avec JIRA qui est très populaire en tant que système de suivi des fonctionnalités / bogues. La suite complète étant JIRA, Greenhopper, Bamboo et Eclipse. De nombreux clients ont également le centre de qualité HP et il existe des plugins qui le rejoignent également dans JIRA. J'aime aussi le fait que JIRA, Bamboo et GreenHopper viennent tous d'Atlassian.
Après une utilisation intensive de TeamCity, Jenkins a l'air très nu. Oui, les plugins vous permettent de faire n'importe quoi, une fois que vous les avez installés. TeamCity a un ensemble de fonctionnalités mature qui vous permet de sortir de la boîte. Pourtant, au niveau de la livraison continue, les deux laissent un pipeline d'étape approprié non mis en œuvre. QuickBuild est un produit encore plus riche en fonctionnalités qui mérite l'attention, c'est un payware.
bbaassssiiee
Ayant maintenant vu Bamboo en action sur un site client, je n'y suis plus très intéressé. Il y a des domaines autour de la création de scripts et du transfert d'informations entre les builds qu'il a du mal à faire. Les résultats ont tendance à être que les développeurs mettent toutes sortes de choses dans la zone de variable globale du CI qui ne devraient tout simplement pas y être.
Réponses:
Team City est de loin le meilleur serveur CI. Sa fonctionnalité qui tue pour moi est l'intégration étroite avec les IDE (IntelliJ, Eclipse et VisualStudio). Il peut vous montrer, par exemple, quand un fichier que vous éditez dans l'EDI devient obsolète, qui l'a changé et ce qu'il a changé. Vous pouvez valider à partir de l'EDI sur le serveur CI, exécuter la compilation et les tests sur la grille de génération, puis le serveur CI validera si la génération réussit. Vous pouvez cliquer sur créer des rapports dans l'application Web CI et cela ouvrira les fichiers appropriés dans l'EDI.
Il y a des plugins disponibles (j'en ai écrit un: http://team-piazza.googlecode.com ), mais pas beaucoup.
la source
+1 pour Hudson.
Hudson est un projet très actif, a une large communauté d'utilisateurs et une liste de diffusion d'utilisateurs actifs, est vraiment facile à démarrer, est facile à utiliser, a été utilisé sur d'énormes, très énormes projets (JBoss, JAX-WS, etc.) et a donc fait ses preuves de succès, offre de très belles avancées fonctionnalités (par exemple, matrice de construction, clustering de construction, etc.), est open source, a beaucoup de plugins ...
Et si le soutien est vraiment une chose importante, vous pouvez obtenir un support commercial de Sun . Mais FWIW, je n'ai jamais rencontré de problème de blocage avec Hudson.Mise à jour: Comme vous le savez peut-être, Kohsuke Kawaguchi (le créateur d'Hudson) a quitté Sun / Oracle et a créé sa propre entreprise pour amener Hudson à l'étape suivante . En d'autres termes, ce n'est pas une menace pour Hudson. Et si vous recherchez une assistance, vous pouvez obtenir une version certifiée de Hudson CI Server dans le cadre d'un plan d'abonnement (cette version certifiée regroupe une version de haute qualité de Hudson avec un ensemble prédéfini de plugins plus une version commerciale).
Mise à jour: pour illustrer la taille de leur base d'utilisateurs respective, voici une comparaison des tendances de l'emploi pour plusieurs outils de CI sur Indeed (requête en direct):
Ce n'est bien entendu pas un indicateur technique.
la source
Nous avons commencé avec Hudson pour quelques projets Flex, puis nous avons migré vers TeamCity, lorsque les développeurs .NET ont rejoint nos efforts CI. Maintenant, nous avons à nouveau remplacé le serveur TeamCity, de retour à Hudson. Les principales raisons sont: - La communauté Hudson dynamique, mieux que le soutien. - L'énorme quantité de plugins pour chaque type de tâches. - L'open source. - Hudson est gratuit, TeamCity n'est gratuit que pour 10 projets.
edit: TeamCity est désormais gratuit pour 20 projets.
la source
TeamCity est génial car il permet à chaque développeur d'avoir son propre profil de build et de s'y connecter à partir de son IDE. Qu'un solitaire est «butt-kickin». Il existe également un support pour GIT, etc. Jetez-y un coup d'œil. La version professionnelle est gratuite.
la source
Le principal argument contre Hudson est que chaque version introduit de nouveaux bogues.
Les versions sont très fréquentes, vous devez donc mettre à jour fréquemment pour ne pas prendre de retard. Cela signifie que vous devez consacrer beaucoup de temps au diagnostic des problèmes et à la restauration des versions précédentes d'Hudson. (Parfois, une restauration n'est même pas possible!)
Nous introduisons le déploiement continu dans notre boutique (lorsque vous enregistrez le code, il est déployé sur le site en direct!) Et avoir à lutter avec Hudson nous coûte trop cher.
Nous cherchons activement à migrer vers TeamCity uniquement en raison du coût des bogues d'Hudson.
la source
J'ai beaucoup aimé Teamcity mais dans l'environnement dans lequel je travaille, le temps qu'il faudrait pour obtenir un bon de commande pour Teamcity via les couches de gestion aurait probablement dépassé le temps nécessaire pour tout migrer vers Hudson.
la source
J'ai déjà utilisé et configuré TeamCity et Jenkins (alias le nouveau Hudson) et même si je conviens que TeamCity est beaucoup plus facile à configurer, il n'est gratuit que pour les équipes de 10 utilisateurs ou moins. Les deux systèmes sont très faciles à configurer et disposent d'un système de plugins bien pris en charge. La fonctionnalité qui tue dans TeamCity est le flux de travail de pré-enregistrement où vous pouvez tester le code avant de le vérifier dans le contrôle de code source et la gentillesse de Jenkins est qu'il est complètement gratuit même si vous dépassez les 10 utilisateurs et créez des agents.
la source
Je commence tout juste à m'habituer à Hudson, prêt à expérimenter et à voir comment cela s'intégrera dans notre environnement actuel. Je n'ai absolument aucune expérience avec Teamcity, je ne peux donc pas faire de commentaire à ce sujet, mais j'aime travailler avec hudson jusqu'à présent.
Il existe de nombreux plugins pour hudson et le site hudson vous donne de nombreux conseils pour écrire le vôtre ( http://wiki.hudson-ci.org/display/HUDSON/Extend+Hudson ).
la source
J'ai recommandé aux clients d'envisager Bamboo. La raison en est que (ok, après avoir lu les fiches techniques!), Il a un ensemble de fonctionnalités très similaire à TeamCity. Cependant, le principal avantage est une intégration très étroite avec JIRA qui est très populaire en tant que système de suivi des fonctionnalités / bogues. La suite complète étant JIRA, Greenhopper, Bamboo et Eclipse. De nombreux clients ont également le centre de qualité HP et il existe des plugins qui le rejoignent également dans JIRA. J'aime aussi le fait que JIRA, Bamboo et GreenHopper viennent tous d'Atlassian.
la source