CruiseControl vs TeamCity pour une continuous integration?

J’ai travaillé sur et avec des outils d’continuous integration 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 à mettre en place et fournit encore 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 utile. Pour les projets .NET simples, vous pouvez simplement indiquer à 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 du contrôle de la source). Nous avons également utilisé des scripts MSBuild compliqués avec lui et avons fait un chaînage de build. Je suis également passé par deux mises à niveau de TeamCity et elles étaient indolores.

CruiseControl.NET fonctionne également bien. Il est plus compliqué à mettre en place, mais son histoire est plus longue, il est donc facile de trouver des solutions sur le Web. Puisque CruiseControl.NET est open source, vous avez également la possibilité d’append ou de modifier ce que vous voulez. J’avais utilisé CruiseControl.NET depuis sa sortie et j’ai écrit certains des premiers codes pour cc.tray (heureusement réécrits par quelqu’un qui connaissait mieux).

Cruise, de ThoughtWorks, semble également très bien, mais je ne vois pas de raison convaincante pour que je change. Si je commençais un nouveau projet, j’essayerais peut-être, mais TeamCity a fait un excellent travail en simplifiant les choses simples tout en rendant le complexe assez indolore.

Edit: Nous venons de mettre à jour TeamCity 5.0 il y a quelques semaines et ce fut une autre mise à jour indolore. Il nous a permis de tirer parti des capacités de couverture de code améliorées et de la prise en charge de GIT. Nous utilisons également la version personnelle et les fonctionnalités de validation pré-testées depuis longtemps. Je pensais juste que je devais mettre à jour la réponse pour indiquer que TeamCity continue à s’améliorer et rest 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 les mains peut être difficile, mais ça va.

Mais

Après le Kona: Continuous Integration and Better Unit Testing (le premier 1/3 sur TeamCity), je vérifierai aussi TeamCity. J’adore le tableau de bord de test 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 y a aussi une vidéo CC.NET sur le net.

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

J’utilise TeamCity actuellement sur un projet et j’en suis généralement satisfait, mais bon nombre des graphiques générés 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é unique: 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 génération réussit (par exemple, les compilations et tous les tests réussis).

Étant donné que vous pourriez faire fonctionner TeamCity et Hudson en quelques heures, il pourrait être utile de les récupérer et de les exécuter côte à côte, ainsi que d’autres (comme CruiseControl) auxquels vous pouvez penser. Si vous ne pouvez pas supporter un serveur CI rapidement pour effectuer une comparaison côte à côte, vous disposez au moins d’un sharepoint données pour faciliter l’installation et / ou la configuration.

Je les ai utilisés avec succès sur différents projets. Du sharepoint vue de la configuration et de l’administration, Team City est beaucoup plus facile à gérer. Vous n’avez pas à bidouiller 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 plutôt que CC jusqu’à ce que Team City coûte $$.

J’ai utilisé à la fois 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 exécutés sur des systèmes d’exploitation hétérogènes, ce qui a causé certains problèmes de configuration initiaux. Cependant, le support par e-mail était absolument parfait pour tout configurer. J’ai reçu des réponses à mes questions idiotes en quelques minutes.

L’interface est intuitive et réactive, ainsi que riche en fonctionnalités. Le produit est 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 rafraîchir la page.

Je pense que nous utilisons à peu près toutes les fonctionnalités avancées du produit et que nous n’avons trouvé aucun bogue à ce jour. Intégration Ndepend, scripts NAnt nesteds, étiquetage de version Perforce, vous l’appelez, nous le faisons.

Je recommande fortement TeamCity à tous ceux qui recherchent un serveur d’continuous integration, ou n’importe quel serveur de compilation.

Sans vouloir vous lancer d’autres outils 🙂

Hudson est une excellente alternative à l’open source, j’ai utilisé CC et CC.net, et j’avoue que je pense qu’ils sont des outils fantastiques. Je pense à passer à hudson car il est beaucoup plus facile à configurer et à entretenir.

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

Assurez-vous que le système que vous choisissez dépend du nombre de projets dont vous aurez besoin pour le 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 beaucoup de bibliothèques statiques C ++ dans lesquelles je compose des applications. Chaque bibliothèque dépend d’autres bibliothèques et les applications intègrent un ensemble de bibliothèques et de build. Chaque lib dispose d’une suite de tests. Chaque application dispose d’une suite de tests. Je construis pour 5 compilateurs et des 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. Le fonctionnement des déclencheurs de projet (ils utilisent remoting 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 effectuent une recherche séquentielle. la recherche du projet qui vous intéresse…) signifie qu’ils ne sont pas bien adaptés. 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 génération.

Bien sûr, c’est open source, donc vous pouvez le réparer … Et je suis sûr que c’est bon pour un petit nombre de projets non interdépendants.

Pour plus de détails sur les problèmes que j’ai rencontrés et sur 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 éditer des fichiers de configuration dans le bloc-notes notablement 🙂

Il a été autour de temps alors son bien soutenu et vous pouvez normalement trouver quelqu’un qui a fait ce que vous voulez faire avant. L’interface Web est également .net, ce qui était un avantage pour nous, car nous sums une boutique Microsoft.

Je n’ai pas utilisé TeamCity mais j’en ai entendu pas mal de recommandations et ça a l’air bien.

J’ai eu une expérience dans la mise en place et le fonctionnement de CruiseControl (version Java) sous Linux lors de ma précédente entreprise. Comme la plupart des gens le suggèrent, ce n’est pas la chose la plus sortingviale à configurer. Vous devez comprendre son framework pour arriver à la configuration réalisable / gérable. Cependant, une fois que vous avez réussi, je pense que CruiseControl est assez flexible pour vous permettre de faire différentes choses pour différents scénarios.

En 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 fonctionnalité de pré-test soit intéressante.

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

Une troisième option à envisager: la croisière de Thoughtworks. Il est construit sur CruiseControl, mais offre beaucoup plus de fonctionnalités, une configuration plus simple, etc., etc. Non gratuit (ou open source).

http://studios.thoughtworks.com/cruise-continuous-integration

J’utilise Teamcity depuis 1 an et demi et je profite d’une expérience formidable. J’ai intégré un certain nombre de projets .Net et Java et utilisé des outils tels que 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 cauchemardesque avec d’autres outils CI.
Récemment mis à niveau vers Teamcity 8.0.6, qui était indolore. Teamcity fournit également une API REST très utile pour certains scénarios. Si vous utilisez Powershell pour automatiser des builds, un certain nombre de scripts d’intégration Psake / Teamcity sont disponibles sur GitHub.