Le 15/05/2013 19:38, Emmanuel Thierry a écrit :
>
> De ce point de vue git fait ce qu'on lui demande. Si tu demandes à tes devs 
> de n'utiliser qu'un seul upstream tu as une architecture centralisée avec git.
> Par contre empêcher des développeurs d'avoir des branches locales par pure 
> doctrine c'est juste les empêcher de travailler. Derrière ils vont contourner 
> le problème pour pouvoir garder un environnement local qui leur correspond, 
> ou encore régler les problèmes causés par subversion lui-même (qui est un 
> outil de versioning antédiluvien), et ils vont perdre du temps à faire tout 
> ça au lieu de faire des choses utiles.
>
> Je ne comprends pas en quoi du closed source impose la centralisation. Que tu 
> fasses du closed-source ou de l'open-source tu seras obligé en tant que 
> développeur:
> * de tester tes modifs avant de les pousser sur le dépôt central
> * de maintenir des modifications non-terminées en local parce que tu dois 
> pipeliner entre plusieurs tâches (oh ! une demande de bugfix 
> ultra-prioritaire qui arrive !)
> * de te préserver un environnement custom en local pour le déboggage de ta 
> partie du code
> Tout ce que tu ne peux pas faire (facilement) avec svn.
>
Je comprend ce point de vue en tant que développeur, mais le côté sysadm
fait qu'au contraire tu n'as pas à tester sur ton poste en local mais tu
dois utiliser un environnement de dev / recette / preprod conforme à la
prod. Après que tu passes par de la virtualisation ou du vhost par
développeur pour être suffisament isolé et pas être impacté par les
modifs en cours des voisins, c'est à voir mais c'est pas au dev de faire
des environnements de test.
J'ai suffisamment donné depuis 10 ans à entendre c'est pas ma faute ça
marche sur mon poste, c'est la prod qui est pas bien réglé. Sauf que les
contraintes de sécurités entre la prod et son poste perso sont pas les même.

Bref la centralisation vient de là principalement. Svn n'est pas si
obsolète que cela, au quotidien il n'y a pas de différence à mon sens et
niveau.

Par contre le cas de devoir faire plusieurs branches et devoir les
resynchroniser j'ai pas vu un seul client qui se dit pourtant Agile ne
pas perdre un temps fou là dessus. Alors que structurer les demandes
release par release et que tout le monde se concentre sur les points
définis c'est tellement plus stable dans le temps. Enfin c'est mon
ressenti dans l'encadrement, l'hébergement et l'infogérance de clients
type Agile. J'en ait deux qui font des releases plusieurs fois par jour,
chaque release contient les tâches nécessaires à l'obtention d'un
élément urgent ou évolution. Tous les dev bossent ensemble en même temps
sur les tâches à faire (découper en des éléments super simples). Et avec
eux j'ai aucun souci, stabilité de l'application à toute épreuve, aucun
rollback fait.

A voir donc, autant Git pour kernel je comprend même si j'aimerais voir
comment les mainteneurs arrivent à récupérer et merger autant de
branches différentes tout en maintenant une stabilité et la gestion des
dépendances. Mais là c'est un autre niveau de dev et puis l'outils a été
codé pour eux et ils ont pas de commerciaux ou marketeux pour les
perturber dans leur travaux, ça compte énormément aussi.

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/

Répondre à