[LCC] Gestion des sources et best practices
Guillaume SCHEIBEL
J'ai envi de lancer un débat (j'espère qu'il sera animé et
constructif) et par la même occasion profiter de vos expériences
autour de la problématique de la gestion des sources avec un logiciel
type SVN, TFS etc.
Voici les données:
- plusieurs projets (certains à combiner pour faire un applicatif,
d'autres étant des applications en standalone)
- 4 environnements de déploiement: le poste local, le l’environnement
de développement, celui d'homologation / intégration (pour la partie
recette) et enfin l'environnement de production.
- plusieurs développeurs
J'ai pensé à 2 modèles:
- avoir un tronc qui doit pouvoir être packagé et livré en production
à tout moment. Dès qu'une modification doit survenir sur un projet
(correctif, évolutif) on fait une branche que l'on merge une fois la
validation pour la production obtenue. Le problème est que l'on perd
en flexibilité par rapport aux environnements précédemment cités.
- seconde option: toujours un tronc servant pour la production mais à
ce tronc on ajoute 1 branche qui sert à l'homologation. A cette
branche on ajout 1 branche pour l'environnement de développement et
enfin 1 branche par développeur pour les postes locaux. L'avantage est
qu'avec les sources commitées on peut livré sur l'environnement ciblé
et une fois que les tests sont passés on merge sur la branche en
dessous (puis reteste etc etc jusqu'à la prod) mais on est moins
flexible.
Voilà.
Vous avez 2h pour rendre votre copie. ;)
Qu'en pensez vous ?
PS: Le but est d'intégrer cela dans les prémisses d'une démarche
d'intégration continue avec dans un premier temps des outils type
Maven. Et et facilitant au possible l'installation des postes de
développent bien sûr :)
Romain Pelisse
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Romain PELISSE,
"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett
http://belaran.eu/wordpress/belaran
Moandji Ezana
Bonjour à tous,
J'ai envi de lancer un débat (j'espère qu'il sera animé et
constructif) et par la même occasion profiter de vos expériences
autour de la problématique de la gestion des sources avec un logiciel
type SVN, TFS etc.
Olivier Bazoud
* As tu regarder Git ?
* Ce model de gestion des branches avec Git pourrait te donner des
idées : http://nvie.com/posts/a-successful-git-branching-model
Olivier.
2011/1/24 Romain Pelisse <bel...@gmail.com>:
Romain Pelisse
En quoi est-ce qu'un DVCS est-il obligatoire? Si le "chemin de merge" est à sens unique, comme semble être le cas ici, c'est facile à gérer avec SVN.
Guillaume SCHEIBEL
donc rester plus large. Mais oui j'ai pensé à git qui pourrait
répondre à mon problème cependant j'ai un impératif au niveau SCM
c'est TFS. Je ne suis pas pour mais c'est une contrainte sur laquelle
je n'ai pas la main.
Partant de là, je suis donc plus sur une approche par procédures que
par outils.
On 24 jan, 15:47, Romain Pelisse <bela...@gmail.com> wrote:
> > En quoi est-ce qu'un DVCS est-il obligatoire? Si le "chemin de merge" est à
> > sens unique, comme semble être le cas ici, c'est facile à gérer avec SVN.
>
> Je n'ai jamais dit "obligatoire", j'ai dit "clairement" ;)
>
> Je pense (comme tjrs) qu'un DVCS apportera bcp de souplesse et facilitera la
> mise en place de l'architecture suggerée.
>
> --
> Romain PELISSE,
> insist on coming along and trying to put things in it" -- Terry Pratchett*http://belaran.eu/wordpress/belaran
Romain Pelisse
J'ignore les capacités de TFS (je sais même pas ce que c'est), mais clairement il va définir rapidement les limites du "faisable".
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Romain PELISSE,
"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett
Emmanuel Lecharny
> Bonjour à tous,
> J'ai envi de lancer un débat (j'espère qu'il sera animé et
> constructif) et par la même occasion profiter de vos expériences
> autour de la problématique de la gestion des sources avec un logiciel
> type SVN, TFS etc.
> Voilà.
> Vous avez 2h pour rendre votre copie. ;)
> Qu'en pensez vous ?
Rapidement : utiliser le trunk en production est simplement une hérésie.
Donc aucne des deux options proposées ne me semblent viable.
Le truc, c'est que ce qui est envoyé en production doit de toute façon
passer per tous les environnements, donc disposer d'un tag. Conclusion :
en dev, on corrige, on tag, et on passe aux équipes d'intégration,
d'homologation avant de passer en prod. Tout cela pour un tag donné.
La branch, c'est pour travailler, pas pour releaser.
Après, DVCS ou pas, je pense que c'est complètement hors sujet. Un DVCS
ne va pas changer ce processus, qui s'applique quel que soit le système
de gestion de version utilisé. Avec un DVCS, la notion de tag, c'est
juste une branche qui a été nommé et identifée.
Note : en cas d'urgence, il est possible de bypasser ce process et
patcher dans une branch qui va direct en prod. Les règles, quand on les
viole, ne se mettent pas à hurler (Talleyrand)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Guillaume SCHEIBEL
tous les dev passent (normalement) toutes les étapes. Mais dans ce cas
là, comment gères-tu alors le problème car pour ma part, je ne vois
pas comment allier l'ensemble du processus de validation (via les
environnements adéquats) et la gestion des sources car les 2 doivent
être "synchronisés".
Moandji Ezana
Rapidement : utiliser le trunk en production est simplement une hérésie.
Romain Pelisse
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
Emmanuel Lecharny
> 2011/1/24 Emmanuel Lecharny<elec...@gmail.com>
>
>> Rapidement : utiliser le trunk en production est simplement une hérésie.
>
> Alors il y a beaucoup de hérétiques!
chanson "Met de l'huile" ?
> Sur un projet précédent, après des heures de débat et une équipe divisée en
> parties égales, j'ai conclu qu'il n'y avait aucune différence et que la
> métaphore tronc/branche n'était pas vraiment appropriée : aucune branche
> n'est réellement subordonnée à une autre, elles ont simplement des cycles de
> vie différentes.
Je ne comprend pas. Pour moi, le trunk est en perpétuelle évolution, ce
n'est simplement pas stable. Les branches aussi d'ailleurs, mais il n'y
a pas de contrainte sur une branche style "ça doit builder tout le temps".
Pour moi, la vrai distinction, c'est entre tag et branch/trunk. Une
branch, grosso-modo, c'est fait soit pour tester un truc en local, soit
pour corriger une version antérieure. Dans tous les cas, tant que ce
n'est pas taggé, ça sort pas du dev.
Avec un DVCS, c'est pareil. Ce qui passe en prod, c'est ce que la
personne qui "tire" les branches adaptées tag comme étant une version
utilisable (le tag sera siplement un numéro de commit).
L'idée c'est juste de faire la différence entre quelque chose qui bouge
et quelque chose qui est stable.
> D'ailleurs, j'ai l'impression que les DVCS ne font pas
> vraiment la distinction.
>
> Sur ce même projet, on gérait des branches développement, staging et
> production (j'en oublie peut-être) avec SVN sans aucun problème.
En fait, tout dépend de ce que tu ajoutes dans chaque itération. Il peut
faire sens de packager une version qui vient de dev en y ajouter de la
configuration spécifique en fonction de l'environement, mais ce n'est
que de l'organisation interne, ce que d'aucuns nommeraient de la gestion
de configuration. Dans tout les cas de figure, ce qui rentre en prod est
clairement identifié par un numéro de version unique cross env.
Et ne faites pas ce que j'ai vu dans un des gros projets sur lequel j'ai
travaillé (300 personnes dont 150 développeurs) : ils avaient 4 repos
(CVS, pôvre), un pour le dev, un pou l'équipe framework, un pour
l'intégration et un pour les tests. Pour tracer une modif, tu pleures ta
mère et ta soeur avec des larmes de sang caillé...
Romain Pelisse
Avec un DVCS, c'est pareil. Ce qui passe en prod, c'est ce que la personne qui "tire" les branches adaptées tag comme étant une version utilisable (le tag sera siplement un numéro de commit).
Moandji Ezana
Pour moi, la vrai distinction, c'est entre tag et branch/trunk. Une branch, grosso-modo, c'est fait soit pour tester un truc en local, soit pour corriger une version antérieure. Dans tous les cas, tant que ce n'est pas taggé, ça sort pas du dev.
Avec un DVCS, c'est pareil. Ce qui passe en prod, c'est ce que la personne qui "tire" les branches adaptées tag comme étant une version utilisable (le tag sera siplement un numéro de commit).
L'idée c'est juste de faire la différence entre quelque chose qui bouge et quelque chose qui est stable.
En fait, tout dépend de ce que tu ajoutes dans chaque itération. Il peut faire sens de packager une version qui vient de dev en y ajouter de la configuration spécifique en fonction de l'environement, mais ce n'est que de l'organisation interne, ce que d'aucuns nommeraient de la gestion de configuration. Dans tout les cas de figure, ce qui rentre en prod est clairement identifié par un numéro de version unique cross env.
Emmanuel Lecharny
>> Avec un DVCS, c'est pareil. Ce qui passe en prod, c'est ce que la personne
>> qui "tire" les branches adaptées tag comme étant une version utilisable (le
>> tag sera siplement un numéro de commit).
>>
> Je dirais plus ou moins "non". Avec un DVCS, tu peux avoir un référent (le
> trunk) stable car les commits ne sont pushés que après validation.
fait, la notion de trunk ou de branche dans un DVCS s'efface, mais il
n'en demeure pas moins qu'il faut bien que quelqu'un décide qu'une
révision est stable (et la tag comme telle).
Mais le principe est le même : le release manager (celui qui 'tire' les
branches pour crééer la release ne fait rien d'autre que créer un tag).
Guillaume SCHEIBEL
C'est dans ce sens là que je souhaite aller c'est pour ça que plutôt
que "Trunk" j'ai envi de parler de "Main'" qui est toujours stable
d'où la capacité à tout moment de packagé et déployer en production.
Les seules vraies version instables sont les branches de dev (1 par
développeur) même la branche d'Homologation est stable (au sens pas
d'exception ou de plantage bizarre) elle n'est peut-être pas valide au
niveau fonctionnel mais c'est un autre problème.
Et on ne change d'environnement que lorsque le précédent est validé.
Guillaume
On 24 jan, 17:35, Romain Pelisse <bela...@gmail.com> wrote:
> > Avec un DVCS, c'est pareil. Ce qui passe en prod, c'est ce que la personne
> > qui "tire" les branches adaptées tag comme étant une version utilisable (le
> > tag sera siplement un numéro de commit).
>
> Je dirais plus ou moins "non". Avec un DVCS, tu peux avoir un référent (le
> trunk) stable car les commits ne sont pushés que après validation.
>
> Exemple: équide de dev1 clone le "trunk", bosse dessus, font des commits. La
> Q/A ou le testeurs clonent leur repos, valident, le bon fonctionnement et
> l'intégration, et dit "OK pour pusher ces révisions". Hop, on push dans le
> référent, qui était "stable" et qui le reste.... Dans ce contexte, ton trunk
> n'est jamais instable (sauf erreur of course, mais on peut aussi commité
> dans la merde dans une branche de dev).
>
> --
> Romain PELISSE,
> insist on coming along and trying to put things in it" -- Terry Pratchett*http://belaran.eu/wordpress/belaran
Emmanuel Lecharny
>> quelque chose qui est stable.
>>
> Je pense qu'on est d'accord l'un avec l'autre :). Les branches sont des
> flux, les tags sont des instantanés de ce flux.
évidement cela, mais aussi une version prête à l'emploi).
Moandji Ezana
Les seules vraies version instables sont les branches de dev (1 par développeur)
Guillaume SCHEIBEL
Pourquoi 1 par développeur, cela permet de limiter la propagation des
erreurs/instabilité aux développeursµ.
Le problème qui se pose alors est comment assurer l'intégrité des
environnements car en cas de modification sur un projet, il faut que
celle-ci soit obligatoirement répercutée.
D'où sur la branche de dev qui est alors "commune", faire 1 branche /
projet au besoin cela permet d'améliorer la granularité (et cela
n'empêche pas les autres de travailler en bloquant le workspace). Une
fois le dev terminer, on merge la branche. Comme ça dès que d'un autre
développeur doit travailler sur ce projet il sera à jour au niveau des
sources.
Mais un autre problème ce pose, les dépendances entre projets. Je
m'explique:
Soit un projet X dépendant du projet A
Soit un projet Y dépendant aussi du projet A
En cas d'utilisation type lecture aucun problème mais en cas de
modification ....
De plus si à un autre moment je modifie modifier le projet A il faut
que je passe des tests de non-régression sur tous les projets qui en
dépendent.
Guillaume
On 24 jan, 17:58, Moandji Ezana <mwa...@gmail.com> wrote:
> J'ai l'impression que tout le monde est plus moins d'accord sur la façon de
> travailler, mais utilise des mots différents...
>
Moandji Ezana
Pourquoi 1 par développeur, cela permet de limiter la propagation des
erreurs/instabilité aux développeursµ.
Le problème qui se pose alors est comment assurer l'intégrité des
environnements car en cas de modification sur un projet, il faut que
celle-ci soit obligatoirement répercutée.
De plus si à un autre moment je modifie modifier le projet A il faut
que je passe des tests de non-régression sur tous les projets qui en
dépendent.
Guillaume SCHEIBEL
d'abord poser cela en terme de gestion de sources car c'est la
première facette du problème à laquelle je suis confronté mais à terme
effectivement on est sur de l'intégration continue.
Guillaume
On 25 jan, 09:54, Moandji Ezana <mwa...@gmail.com> wrote:
> 2011/1/25 Guillaume SCHEIBEL <guillaume.schei...@gmail.com>
Emmanuel Lecharny
> C'est l'impression que j'ai également.
> Pourquoi 1 par développeur, cela permet de limiter la propagation des
> erreurs/instabilité aux développeursµ.
propre branche, c'est que vous n'avez pas réussi à découper votre projet
en isolant les dépendances. (Si tu utilises un DVCS, la question est
différente, sachant que tu n'a pas de source centralisé, chaque
dévelopeur ayant le repo complet localement, mais ça ne change rien, il
y a toujours une branche référence).
Normalement, une branche c'est fait pour s'isoler temporairement, mais
ça ne doit pas durer éternellement (je ne parle pas des branches de
correction de versions déjà livrées ici).
Il ne devrait pas y avoir de problème lors du développement, à condition
que chacun travaille sur sa partie, que les conséquences sur les autres
parties sont identifiées, discutées et traitées (définition d'une API,
de mock object temporaires, etc). En tout cas, la branche de référence
(le trunk en SVN) doit toujours builder, quelques soient les modifs
effectuées.
> Le problème qui se pose alors est comment assurer l'intégrité des
> environnements car en cas de modification sur un projet, il faut que
> celle-ci soit obligatoirement répercutée.
Au lieu de tarvailler sur des branches séparées, travaillez sur des
projets séparés, avec taggage des versions successives.
Je pense que tu essayes de résoudre un problème de gestion de
configuration avec un outil de gestion de version. Si tu utilises Maven,
ou ant, il te suffit que le projet parallèle ait une version données qui
soit intégré dans un repo de dépendences, et que les autres projets se
refèrent à une version de ce module. Pas besoin de dépendre d'une
branche dans ton système de sources.
Dépend de versions releasées, pas de fichiers sources, en clair.
> D'où sur la branche de dev qui est alors "commune", faire 1 branche /
> projet au besoin cela permet d'améliorer la granularité (et cela
> n'empêche pas les autres de travailler en bloquant le workspace). Une
> fois le dev terminer, on merge la branche. Comme ça dès que d'un autre
> développeur doit travailler sur ce projet il sera à jour au niveau des
> sources.
> Mais un autre problème ce pose, les dépendances entre projets. Je
> m'explique:
> Soit un projet X dépendant du projet A
> Soit un projet Y dépendant aussi du projet A
>
> En cas d'utilisation type lecture aucun problème mais en cas de
> modification ....
Voir plus haut. Gestion de source != gestion de conf.
> De plus si à un autre moment je modifie modifier le projet A il faut
> que je passe des tests de non-régression sur tous les projets qui en
> dépendent.
Encore une fois, gestion de conf. Maven, gradle, Ant+Ivy, buidr etc...
Emmanuel Lecharny
> Complètement, voulant entrer dans cette problématique pas-à-pas j'ai
> d'abord poser cela en terme de gestion de sources car c'est la
> première facette du problème à laquelle je suis confronté mais à terme
> effectivement on est sur de l'intégration continue.
Ce n'est pas un problème d'IC, c'est un problème de gestion de conf. Et
il faut commencer par là. L'outil de gestion de version est juste
essentiel, mais ça ne doit pas dicter ton organisation. C'est en fait le
contraire : ton organisation doit dicter ton utilisation de ton outil de
gestion de version.
Enfin, je pense que c'est également ce que dit Moandji. Donc on converge :)
PS : DVCS vs SVN, c'est aussi un choix à faire. Si ton projet est en
entreprise, avec tout le monde sur le site, un DVCS ne va pas forcément
t'apporter un plus gigantesque. Mais enfin, bon, c'est à la mode, il
faudra juste t'assurer d'avoir les compétences requises. Je ne pense pas
non plus que ce soit un critère fondamental de réussite ou d'échec de
ton projet...
Moandji Ezana
--
Guillaume SCHEIBEL
> contraire : ton organisation doit dicter ton utilisation de ton outil de
> gestion de version."
absolue la meilleure façon de faire est celle est correspond le mieux
à notre projet / entreprise / équipe.
Mais il est toujours bon de confronter les points de vue afin de faire
évoluer le niveau et les pratiques.
Guillaume
Emmanuel Lecharny
> Le mail d'Emmanuel me rassure que je ne suis pas complètement à l'ouest...
Et réciproquement :) On ne doit pas avoir tout à fait tort, sachant que
nos mails se sont croisés :)
Tu mailais de ta branche locale, je suppose ? ;)
Romain Pelisse
PS : DVCS vs SVN, c'est aussi un choix à faire. Si ton projet est en entreprise, avec tout le monde sur le site, un DVCS ne va pas forcément t'apporter un plus gigantesque. Mais enfin, bon, c'est à la mode, il faudra juste t'assurer d'avoir les compétences requises. Je ne pense pas non plus que ce soit un critère fondamental de réussite ou d'échec de ton projet...
En fait, c'est déjà pas mal je trouve, mais pour rejoindre Emmannuel, ça ne va pas régler tes problèmes d'organisation - sauf si, par exemple, une équipe entière utilise git avec un repo commun en 'frontal' du serveur central.
--
Romain PELISSE,
"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett
Moandji Ezana
Tu mailais de ta branche locale, je suppose ? ;)
Emmanuel Lecharny
(http://www.generation-nt.com/google-wave-fondation-apache-actualite-1126551.html)
Guillaume SCHEIBEL
regroupe la gestion des sources, le IC, les configurations, les
environnements de travail etc etc. Mais il faut bien aborder le
problème par 1 bout. Et à cela s'ajoute 2 choses: le budget alloué par
le client et (comme vous l'avez remarqué) mon "novisme" / approche
hésitante sur le sujet. :)
Guillaume
On 25 jan, 10:50, Romain Pelisse <bela...@gmail.com> wrote:
> > PS : DVCS vs SVN, c'est aussi un choix à faire. Si ton projet est en
> > entreprise, avec tout le monde sur le site, un DVCS ne va pas forcément
> > t'apporter un plus gigantesque. Mais enfin, bon, c'est à la mode, il faudra
> > juste t'assurer d'avoir les compétences requises. Je ne pense pas non plus
> > que ce soit un critère fondamental de réussite ou d'échec de ton projet...
>
> Yep, dans cette configuration, un DVCS t'apporte juste un peu plus de
> souplesse :
> - branches locales pour organiser ton propre travail (une branche pour le
> bug du moment, une autre paire pour tes feat. dev)
> - réécriture de l'historique (avant push vers le serveur centrale)
> - bisect (détection du commit ayant introduit une régression)
>
> En fait, c'est déjà pas mal je trouve, mais pour rejoindre Emmannuel, ça ne
> va pas régler tes problèmes d'organisation - sauf si, par exemple, une
> équipe entière utilise git avec un repo commun en 'frontal' du serveur
> central.
>
> Mais sur le fond, je le rejoins aussi sur ce point : c'est une question
> d'organisation. Il faut probablement voir le problème en "entier" en
> incluant la CI, les outils de build et la gestion de sources. Tu définies ce
> que tu veux atteindre, et après tu voies quelle "partie" de cet objectif
> sera en fait assurer par tel ou tel outil.
>
> --
> Romain PELISSE,
> insist on coming along and trying to put things in it" -- Terry Pratchett*http://belaran.eu/wordpress/belaran
Emmanuel Lecharny
> Je suis entièrement d'accord avec toi c'est un problème entier qui
> regroupe la gestion des sources, le IC, les configurations, les
> environnements de travail etc etc. Mais il faut bien aborder le
> problème par 1 bout.
> Et à cela s'ajoute 2 choses: le budget alloué par
> le client
pas de budget, pas de projet...
Guillaume SCHEIBEL
comme l'on doit faire une très grosse évolution qui implique de "tout
casser" je réfléchie à comment améliorer les procédures, la gestion
des sources, les builds, les livraisons etc etc.
Guillaume
Emmanuel Lecharny
> Niveau conf, on a déjà les environnements et une partie sous ant mais
> comme l'on doit faire une très grosse évolution qui implique de "tout
> casser" je réfléchie à comment améliorer les procédures, la gestion
> des sources, les builds, les livraisons etc etc.
Maven, maven, maven...
Guillaume SCHEIBEL
moi .....
Question pour ce qui ont eu à mettre en place ces systèmes (DVCS,
Maven, IC) sur un projet existant quel est le RIO (Retour sur
investissement) que vous avez obtenu ? Car au final soyons lucide
c'est ce qui intéresse les personnes au dessus de nous (client +
managers).
Romain Pelisse
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Romain PELISSE,
"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett
Emmanuel Lecharny
> Question pour ce qui ont eu à mettre en place ces systèmes (DVCS,
> Maven, IC) sur un projet existant quel est le RIO (Retour sur
> investissement) que vous avez obtenu ? Car au final soyons lucide
> c'est ce qui intéresse les personnes au dessus de nous (client +
> managers).
Putain ça devient fatiguant d'être informaticien s'il faut expliquer aux
blaireaux qui tripote les chiffres dans excel pourquoi Maven, qui est
utilisé plus que Ant de nos jours, a un ROI positif...
Est-ce que tu vas demander à tes managers une explication sur le ROI de
l'utilisation de SAP ou de la banque X plutôt que Y ?
Sérieusement, si j'ai un client qui me dit qu'il impose CVS et make
comme outil de dev, ce sera pas mon client, parce que, franchement, il y
connait quoi? Je vais pas non plus imposer à mon dentiste d'utiliser la
fraise mécanique de ma jeunesse en lieu et place de son tout nouveau
système laser qui tue la mort ! Chacun sa merde...
Allez, bon courage :)
Henri Gomez
> blaireaux qui tripote les chiffres dans excel pourquoi Maven, qui est
> utilisé plus que Ant de nos jours, a un ROI positif...
Ben voila, maintenant l'Emmanuel il est tout énervé :)
Romain Pelisse
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Romain PELISSE,
"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett
Emmanuel Lecharny
Bah, non, je prenais juste un café post déjeuner, en attendant une
grosse compile (mieux vaut une grosse compile qu'une petite qu'on moud...).
Je retourne sur mon code pour le reste de la journée maintenant...
