Hudson ou Teamcity pour une intégration continue?
Team City est de loin le meilleur serveur CI. Pour moi, sa principale caractéristique est l'intégration étroite avec les IDE (IntelliJ, Eclipse et VisualStudio). Il peut vous montrer, par exemple, lorsqu'un fichier que vous modifiez dans le IDE devient obsolète, qui l'a changé et ce qu'il a changé. Vous pouvez valider à partir du IDE sur le serveur CI, exécutez le comile et les tests sur la grille de génération, puis le serveur CI se validera si la génération réussit. Vous pouvez cliquer sur les rapports de génération dans l'application Web CI et il ouvrira le fichiers dans l'IDE.
Il existe des plugins disponibles (j'en ai écrit un: http://team-piazza.googlecode.com ), mais pas beaucoup.
+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 très facile à démarrer, facile à utiliser, a été utilisé sur des projets énormes, très énormes (JBoss, JAX-WS, etc. ) et a ainsi fait ses preuves, offre des fonctionnalités avancées très sympas (par exemple matrice de build, clustering de build, etc.), est open source, a beaucoup de plugins ...
Et si le support est vraiment une chose importante, vous pouvez obtenir 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 de Hudson) a quitté Sun/Oracle et a commencé 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 un 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 et certains commercial).
Mise à jour: Pour illustrer la taille de leur base d'utilisateurs respectifs, voici une comparaison des tendances d'emploi pour plusieurs outils CI sur En effet (requête en direct):
Ce n'est bien sûr pas un indicateur technique.
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é dynamique de Hudson, 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 maintenant gratuit pour 20 projets.
TeamCity est génial car il permet à chaque développeur d'avoir son propre profil de build et de s'y connecter depuis son IDE. Qu'un seul est "coup de pied". Il existe également un support pour GIT etc. Jetez-y un œil sérieux. La version professionnelle est gratuite.
Le plus gros argument contre Hudson est que chaque version introduit de nouveaux bugs.
Les versions sont très fréquentes, vous devez donc mettre à niveau fréquemment afin de ne pas prendre de retard. Cela signifie que vous devez consacrer beaucoup de temps au diagnostic des problèmes et au retour aux versions précédentes d'Hudson. (Parfois, un retour en arrière 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 envisageons activement de migrer vers TeamCity uniquement en raison du coût des bogues d'Hudson.
J'ai vraiment aimé Teamcity mais dans l'environnement dans lequel je travaille, le temps qu'il faudrait pour obtenir un bon de commande pour Teamcity à travers les couches de gestion aurait probablement dépassé le temps nécessaire pour tout migrer vers Hudson.
J'ai utilisé et configuré TeamCity et Jenkins (alias le nouveau Hudson) avant et même si je conviens que TeamCity est beaucoup plus simple à configurer, il n'est gratuit que pour des équipes de 10 utilisateurs ou moins. Les deux systèmes sont très faciles à configurer et disposent d'un système de plug-in bien pris en charge. La fonctionnalité de tueur 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 source et la beauté de Jenkins est qu'il est complètement gratuit même si vous vous développez au-delà des 10 utilisateurs et des agents de construction.
Je commence tout juste à m'habituer à Hudson prêt à expérimenter et à voir comment il s'intégrera dans notre environnement actuel. Je n'ai absolument aucune expérience avec Teamcity, je ne peux donc pas en parler, 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 ).
J'ai recommandé aux clients de considérer Bamboo. La raison en est que (ok, en lisant les fiches techniques!), Il a une fonctionnalité 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. Un certain nombre de clients ont également HP Quality Center et il existe également des plugins qui les joignent à JIRA. J'aime aussi le fait que JIRA, Bamboo et GreenHopper viennent tous d'Atlassian.