Expérience de construction à distance de serveur de construction continue (cc.net, hudson, bambou, etc.)?

Nous utilisons actuellement une fois le serveur cc.net pour notre processus de construction, qui construit à la fois .net (en utilisant msbuild & nant) et java (en utilisant maven et ant).

CC.net surveille le contrôle des sources et déclenche une génération à distance exécutée sur un serveur distinct. CC.net rassemble ensuite les résultats.

Lorsque nous exécutons la génération à distance, elle généralement:

• exécute nunit ou junit ou similaire en utilisant des données simulées
• exécute éventuellement un script DB pour créer une nouvelle instance de base de données ou restaurer une base de données à partir d'une position connue.
• fonctionne au sélénium ou similaire pour tester l'interface utilisateur
• exécute emma ou ncover pour la couverture du code
• construit le système pour différents environnements de déploiement (test, acceptation, production)

Nous pouvons avoir plusieurs builds en cours d'exécution à la fois, certains .net et certains java (de différentes équipes de projet).

Il faut beaucoup de temps pour faire fonctionner les builds distants lorsque nous mettons en place un nouveau projet et nous pensons qu'il doit y avoir quelque chose de mieux adapté aux builds distants que cc.net.

Quelqu'un a-t-il une expérience des constructions à distance avec des systèmes d'intégration continue?
Je ne veux pas vraiment de listes de fonctionnalités de serveurs CI, j'apprécierais davantage d'entendre comment vous les avez utilisés dans un environnement multilingue et multi-serveurs.

Hudson (Mise à jour: dans le monde d'aujourd'hui, j'utiliserais Jenkins, un fork d'Hudson.)

J'ai utilisé hudson dans des environnements d'entreprise Java et .NET pour des projets à haute visibilité (vous avez probablement visité certains des sites). Hudson est solide depuis le début, mais la meilleure partie est qu'il y a beaucoup de plugins pour faire à peu près tout ce que vous voulez. Hudson est hautement configurable, possède une grande communauté et est vraiment facile à installer dans un environnement de cluster si vous avez besoin de plusieurs versions à la fois. C'est mon serveur CI préféré de tous ceux que j'ai utilisés (CC.NET, Hudson et TFS).

De plus, vous pouvez utiliser le plugin ChuckNorris pour qu'il vous donne le pouce vers le haut ou vers le bas.

Nous étions confrontés à cette question il y a quelque temps et avons décidé d'aller avec TeamCity . Nous n'avons examiné que Hudson, CC et TeamCity. Le choix a été facile à faire - TeamCity a fini par être notre serveur de build. Veuillez noter que je ne suis pas un pro dans ce domaine et que c'était ma première expérience avec des serveurs de build à cette époque.

Hudson - Je ne savais pas quoi faire ni où lire à ce sujet. Et même si je pouvais comprendre quelque chose là-bas, ce n'était pas une option - trop de travail. J'ai décidé de jeter un œil à CC.

Régulateur de vitesse - identique à Hudson, mais d'une manière légèrement différente. Rien ne peut y être compris sans un manuel et une tonne d'aide de Google. Je viens de jeter un œil à TC.

TeamCity - TeamCity se sentait comme le paradis après les deux premiers. C'est le plus utilisable de ces trois. Installez, accédez au panneau d'administration, configurez un projet (montrez où se trouve le SVN, pointez pour créer des fichiers, spécifiez la couverture / les tests unitaires, etc.) et commencez à en profiter. Et même si je ne peux pas dire que je n'ai rien recherché sur Google, 95% du processus de configuration a été très simple et clair. Je recommande fortement cet outil. Allez y jeter un œil. Cela vous fera économiser beaucoup de nerfs et de temps :)

Je dois également noter que TC n'est pas gratuit. Bien qu'ils aient une édition gratuite qui peut être utilisée dans des projets commerciaux avec certaines limitations (max build configs 20) - jetez un œil sur leur page de tarification.

PS J'ai l'impression de travailler pour TC, mais ce n'est vraiment pas le cas :)

Nous utilisons CC.NET 1.4.

Nous essayons de passer à 1.6 ... quel cauchemar.

C'est puissant ... mais UNIQUEMENT si vous l'utilisez correctement et comprenez comment tout s'emboîte. C'est beaucoup demander à toute l'équipe. Nous avons des «buildmasters» qui ont accès au serveur et peuvent changer les configurations. Même ainsi, il y a beaucoup de googler en ce qui concerne ccnet et toute l'entreprise est devenue un énorme gâchis.

Personnellement, je veux passer à TeamCity.

Je vous recommande de vous éloigner de ccnet.

bonne question. Nous essayons actuellement de trouver quel outil nous convient le mieux. Je ne pourrai donc vous raconter qu'une petite expérience. Mais nous serions très intéressés par le système CI que vous avez choisi maintenant et pour quelles raisons. Veuillez donc nous tenir informés.

Je suis très impressionné par le niveau élevé de votre CI. Je dois admettre que nous avons moins d'exigences car nous n'exécutons pas encore de tests d'interface utilisateur et ne créons pas d'instances de base de données ou similaires, nous utilisons simplement des simulations pour nos tests unitaires.

Passons maintenant à nos expériences jusqu'à maintenant:

Pour les projets Java, nous utilisons Bamboo qui fonctionne très bien avec JUnit et Emma. Et il n'y a pas tant d'efforts pour monter un nouveau projet.

Pour les projets .NET, nous recherchons toujours la meilleure solution

• Cruise Control: nous n'avons pas pu le faire fonctionner en raison de problèmes de connexion à notre référentiel

• TFS:

  a) Il y a quelques étapes de configuration nécessaires pour pouvoir exécuter la première génération.

  b) Il y a des écueils où vous devez surmonter les droits d'accès. Il existe de nombreux rôles que vous pouvez définir et vous devez savoir exactement quels droits ont votre processus de construction et lesquels ont votre compte de connexion personnel. Mais si vous avez suffisamment de temps pour gérer, vous pouvez définir chaque granularité particulière dont vous avez besoin.

  c) En ce qui concerne les bibliothèques référencées, il y a aussi des choses à gérer si vous voulez partager des bibliothèques pour de nombreux projets et ne voulez pas les gérer à chaque projet

  d) L'exécution du test NUnit n'est pas aussi facile que nous le pensions. C'est simple si vous utilisez l'exécution de test fournie par Visual Studio, mais ce n'est pas NUnit

  e) Nous n'avons pas encore essayé d'exécuter NCover (tout d'abord :-))

• Hudson: outil suivant, nous allons essayer. Semble avoir un plugin vraiment bon et facile pour .NET, je vous ferai savoir comment cela a fonctionné

• Bamboo: Première prédiction que nous avons obtenue: "Trop Java spécifique". Mais peut-être que nous essaierons néanmoins le plugin .NET, je vous le ferai savoir

J'espère que nous pourrons poursuivre cette discussion et échanger nos expériences.

Andy