CruiseControl [.Net] vs TeamCity pour une intégration continue?

Je voudrais vous demander quel environnement de construction automatisé vous considérez le mieux, basé sur l'expérience pratique. Je prévois de faire du développement .Net et Java, alors j'aimerais avoir un outil qui prend en charge ces deux plates-formes.

J'ai lu et découvert CruiseControl.NET , utilisé dans le développement de stackoverflow, et TeamCity avec son support pour les agents de build sur différentes plates-formes OS et basés sur différents langages de programmation. Donc, si vous avez une expérience pratique sur les deux, lequel préférez-vous et pourquoi?

Actuellement, je m'intéresse surtout à la facilité d'utilisation et de gestion de l'outil, encore moins au fait que CC est open source, et TC est soumis à une licence à un moment donné lorsque vous avez beaucoup de projets à exécuter (parce que, je besoin pour un petit nombre de projets).

De plus, s'il existe un autre outil qui répond à ce qui est mentionné ci-dessus 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 des 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 que moi avec TeamCity. Il est très simple à mettre en place et fournit toujours beaucoup de puissance. La page de 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 TeamCity est également très précieuse. Pour les projets .NET simples, vous pouvez simplement indiquer à TeamCity où se trouve la solution et quels assemblys ont des tests et c'est tout ce dont il a besoin (autre que l'emplacement du contrôle de code source). Nous avons également utilisé des scripts MSBuild compliqués avec lui et effectué le chaînage de construction. J'ai également subi deux mises à niveau TeamCity et elles étaient indolores.

CruiseControl.NET fonctionne également bien. Il est plus délicat à mettre en place mais son historique est plus long, il est donc facile de trouver des solutions sur le Web. Puisque 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 j'ai écrit une partie du code initial pour cc.tray (heureusement réécrit par quelqu'un qui savait mieux).

Cruise, de ThoughtWorks, a également l'air plutôt bien, mais je ne vois pas de raison impérieuse pour moi de changer. Si je commençais un nouveau projet, je pourrais peut-être essayer, mais TeamCity a fait un excellent travail en simplifiant 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 sans douleur. Cela nous permet de profiter des capacités améliorées de couverture de code et de la prise en charge de GIT. Nous utilisons également maintenant les fonctionnalités de build personnel et de validation pré-testées qui existent depuis un certain temps. J'ai juste pensé que je devrais mettre à jour la réponse pour indiquer que TeamCity continue de s'améliorer et qu'il 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 à la main peut être pénible, mais ça va.

Mais .

Après le screencast Kona: Intégration continue et meilleurs tests unitaires (le premier 1/3 sur TeamCity), je vais également vérifier 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.

ps: J'espère qu'il existe également une vidéo CC.NET précieuse sur le net.

Mon serveur CI préféré est de loin Hudson. Facile à configurer et à entretenir, de nombreux graphiques sympas pour montrer les tendances aux développeurs et aux non-développeurs, et gratuits.

J'utilise TeamCity actuellement sur un projet et j'en suis généralement satisfait, mais la plupart des 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é qui tue: 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, les compilations et tous les tests réussissent).

Étant donné que vous pouvez faire fonctionner TeamCity et Hudson en quelques heures, il peut être intéressant de les saisir et de les exécuter côte à côte, avec tous les autres (tels que CruiseControl) auxquels vous pouvez penser. Si vous ne pouvez pas faire fonctionner un serveur CI rapidement pour effectuer une comparaison côte à côte, vous disposez au moins d'un point de données pour faciliter l'installation et / ou la configuration.

Je les ai utilisés tous les deux 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 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 plutôt que CC jusqu'à ce que vous arriviez au point que Team City coûte $$.

J'ai utilisé à la fois CC.net et TeamCity. Je suis chargé de mettre en place et d'installer TeamCity pour mon organisation (5 développeurs). Notre organisation utilise des pratiques et des outils inhabituels (du moins, pour les organisations de notre taille), tels que Perforce pour le contrôle de code source et plusieurs agents de construction s'exécutant sur des systèmes d'exploitation hétérogènes, ce qui a causé des problèmes de configuration initiale. Cependant, le support par e-mail était absolument de premier ordre 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 trouvé aucun bogue jusqu'à présent. Intégration Ndepend, scripts NAnt imbriqués, étiquetage de version Perforce, vous l'appelez, nous le faisons.

Je recommande vivement TeamCity à tous ceux qui recherchent un serveur d'intégration continue, ou tout autre 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. Je pense passer à Hudson car il semble beaucoup plus facile à configurer et à entretenir.

https://hudson.dev.java.net/

Assurez-vous que le système que vous choisissez s'adapte au nombre de projets dont vous aurez besoin pour gérer ...

J'utilise CruiseControl.Net mais je ne le recommanderais pas pour construire beaucoup de projets ... J'ai un arrangement (peut-être un peu é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 intègrent 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 ce dont vous avez besoin et que 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 communication à distance 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 extraient tous les projets de ce serveur et recherchent la liste de manière séquentielle rechercher le 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 prend la majeure partie du processeur pour votre machine de construction.

Bien sûr, c'est open source, donc vous pouvez le réparer ... 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 quelques 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 qui demande un peu de patience. Vous éditerez beaucoup les fichiers de configuration dans le bloc-notes :)

Il existe depuis un certain temps, il est donc bien pris en charge et vous pouvez normalement trouver quelqu'un qui a déjà fait ce que vous voulez faire. 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 de la configuration et de l'exécution de CruiseControl (version Java) sous 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 trouver 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érents types de choses pour s'adapter à différents scénarios.

Outre la documentation de CruiseControl, sa page wiki contient également des informations utiles.

Je n'ai pas d'expérience directe avec TeamCity. Bien que sa fonction de validation de pré-test semble assez intéressante.

L'autre outil CC que vous pourriez lui donner est Bamboo d'Atlassian. C'est beaucoup plus facile à configurer et l'interface est plus agréable. Cependant, ce n'est pas aussi flexible que ce que propose CruiseControl.

Une troisième option que vous voudrez peut-être envisager: la croisière de Thoughtworks. Il est construit sur CruiseControl, mais offre beaucoup plus de fonctionnalités, une configuration plus facile, etc, etc. Non 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 également réussi à faire fonctionner CI pour certains projets SQL, ce qui était un peu un 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