Hudson ou Teamcity pour une continuous integration?

Team City est de loin le meilleur serveur CI. Sa fonction phare est l’intégration étroite aux IDE (IntelliJ, Eclipse et VisualStudio). Il peut vous montrer, par exemple, si un fichier que vous modifiez dans l’EDI est obsolète, qui l’a modifié et ce qu’il a modifié. Vous pouvez valider depuis l’EDI vers le serveur CI, exécuter la comile et les tests sur la grid de génération, puis le serveur CI va valider si la génération réussit. Vous pouvez cliquer sur créer des rapports dans l’application Web CI et ouvrir 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.

+1 pour Hudson.

Hudson est un projet très actif, a une large communauté d’utilisateurs et une liste de diffusion des utilisateurs actifs, est vraiment facile à utiliser, facile à utiliser, a été utilisée sur des projets énormes (JBoss, JAX-WS, etc.) et a donc prouvé son succès, offre des fonctionnalités très intéressantes. fonctionnalités (par exemple, masortingce de compilation, clustering de build, etc.), est open source, a beaucoup de plugins …

Et si le support 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 de Hudson) a quitté Sun / Oracle et a lancé sa propre entreprise pour amener Hudson à la prochaine étape . En d’autres termes, ce n’est pas une menace pour Hudson. Et si vous êtes à la recherche d’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 haute qualité de Hudson avec un ensemble prédéfini de plug-ins et un commercial).

Mise à jour: Pour illustrer la taille de leur base d’utilisateurs respective, voici une comparaison des tendances de travail pour plusieurs outils CI sur Indeed (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 les suivantes: – La communauté dynamic d’Hudson, mieux que le soutien. – L’énorme quantité de plugins pour chaque type de tâches. – L’open source. – Hudson est gratuit, TeamCity est uniquement gratuit 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 construction et de l’accéder à son IDE. Qu’un seul est “bout à bout”. Il y a aussi un soutien pour le GIT, etc. Regardez-le sérieusement. La version professionnelle est gratuite.

Le plus gros 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 à diagnostiquer les problèmes et à revenir 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 magasin (lorsque vous enregistrez du code, il est déployé sur le site en direct!) Et que vous devez vous battre avec Hudson nous coûte trop cher.

Nous cherchons activement à migrer vers TeamCity uniquement à cause du coût des bogues d’Hudson.

J’aimais beaucoup Teamcity, mais dans l’environnement où je travaille, le temps qu’il faudrait pour obtenir un bon de commande pour Teamcity par le biais de différentes couches de la direction aurait probablement dépassé le temps requirejs pour migrer tout vers Hudson.

J’ai déjà utilisé et installé TeamCity et Jenkins (alias le nouveau Hudson) et, bien que je sois d’accord pour dire que TeamCity est beaucoup plus facile à installer, il est gratuit pour les équipes de 10 utilisateurs ou moins. Les deux systèmes sont très faciles à configurer et disposent d’un système de plug-ins bien pris en charge. La fonction phare de TeamCity est le workflow de pré-checkin où vous pouvez tester le code avant de le vérifier dans le contrôle de code source et la finesse de Jenkins est qu’il est totalement gratuit même si vous développez au-delà des 10 utilisateurs et agents de compilation.

Je commence 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, donc je ne peux rien en dire, mais j’aime bien travailler avec Hudson jusqu’ici.

Il y a beaucoup de plugins pour hudson et le site hudson vous donne beaucoup de conseils pour écrire votre propre ( http://wiki.hudson-ci.org/display/HUDSON/Extend+Hudson ).

J’ai recommandé aux clients de considérer Bamboo. La raison étant que (ok, en lisant 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. Un certain nombre de clients ont également HP Quality Center et il existe également des plugins pour JIRA. J’aime aussi le fait que JIRA, Bamboo et GreenHopper proviennent tous d’Atlassian.