Système d'intégration continue pour une base de code Python

Question

Je commence à travailler sur un projet de loisir avec un Python et j'aimerais mettre en place une forme d'intégration continue (c'est-à-dire exécuter une batterie de cas de test à chaque fois qu'un enregistrement est effectué et envoyer des courriels d'avertissement aux personnes responsables lorsque les tests échouent) semblable à Régulateur de vitesse ou TeamCity .

Je réalise que je pourrais faire ça avec des crochets dans la plupart des cas. VCSes mais cela nécessite que les tests soient exécutés sur la même machine que le serveur de contrôle de version, ce qui n'est pas aussi élégant que je le souhaiterais. Est-ce que quelqu'un a des suggestions pour un petit système d'intégration continue, convivial et à code source ouvert, adapté à un système de contrôle de version ? Python codebase ?

Answer 1

Nous courons Buildbot - Trac au travail. Je ne l'ai pas trop utilisé car ma base de code ne fait pas encore partie du cycle de publication. Mais nous exécutons les tests sur différents environnements (OSX/Linux/Win) et il envoie des emails - et il est écrit en Python.

Answer 2

Une possibilité est Hudson. Il est écrit en Java, mais il est intégré aux projets Python :

Hudson adopte Python

Je ne l'ai cependant jamais essayé moi-même.

( Mise à jour Sept. 2011 : Après un conflit de marque, Hudson a été renommé en Jenkins .)

Answer 3

Seconder l'intégration Buildbot - Trac. Vous pouvez trouver plus d'informations sur l'intégration sur le site Web de la Commission européenne. Site web de Buildbot . Dans mon précédent emploi, nous avons écrit et utilisé le plugin qu'ils mentionnent (tracbb). Ce que fait le plugin est de réécrire toutes les urls de Buildbot afin que vous puissiez utiliser Buildbot à partir de Trac. ( http://example.com/tracbb ).

Ce qui est vraiment bien avec Buildbot, c'est que la configuration est écrite en Python. Vous pouvez intégrer votre propre code Python directement à la configuration. Il est également très facile d'écrire vos propres BuildSteps pour exécuter des tâches spécifiques.

Nous avons utilisé BuildSteps pour récupérer les sources depuis SVN, tirer les dépendances, publier les résultats des tests sur WebDAV, etc.

J'ai écrit une interface X10 pour que nous puissions envoyer des signaux avec les résultats de la construction. Quand la construction échoue, nous allumons une lampe à lave rouge. Quand la construction réussissait, une lampe à lave verte s'allumait. De bons moments :-)

Answer 4

Nous utilisons à la fois Buildbot et Hudson pour le développement de Jython. Les deux sont utiles, mais ont des forces et des faiblesses différentes.

La configuration de Buildbot est purement Python et assez simple une fois que l'on a pris le coup de main (regardez la documentation de l'API générée par epydoc pour les informations les plus récentes). Buildbot facilite la définition des tâches non liées aux tests et la répartition des testeurs. Cependant, il n'a pas vraiment de concept de tests individuels, juste une sortie textuelle, HTML, et un résumé, donc si vous voulez avoir une sortie de test navigable à plusieurs niveaux et ainsi de suite, vous devrez le construire vous-même, ou simplement utiliser Hudson.

Hudson offre une excellente prise en charge de la décomposition des résultats globaux en suites de tests et en tests individuels. Il est également très utile pour comparer les résultats des tests entre les différentes versions, mais la distribution (maître/esclave) est comparativement plus compliquée, car vous avez également besoin d'un environnement Java sur les esclaves ; Hudson est également moins tolérant vis-à-vis des liaisons réseau instables entre le maître et les esclaves.

Ainsi, pour bénéficier des avantages des deux outils, nous exécutons une seule instance de Hudson, qui détecte les échecs de test les plus courants, puis nous effectuons une régression multi-plateforme avec Buildbot.

Voici nos exemples :

• Jython Hudson
• Jython buildbot

Answer 5

Nous utilisons Mordu qui est intégré à trac. Et c'est basé sur Python.