Re: Hudson : est-possible ?

Jean-Baptiste BRIAUD -- Novlog <[email protected]> Tue, 18 Jan 2011 09:39:25 +0100
Newsgroups gmane.comp.java.french.general
Message-ID <[email protected]>
Oui, je comprends l'idée, mais je trouve que cette implémentation du remote run dénature la feature.
En effet, cela impose une transaction avec le Version Control alors que c'est précisément pour l'éviter que le remote run existe.
L'idée du remote run est de faire tourner sur la machine de test le code actuel du développeur avec la même config de test que la build.
C'est très puissant, cela évite un commit, même si avec GIT cela serait probablement plus souple.
Souvent, le test rate rapidement et il faut itérer rapidement et plusieurs fois, ce qui supposerait une gestion peu souhaitable du version control avec beaucoup trop de fusion de branches et autre joyeusetés en perpective ...

Je crois qu'il manque cruellement cette fonction à Hudson car sur le point 2, Hudson semble plus puissant que Teamcity.
Je ne suis pas certain que cela nécessiterait un plugin bien que cette solution adoptée par Teamcity est très confortable.

Un simple scp ou ftp (ou autre du même genre) devrait suffire pour une implémentation simple.
De fait, une fois le code local de la machine du développeur transféré sur la machine de test, il suffit de déclencher la build comme si le code venait d'un version control.
La différence avec un simple scp : 
1. il faut déclencher la build après la copie
2. il faut prévenir le développeur et peut-être pas tout le monde.


On 17 janv. 2011, at 22:01, Baptiste MATHUS wrote:

> Ca va pas forcément t'aider, mais ya ptête un moyen de pas casser le build général: utiliser un DVCS.
> Des fois que votre adhérence à SVN ne soit pas énorme ça peut ptête s'envisager chez vous, je ne connais pas votre config.
> 
> Nous on y pense de plus en plus sérieusement.
> Avec SVN, tout marche bien, mais on manque de souplesse.
> 
> Avec git, par exemple, ce serait très facile d'avoir un dépôt avant IC, et un master post passage OK en IC, poussé automatiquement du premier vers le deuxième en cas de succès. Utiliser un DVCS nous permettrait aussi de mettre en place Gerrit, etc. Bref, ça devient vraiment tentant.
> 
> Désolé :)
> 
> Le 17 janvier 2011 21:54, Jean-Baptiste BRIAUD -- Novlog <[email protected]> a écrit :
> OK.
> 
> Je ne vais pas pouvoir "négocier" le point 1, c'est trop utile. C'est devenu une fonctionnalité critique ici.
> Je lancerait donc les tests sous Windows à la main et non pas automatiquement.
> 
> Merci !
> 
> On 13 janv. 2011, at 11:57, Olivier Lamy wrote:
> 
> > Hello
> >
> > Le 1) Non (là pour le coup il faudrait un plugin eclipse et des modifs hudson)
> >
> > Le 2) Oui (c'est le "Construire un projet multi-configuration" ou
> > Matrix Build) tu peux choisir une matrice de os, jdk
> >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy
> > http://www.linkedin.com/in/olamy
> >
> > Le 13 janvier 2011 11:50, Jean-Baptiste BRIAUD -- Novlog
> > <[email protected]> a écrit :
> >> Bonjour à tous,
> >>
> >> Je souhaiterais savoir avec Hudson s'il est possible, sans s'arracher les cheveux d'avoir les points suivants :
> >>
> >> 1. concept du "remote run" : lancer les tests complets à partir d'un IDE (par exemple IntelliJ et Eclipse) avec la version *locale* du code.
> >> Il faut donc un plugin qui envoi le code de la machine du dev et non pas celui du trunk au serveur de build.
> >> Cela permet de ne pas casser la build generale mais de savoir à quoi s'en tenir en cas de commit.
> >>
> >> 2. de faire qu'une build soit "a cheval" sur plusieurs machines histoire de tester sous differents OS.
> >> L'idée étant de réutiliser le même script.
> >> Nous avons un script Ant qui s'occupe de tout : compile, package, deploy, test, ... et qui contient des section <IF> en fonction de l'OS.
> >> Le résultat est une build qui peut tourner sous Windows et qui lancera des tests avec IE, Firefox et GoogleChrome.
> >> La même build sous Mac lancera les tests sous Safari, Firefox et GoogleChrome.
> >> J'aurais voulu lancer 2 fois le même script sur 2 machines différentes et que les résultats soit rassemblé à la fin.
> >>
> >> Qu'en pensez-vous ?
> >>
> >> Nous utilisons actuellement TeamCity qui donne satisfaction sur le point 1 mais qui semble nous lâcher sur le point 2.
> 
> 
> 
> 
> -- 
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !