--
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
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.
* 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>:
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.
--
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
> 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
Rapidement : utiliser le trunk en production est simplement une hérésie.
--
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
> 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é...
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).
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.
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).
Les seules vraies version instables sont les branches de dev (1 par développeur)
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.
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...
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...
--
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 ? ;)
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...
Tu mailais de ta branche locale, je suppose ? ;)
> Et à cela s'ajoute 2 choses: le budget alloué par
> le client
pas de budget, pas de projet...
Maven, maven, maven...
--
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
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 :)
Ben voila, maintenant l'Emmanuel il est tout énervé :)
--
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
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...