CruiseControl [.Net] vs TeamCity pour une intégration continue?
Je voudrais vous demander quel environnement de construction automatisé vous considérez le mieux, sur la base d'une expérience pratique. Je prévois de faire du .Net et du Java, donc j'aimerais avoir un outil qui supporte ces deux plateformes.
J'ai lu et découvert CruiseControl.NET , utilisé sur le développement de stackoverflow, et TeamCity avec son support pour les agents de construction sur différentes plates-formes OS et basé sur différents langages de programmation. Donc, si vous avez une expérience pratique des deux, laquelle préférez-vous et pourquoi?
Actuellement, je suis principalement intéressé par la facilité d'utilisation et la gestion de l'outil, et encore moins par le fait que CC est open source, et TC est soumis à licence à un moment donné lorsque vous avez beaucoup de projets à exécuter (car, je besoin pour un petit nombre de projets).
De plus, s'il existe un autre outil qui répond à ce qui précède et que vous pensez qu'il vaut la peine d'être recommandé - n'hésitez pas à l'inclure dans la discussion.
J'ai travaillé sur et avec les outils d'intégration continue depuis celui qui a engendré Cruise Control (version Java). J'ai essayé presque tous à un moment donné. Je n'ai jamais été aussi heureux qu'avec TeamCity. Il est très simple à installer et fournit toujours beaucoup de puissance. La page des statistiques de construction qui montre les temps de construction, le nombre de tests unitaires, le taux de réussite, etc. est très agréable. La page d'accueil du projet de TeamCity est également très précieuse. Pour les projets .NET simples, vous pouvez simplement dire à TeamCity où se trouve la solution et quels assemblages ont des tests et c'est tout ce dont elle a besoin (autre que l'emplacement de contrôle de source). Nous avons également utilisé des scripts MSBuild compliqués avec lui et effectué le chaînage de build. J'ai également subi deux mises à niveau de TeamCity et elles ont été indolores.
CruiseControl.NET fonctionne également bien. Il est plus difficile à configurer, mais son historique est plus long, il est donc facile de trouver des solutions sur le Web. Étant donné que CruiseControl.NET est open source, vous avez également la possibilité d'ajouter ou de modifier ce que vous voulez. J'avais utilisé CruiseControl.NET depuis sa sortie et écrit une partie du premier code pour cc.tray (heureusement réécrit par quelqu'un qui connaissait mieux).
Cruise, de ThoughtWorks, semble également très bien, mais je ne vois pas de raison impérieuse pour moi de changer. Si je commençais un nouveau projet, je pourrais l'essayer, mais TeamCity a fait un excellent travail pour simplifier les choses simples tout en rendant le complexe assez indolore.
Edit: Nous venons de passer à TeamCity 5.0 il y a quelques semaines et c'était une autre mise à niveau indolore. Il nous a permis de profiter des capacités améliorées de couverture de code et du support GIT. Nous utilisons également maintenant la construction personnelle et les fonctionnalités de validation pré-testées qui existent depuis un certain temps. Je pensais juste que je devrais mettre à jour la réponse pour indiquer que TeamCity continue de s'améliorer et est toujours facile à utiliser.
J'étais/je suis un grand fan de CC.NET. Nous avons actuellement 5 projets dans CruiseControl et fonctionne très bien. Écrire des fichiers de configuration avec la main peut être pénible mais c'est correct.
Mais.
Après le Kona: intégration continue et meilleurs tests unitaires screencast (le premier 1/3 sur TeamCity), je vérifierai également TeamCity. J'adore le tableau de bord de test unitaire intégré et l'interface de configuration.
Je pense que tout le monde devrait regarder cette vidéo avant de choisir CC.NET ou TeamCity.
p.s .: J'espère qu'il y a aussi une vidéo CC.NET précieuse sur le net.
Mon serveur CI préféré est de loin Hudson. Facile à configurer et à entretenir, beaucoup de graphiques Nice pour montrer les tendances aux développeurs et non-développeurs, et gratuits.
J'utilise TeamCity actuellement sur un projet et je suis généralement satisfait de celui-ci, mais de nombreux graphiques qu'il génère ne sont pas particulièrement utiles, et il est plus compliqué à configurer que Hudson.
Cela dit, TeamCity est puissant, gratuit pour de nombreuses utilisations et possède une fonctionnalité de tueur: Remote Run. Vous pouvez "pré-valider" votre enregistrement directement depuis IDEA ou Eclipse, exécuter une ou plusieurs configurations de build sur le serveur TeamCity, et ne valider les modifications que si la build réussit (par exemple, compile et tous les tests réussissent).
Étant donné que vous pouvez mettre en marche TeamCity et Hudson en quelques heures, il pourrait être utile de les saisir et de les exécuter côte à côte, ainsi que tous les autres (tels que CruiseControl) auxquels vous pouvez penser. Si vous ne pouvez pas mettre un serveur CI en place rapidement pour effectuer une comparaison côte à côte, vous disposez au moins d'un point de données pour une installation et/ou une configuration faciles.
Je les ai tous deux utilisés avec succès sur différents projets. Du point de vue de la configuration et de l'administration, Team City est beaucoup plus facile à gérer. Vous n'avez pas à pirater avec les fichiers .config comme vous le faites avec CC et la configuration est un jeu d'enfant. Comme vous n'avez pas beaucoup de projets, je recommanderais Team City sur CC jusqu'à ce que Team City coûte $$.
J'ai utilisé CC.net et TeamCity. Je suis chargé de configurer et d'installer TeamCity pour mon organisation (5 développeurs). Notre organisation utilise des pratiques et des outils inhabituels (au moins pour les organisations de notre taille), tels que Perforce pour le contrôle des sources et plusieurs agents de génération fonctionnant sur des systèmes d'exploitation hétérogènes, ce qui a provoqué quelques maux de tête de configuration initiale. Cependant, le support par e-mail était absolument parfait pour tout configurer. J'ai reçu des réponses à mes questions stupides en quelques minutes.
L'interface est intuitive et réactive, ainsi que riche en fonctionnalités. Le produit semble très cher. La configuration est simple et l'interface Web est suffisamment intelligente pour se mettre à jour sans redémarrer les services de l'agent ou du serveur, ni même actualiser la page.
J'ai l'impression que nous utilisons à peu près toutes les fonctionnalités avancées du produit et que nous n'avons jusqu'à présent trouvé aucun bogue. Intégration Ndepend, scripts NAnt imbriqués, étiquetage de version Perforce, vous l'appelez, nous le faisons.
Je recommande fortement TeamCity à tous ceux qui recherchent un serveur d'intégration continue, ou n'importe quel serveur de build, vraiment.
Sans vouloir vous lancer des outils alternatifs :-)
Hudson est une excellente alternative open source, j'ai utilisé CC et CC.net, et j'avoue que je pense que ce sont des outils fantastiques. J'envisage de passer à Hudson car il apparaît beaucoup plus facile à configurer et à entretenir.
Assurez-vous que le système que vous décidez d'échelles au nombre de projets dont vous aurez besoin pour gérer ...
J'utilise CruiseControl.Net mais je ne le recommanderais pas pour la construction de nombreux projets ... J'ai un arrangement (peut-être légèrement étrange) où j'ai de nombreuses bibliothèques statiques C++ que je compose en applications. Chaque bibliothèque dépend d'autres bibliothèques et les applications récupèrent un ensemble de bibliothèques et se construisent. Chaque bibliothèque a une suite de tests. Chaque application dispose d'une suite de tests. Je construis pour 5 compilateurs et variantes de plates-formes (Windows).
La première chose que j'ai trouvée est que les déclencheurs de projet de CC.Net ne sont pas vraiment tout à fait ce dont vous avez besoin et le multi-déclencheur ne fonctionne pas bien avec les déclencheurs de projet. La façon dont les déclencheurs de projet fonctionnent (ils utilisent la télécommande pour se connecter au serveur sur lequel le projet est stocké (même s'il s'agit d'un projet géré par la même instance de CC.Net), puis extraire tous les projets de ce serveur et rechercher la liste séquentiellement la recherche du projet qui vous intéresse ...) signifie qu'ils ne s'adaptent pas bien. Une fois que vous avez dépassé un certain nombre de projets, vous constaterez que CC.Net utilise la majeure partie du processeur pour votre machine de génération.
Bien sûr, c'est open source, donc vous pouvez le corriger ... Et, je suis sûr que c'est bien pour un petit nombre de projets non interdépendants.
Pour plus de détails sur les problèmes que j'ai rencontrés et certains correctifs pour CC.Net, voir ici http://www.lenholgate.com/archives/cat_ccnet.html
J'ai récemment installé cc .net. C'est une excellente application mais nécessite un peu de patience. Vous allez modifier beaucoup de fichiers de configuration dans le bloc-notes :)
Il existe depuis un certain temps, donc il est bien pris en charge et vous pouvez normalement trouver quelqu'un qui a fait ce que vous voulez faire auparavant. L'interface Web est également .net, ce qui était un plus pour nous car nous sommes une boutique Microsoft.
Je n'ai pas utilisé TeamCity mais j'en ai entendu pas mal de recommandations et ça a l'air joli.
J'ai eu une expérience dans la configuration et l'exécution de CruiseControl (version Java) sur Linux au cours de mon entreprise précédente. Comme la plupart des gens le suggèrent, ce n'est pas la chose la plus triviale à configurer. Vous devez comprendre son cadre afin de proposer la configuration réalisable/gérable. Cependant, une fois que vous avez dépassé cette bosse, je pense que CruiseControl est assez flexible pour vous permettre de faire différentes sortes de choses pour s'adapter à différents scénarios.
En outre, la documentation de CruiseControl, son page wiki contient également des informations utiles.
Je n'ai pas d'expérience directe avec TeamCity. Bien que sa fonction de validation pré-test semble suffisamment intéressante.
L'autre outil CC que vous pourriez lui donner est Bamboo d'Atlassian. Il est beaucoup plus facile à configurer et l'interface est plus agréable. Cependant, il n'est pas aussi flexible que ce que propose CruiseControl.
Une troisième option que vous voudrez peut-être envisager: la croisière Thoughtworks. Il est construit sur CruiseControl, mais offre beaucoup plus de fonctionnalités, une configuration plus facile, etc., etc. Pas gratuit (ou open source).
http://studios.thoughtworks.com/cruise-continuous-integration
J'utilise Teamcity depuis 1 an et demi et j'ai une grande expérience. J'ai intégré un certain nombre de projets .Net et Java et utilisé des outils comme MSBuild, Maven etc. J'ai trouvé Teamcity assez simple à configurer et à utiliser. J'ai réussi à faire fonctionner CI pour certains projets sql ainsi qui était un peu de cauchemar qui aurait pu être pire avec d'autres outils CI.
Récemment mis à niveau vers Teamcity 8.0.6 qui était indolore. Teamcity fournit également une API REST qui est très utile pour certains scénarios. Si vous utilisez powershell pour automatiser les builds, un certain nombre de scripts d'intégration Psake/Teamcity sont disponibles sur GitHub