buildbot vs hudson/jenkins pour le C++ intégration continue

Question

Je suis actuellement à l'aide jenkins/hudson pour l'intégration continue d'un grand la plupart du temps C++ du projet. Nous avons des projets distincts pour le tronc et chaque branche. Aussi, il y a quelques projets connexes pour le code Java, mais le programme d'installation pour ceux qui sont assez basiques (on peut le faire plus tard). Les projets C++ effectuer les opérations suivantes:

• Construit tout avec des options pour savoir si reconfigurer, faire un nettoyage de construire ou d'utiliser une nouvelle caisse
• Éventuellement construit et exécute tous les tests
• Éventuellement l'exécute tous les tests à l'aide de Valgrind est memcheck
• Fonctionne cppcheck
• Génère la documentation doxygen
• Publie des rapports: les tests unitaires, valgrind, cppcheck, les avertissements du compilateur, SLOC, ouvrir des tâches, et la couverture de code (à l'aide de gcov, gcovr, et la couverture du plugin)
• Déploie code de la nuit ou à la demande sur un environnement de test et un dépôt de paquets

Tout est configurable pour automatique construit et en option à la demande s'appuie. Dessous, il y a un script bash qui contrôle une grande partie de ce qui, plus loin, cela dépend de notre système de construction, qui utilise automake et autoconf personnalisés scripts bash.

Nous avons commencé à utiliser Hudson (à l'époque) parce que c'est ce que le Java gars et nous voulions juste les nightly builds. Depuis lors, nous avons ajouté beaucoup plus et continuer à ajouter de plus. À certains égards, Hudson est formidable, mais ce n'est certainement pas l'idéal.

J'ai regardé d'autres solutions, et le seul qui ressemble à cela pourrait être un remplacement est buildbot. Serait buildbot être mieux de cette situation? Est l'investissement en vaut la peine puisque nous sommes déjà à l'aide d'Hudson? Pourquoi?

EDIT: Quelqu'un a demandé pourquoi je n'ai pas trouvé d'Hudson/Jenkins pour être idéal. La réponse courte est que tout peut être amélioré. Je suis tout simplement demandais si Jenkins est actuellement la meilleure solution pour mon cas d'utilisation ou s'il y a quelque chose de mieux (buildbot?) ce serait plus facile à maintenir dans le long terme, même si de nouvelles exigences.

Answer 1

Les deux sont des projets open source, mais vous n'avez pas besoin de changer de buildbot code pour "étendre", il est en fait assez facile d'importer vos propres paquets dans sa configuration dans laquelle vous pouvez sous-classe de la plupart des caractéristiques avec vos propres ajouts. Exemples: votre propre compilation ou le code de test, certains d'analyse des produits/des erreurs à la prochaine étapes, votre propre mise en forme de l'alerte e-mails, etc. il y a beaucoup de possibilités.

En général, je dirais que buildbot est le plus "généraliste" automatique à créer des outils. Jenkins, cependant, pourrait être la meilleure liés à l'exécution des tests, en particulier pour l'analyse et la présentation des résultats à nice moyens (résultats, des détails, des graphiques.. quelques clics), des choses qui buildbot ne font pas "out-of-the-box". Je suis en train de penser à la fois pour avoir plus sexy de tester les pages de résultats.. :-)

Aussi en règle générale, il ne devrait pas être difficile de créer un nouvel outil de config: si la spécification de quoi faire (configs, construit, tests), c'est trop dur de passer d'un outil à un autre, c'est un (mauvais) signe que pas assez de scripts de configuration sont déplacés vers les sources. Buildbot (ou Jenkins) ne devraient appeler des commandes simples. Si elle est simple à exécuter des tests, puis les développeurs vont faire ça bien et cela permettra d'améliorer le taux de réussite, alors que si seulement le système d'intégration continue exécute les tests, vous serez à courir après elle pour fixer le nouveau code des échecs, et perdra de sa non-régression de la valeur, juste mon 0.02€ :-)

Espère que ça vous aidera.

Answer 2

Le "résultat" d'intégration est également dans jenkins/hudson, et vous pouvez assez facilement la capture de construire des produits sans avoir à "copier ailleurs".

Pour notre exemple, les rapports de couverture et de test de l'unité de paramètres et de javadoc pour le code java est tout intégré. Pour notre code C++, les plugins sont un peu défaut, mais vous pouvez toujours obtenir la plus grande partie.

nous avons couru buildbot depuis le pré de 0.7, et sont maintenant en cours d'exécution 0,8 et sont seulement en train de voir une raison de changer, comme buildbot 0.8 oublié windows esclaves pendant une longue période de temps et le soutien a été très mauvaise.

Answer 3

Il existe de nombreuses autres solutions, en plus de Jenkins/Hudson/BuildBot:

• TeamCity par Jetbrains
• Bambou par Atlassian
• Aller par Thoughtworks
• Régulateur De Vitesse
• OpenMake Meister

Les détails au sujet de ce que vous faites ne sont pas si important, en fait, aussi longtemps que les agents (appelés nœuds) que vous le faites sur le soutien de ces tâches.

La beauté d'un serveur CI est à remarquer lors de l'accumulation de changements pour déclencher une nouvelle version (et de tester), de publier les artefacts, et de publier les résultats du test.

Lorsque vous comparez CI des outils comme ceux que nous avons mentionnés, en tenant compte d'éléments comme la facilité d'utilisation de son interface, combien il est facile de branchement (et les fonctionnalités qu'il pourrait offrir comme automatique de fusion), notifications (comme XMPP/jabber), ou un radiateur (comme de brancher un moniteur de toujours afficher l'état). Support produit est une autre chose à considérer - Jenkins soutien est seulement aussi bon que ce qui est en train de répondre aux questions de la communauté au moment où vous avez des questions.

Mon préféré est le Bambou, mais il est livré avec un droit de licence.

Answer 4

Vous devriez considérer les problèmes de performances.

Recherche dans Google et comparer ci-dessous les résultats de la requête:

• "jenkins lent" => environ 16M résultats
• "buildbot lent" => à propos de 1.39 M résultats

Mon entreprise système CI est en train de migrer de buildbot de jenkins. Jenkins page d'affichage de la vitesse de rendu est terrible. Peut-être l'optimisation des performances de jenkins est nécessaire, mais avec buildbot, ce n'est pas ma préoccupation à tous.

Ok, jenkins est rendu performance est due à la faiblesse de plugin.

Mais je pense toujours que buildbot (textuelle et n'est pas si facile), la configuration est beaucoup plus souple que jenkins.