buildbot vs hudson / jenkins pour l'intégration continue C ++
J'utilise actuellement jenkins/hudson pour l'intégration continue d'un grand projet principalement C++. Nous avons des projets distincts pour le tronc et chaque branche. En outre, il existe des projets connexes pour le Java, mais la configuration de ceux-ci est assez basique pour le moment (nous pouvons en faire plus plus tard cependant). Les projets C++ font ce qui suit:
- Génère tout avec des options pour reconfigurer, effectuer une nouvelle génération ou utiliser une nouvelle extraction
- Génère et exécute tous les tests en option
- Exécute éventuellement tous les tests à l'aide de la vérification de mémoire de Valgrind
- Exécute cppcheck
- Génère la documentation doxygen
- Publie des rapports: tests unitaires, valgrind, cppcheck, avertissements du compilateur, SLOC, tâches ouvertes et couverture de code (à l'aide de gcov, gcovr et du plugin cobertura)
- Déploie le code tous les soirs ou à la demande dans un environnement de test et un référentiel de packages
Tout est configurable pour les builds automatiques et facultatif pour les builds à la demande. En dessous, il y a un script bash qui contrôle une grande partie de cela, qui dépend davantage de notre système de construction, qui utilise automake et autoconf avec des scripts bash personnalisés.
Nous avons commencé à utiliser Hudson (à l'époque) parce que c'était ce que les gars de Java utilisaient et nous voulions juste des versions nocturnes. Depuis lors, nous avons ajouté beaucoup plus et continuons à en ajouter. à certains égards, Hudson est génial, mais n'est certainement pas idéal.
J'ai examiné d'autres solutions et la seule qui semble pouvoir être un remplacement est buildbot. Buildbot serait-il meilleur pour cette situation? Est-ce que l'investissement en vaut la peine puisque nous utilisons déjà Hudson? Pourquoi?
EDIT : Quelqu'un a demandé pourquoi je n'avais pas trouvé Hudson/Jenkins idéal. La réponse courte est que tout peut être amélioré. Je me demande simplement si Jenkins est la meilleure solution actuelle pour mon cas d'utilisation ou s'il y a quelque chose de mieux (buildbot?) Qui serait plus facile à maintenir à long terme même si de nouvelles exigences apparaissent.
Les deux sont des projets open source, mais vous n'avez pas besoin de changer le code buildbot pour le "prolonger", il est en fait assez facile d'importer vos propres packages dans sa configuration dans laquelle vous pouvez sous-classer la plupart des fonctionnalités avec vos propres ajouts. Exemples: votre propre code de compilation ou de test, une analyse des sorties/erreurs à donner aux étapes suivantes, votre propre formatage d'e-mails d'alerte, etc., il y a beaucoup de possibilités.
En général, je dirais que buildbot est l'outil de génération automatique le plus "polyvalent". Jenkins pourrait cependant être le mieux lié à l'exécution de tests, en particulier pour analyser et présenter les résultats de manière agréable (résultats, détails, graphiques ... à quelques clics), des choses que buildbot ne fait pas "out-of-the-box". Je pense en fait à utiliser les deux pour avoir des pages de résultats de test plus sexy .. :-)
De plus, en règle générale, il ne devrait pas être difficile de créer une nouvelle configuration d'outil: si la spécification de ce qu'il faut faire (configurations, builds, tests) est trop difficile à 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 devrait appeler que des commandes simples. S'il est simple d'exécuter des tests, les développeurs le feront également et cela améliorera le taux de réussite, tandis que si seul le système d'intégration continue exécute les tests, vous l'exécuterez pour corriger les échecs du nouveau code et perdrez sa valeur de non-régression, juste mes 0,02 € :-)
J'espère que cela vous aidera.
L '"intégration des résultats" se trouve également dans jenkins/hudson, et vous pouvez relativement facilement capturer des produits de build sans avoir à les "copier ailleurs".
Pour notre exemple, les rapports de couverture et les mesures de test unitaire et javadoc pour le code Java sont tous intégrés. Pour notre code C++, les plugins manquent un peu, mais vous pouvez toujours en obtenir la plupart) .
nous avons exécuté buildbot depuis la version antérieure à 0.7, et exécutons maintenant 0.8 et ne voyons maintenant aucune raison réelle de changer, car buildbot 0.8 a oublié les esclaves Windows pendant une période prolongée et le support était assez médiocre.
Il existe de nombreuses autres solutions, en plus de Jenkins/Hudson/BuildBot:
- TeamCity by Jetbrains
- Bamboo par Atlassian
- Allez par Thoughtworks
- Régulateur de vitesse
- OpenMake Meister
Les détails de ce que vous faites ne sont pas si importants, en fait, tant que les agents (alias nœuds) sur lesquels vous les effectuez prennent en charge ces tâches.
La beauté d'un serveur CI se remarque lorsque la version change pour déclencher une nouvelle version (et tester), publier les artefacts et publier les résultats des tests.
Lorsque vous comparez des outils CI comme ceux que nous avons mentionnés, considérez des fonctionnalités telles que la convivialité de son interface, la facilité de branchement (et les fonctionnalités qu'il pourrait offrir comme la fusion automatique), les notifications (comme XMPP/Jabber) ou un radiateur d'informations (comme le raccordement) un moniteur pour toujours afficher le statut). Le support produit est une autre chose à considérer - le support de Jenkins est seulement aussi bon que celui qui répond aux questions de la communauté au moment où vous avez des questions.
Mon préféré est Bamboo, mais il est livré avec des frais de licence.
Je suis un utilisateur de longue date de Jenkins au milieu de l'évaluation de Buildbot et je voudrais offrir quelques éléments aux personnes qui envisagent d'utiliser Buildbot pour des solutions multi-modules:
*) Buildbot n'a aucun concept prêt à l'emploi de fichier artifacts lié à chaque build. Ce n'est pas dans l'interface utilisateur et ce n'est dans aucun des modules "étapes" intégrés pour autant que je puisse voir:
http://docs.buildbot.net/current/manual/configuration/buildsteps.html
... et je ne vois aucun plugin tiers:
https://github.com/buildbot/buildbot/wiki/PluginList#steps
Buildbot collecte toutes les sorties de la console à partir d'une génération donnée, mais de manière critique, vous ne pouvez pas collecter les fichiers qui y sont liés.
*) Étant donné que les artefacts ne sont pas pris en charge, il n'est pas facile de créer des projets "collecteurs" qui intègrent plusieurs modules, par exemple, un seul programme d'installation. Jenkins a une grande fonctionnalité qui vous permet de paramétrer une build avec des builds d'autres modules (le type de paramètre est un run).
*) L'établissement de dépendances entre modules est plus délicat dans Buildbot. Supposons que vous ayez une bibliothèque dont dépendent trois binaires et que vous souhaitiez que ces binaires soient reconstruits chaque fois que la bibliothèque change. Jenkins a triggers intégré à l'interface utilisateur. Si vous voulez faire des déclencheurs dans Buildbot, vous devez les scripter en utilisant schedulers.Dependent, et cela provoque beaucoup d'encombrements d'éléments dans l'interface utilisateur Schedulers.
*) Lorsque vous travaillez dans Buildbot, il semble que la quasi-totalité de la configuration se fasse dans master.cfg dans du code. C'est génial et frustrant.
*) Buildbot vous oblige à créer un worker en plus d'un master serveur. C'est gênant pour les débutants et les systèmes pour lesquels un seul serveur de build est suffisant.
Mon impression après deux jours d'évaluation de Buildbot est que nous nous en tiendrons à Jenkins, principalement parce qu'il a artifacts. Buildbot est un outil que nous n'utiliserions que si nous avions des besoins de personnalisation plus étendus et le temps de le faire.
Au sujet de buildbot et des artefacts - je n'ai pas assez de score utilisateur pour faire un commentaire - vous pouvez obtenir des artefacts de la série buildbot 2.x assez facilement avec des actions de téléchargement de fichiers/répertoires intégrés. Cependant, vous ne souhaitez que rarement déplacer des fichiers. En règle générale, vous effectuez un buildstep déclenché qui effectue le déploiement directement sur le travailleur pour de meilleurs résultats. par exemple, stockage Push to Cloud, conteneurs, tierce partie (téléchargements Steam), etc.
De cette façon, vous pouvez obtenir des métriques sur les téléchargements et mieux les contrôler conditionnellement (ou même mélanger et faire correspondre les artefacts sur les machines de travail).