2010-11-30 26 views
3

Je travaille dans une société de logiciels où notre langage de développement principal est Java. Naturellement, nous utilisons Hudson pour des builds continus, pour lesquels il fonctionne avec brio. Cependant, Hudson n'est pas très bon pour d'autres choses que nous lui demandons de faire. Nous utilisons également des jobs Hudson pour déployer des binaires, actualiser des bases de données, lancer des tests de charge, régressions d'exécution, etc. Nous rencontrons vraiment des problèmes en présence de dépendances de build (les tests de charge requièrent une actualisation DB).Autre gestionnaire de construction pour Hudson

est ici la seule chose que Hudson ne fait pas que nous avons vraiment besoin:

Construire la dépendance: Il prend en charge les dépendances de construction pour Ant construit, mais pas pour les emplois Hudson. Nous utilisons la fonction d'invocation d'URL pour qu'un travail Hudson appelle un autre travail Hudson. Le problème est que Hudson retourne toujours un 200 et ne bloque pas jusqu'à ce que le travail est terminé. Cela signifie que le travail appelant ne sait pas a) si la construction a échoué et b) si cela n'a pas échoué, combien de temps cela a pris.

Il serait bien de ne pas avoir à utiliser le script shell pour spécifier le comportement d'une construction, mais ce n'est pas totalement nécessaire.

Toute direction serait bien. Peut-être que nous n'utilisons pas Hudson dans le bon sens (toutes les builds doivent-elles être construites Ant?) Ou peut-être avons-nous besoin d'un autre produit pour notre déploiement en un clic, migration, rafraîchissement DB, etc. Pour clarifier, nous avons des paramètres dans nos builds qui peuvent causer différentes dépendances en fonction des paramètres. C'est à dire. Parfois, nous voulons tester la charge avec un rafraîchissement DB, parfois sans rafraîchissement DB. Malheureusement, la création d'un travail Hudson pour chaque combinaison de paramètres (comme l'exige le plugin Join) ne fonctionnera pas car les différentes combinaisons peuvent parfois mener à des dizaines de tâches.

+1

Pouvez-vous expliquer ce que vous entendez par "dépendance de construction"? Il est facile de configurer un projet Hudson pour lancer une autre build Hudson. Avez-vous besoin de quelque chose de plus automatique? –

+1

Hudson est aussi bon que possible, les alternatives sont loin d'être aussi compétentes. Restez avec. – skaffman

+0

Si vous rencontrez des problèmes pour que Hudson fasse ce que vous voulez faire, vous pouvez réexaminer votre configuration et les choses que vous essayez de faire (par exemple, pourquoi partagez-vous une base de données entre des environnements de test de charge et autres builds) –

Répondre

5

Il existe une interface CLI pour Hudson qui vous permet d'émettre des commandes vers une instance Hudson. Utilisez "aide" pour obtenir des détails précis. Je crois qu'il y en a un qui vous permet d'invoquer une construction et d'attendre sa finition.

http://wiki.hudson-ci.org/display/HUDSON/Hudson+CLI

7

Je ne pense pas que je comprends vos besoins « construire la dépendance ». Tout travail Hudson peut être configuré pour déclencher un autre travail (en aval) ou être déclenché par un autre travail (en amont). Les Downstream-Ext plugin et Join plugin permettent une définition plus complexe des dépendances de construction.

+0

Ce que je veux dire par "dépendance de construction", c'est que Job B devrait s'exécuter si et seulement si Job A a fini et réussi. La raison pour laquelle nous ne pouvons pas avoir d'emploi Un début de tâche B est parce qu'il peut y avoir plusieurs dépendances sur Job A. Les modules habituels ne fonctionnent pas parce que nous exécutons habituellement les emplois à l'intérieur d'un script shell basé sur journal de les paramètres de la construction. C'est à dire. exécute le Job A si "db refresh" est vrai, sinon ne l'exécute pas. –

+0

@Patrick, intéressant. Je n'ai jamais rencontré un ensemble aussi complexe de dépendances auparavant. Je pense que ma solution serait de pousser cette intelligence dans le système de construction plutôt que d'écrire des scripts via Hudson. Mais je peux imaginer qu'il y a des avantages à avoir des emplois à Hudson aussi. –

2

Avez-vous besoin d'un travail supplémentaire pour vos «dépendances»? Vos dépendances sonnent pour moi comme une étape supplémentaire de construction. Le script qui actualise la base de données peut être stocké dans votre scm et chaque build qui a besoin de cette étape va le vérifier. Vous pouvez appeler ce script si votre paramètre "db refresh" est true. Cela peut être fait avec plus d'un seul de vos modules. Quel est l'avantage? Votre logique de script est dans votre scm (il est toujours bon d'avoir un historique des changements). Vous avez toujours la possibilité de mettre à jour le script une fois pour tous vos travaux de test (puisque tous vérifient le même script). En outre, vous n'avez pas besoin de regarder plusieurs scripts pour savoir si votre test a réussi ou non. Surtout si vous avez un travail qui fait partie de plusieurs lignes d'exécution, il devient difficile de savoir quel travail a été exécuté. Un autre avantage est que vous avez moins d'emplois sur votre Hudson et qu'il est donc plus facile à entretenir.

+0

+1, merci d'avoir exprimé ce que ma réponse de commentaire à @Patrick n'a pas capturé. –

1

Je pense que ce que vous recherchez est http://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin Ce plugin vous permet d'exécuter d'autres tâches en fonction de l'état des travaux précédents.Vous pouvez même appeler un script shell depuis le projet en aval pour déterminer les conditions supplémentaires. qui peut à son tour appeler l'API pour plus d'informations. Par exemple, nous avons une étape de post-construction à nous notifier, cela rappelle l'API JSON pour construire un bon sujet dans notre canal IRC qui dit "Toutes les builds ok" ou "X, Y échouent", etc