Analyse de rentabilisation des systèmes de contrôle de version décentralisés

26

J'ai cherché et n'ai trouvé aucune raison commerciale pour laquelle les systèmes git / mercurial / bazzr sont meilleurs que les systèmes centralisés (subversion, perforce).

Si vous tentiez de vendre un DVCS à une personne non technique, quels arguments fourniriez-vous pour que le profit DVCS augmente .

Je vais bientôt lancer git à mon manager, cela prendra du temps pour convertir les référentiels de subversion et quelques dépenses pour acheter des licences smartgit.

Edit J'ai essayé de faire de cette question une discussion générique sur centralisée vs décentralisée, mais inévitablement elle s'est transformée en git vs subversion. Il existe certainement de meilleurs systèmes centralisés que la subversion.

Keyo
la source
1
Nous sommes dans une position similaire pour ce qui est de plaider la cause et il faut le dire, je ne suis pas convaincu qu'il y en ait actuellement.
Jon Hopkins
Pourrait git-svnrépondre à vos besoins?
JBRWilkinson
@JBRWilkinson Je viens d'utiliser git-svn pour migrer un tas de référentiels vers git. La société n'a pas beaucoup investi dans des outils qui s'intègrent avec svn, donc ce n'était pas vraiment un problème.
Keyo
Ref the edit - vous n'avez toujours pas expliqué comment et pourquoi SVN vous fait défaut de telle sorte que vous sentez que vous avez besoin d'un remplacement. Ma réponse (par exemple) ne concerne PAS git vs svn, il s'agit de trouver une analyse de rentabilisation pour changer le statu quo.
Murph

Réponses:

23

Hmm, après avoir été manager, j'ai deux réactions immédiates à ce sujet:

  • Si vous n'avez pas déjà de bonnes raisons pourquoi lancez-vous autre chose que d'être à la mode?
  • De même, comment Subversion échoue-t-il au point que vous ayez besoin d'un remplacement?

Je ne suis pas, en fait, négatif - je pense qu'il y a probablement un argument à faire (selon les circonstances) mais si le cas est simplement que git est "meilleur" que la subversion alors vous n'en avez pas vraiment un.

Vous devez également être en mesure d'énumérer les inconvénients - vous avez déjà identifié les frais généraux liés à la migration et au réoutillage - quel est le problème supplémentaire? Par exemple, qu'advient-il de votre joli référentiel central et sauvegardé? Comment vous intégrez-vous à votre serveur de build d'intégration continue (si vous n'en avez pas, oubliez git et commencez par trier cela). Oh sécurité et suivi - SVN fonctionne avec des connexions et des autorisations appropriées.

À mon avis, les avantages sont la flexibilité, une meilleure fusion, la possibilité de faire des commits locaux sans casser la construction et ainsi de suite. Les inconvénients sont le manque de contrôle et la même flexibilité.

Il se peut que tout ce que vous voulez faire soit d'exécuter git localement sur votre machine en tant que "meilleur" client de subversion (je cherche à le faire en utilisant mercurial).

Hmm, peut-être que toute cette réponse est vraiment un commentaire? Vous devez présenter votre argumentation ici (dans la question) pour git over subversion (dans votre environnement) afin de voir si nous pouvons vous aider à identifier l'analyse de rentabilisation.


FWIW, je sais que l'on peut facilement désigner une instance spécifique du référentiel comme source de tronc / référence et que c'est ainsi que l'on se connecte à son serveur de build - la différence étant qu'avec DVCS, c'est plus une décision administrative que quelque chose d'inhérent à l'architecture.

Murph
la source
1
Résolution des problèmes d'autorisations / flexibilité: vous avez également besoin d'un référentiel "source", où vous pouvez réellement définir les droits comme d'habitude. L'intégration continue s'exécute pour le référentiel source, les développeurs clonent le référentiel source, etc. Sa sauvegarde est cependant moins importante, car tout le monde a un clone, pas seulement une extraction.
Matthieu M.
1
Le point sur les clones complets étant des sauvegardes est bien fait. J'admettrai librement qu'il y a certains domaines de cela que je ne comprends pas assez bien car mes trucs "de travail" sont svn et mon mercurial est personnel et, pour l'instant, quelque peu limité.
Murph
14

Je dirais que la ramification et la fusion rapides et indolores permettraient aux développeurs d'être plus productifs avec leur code, car chaque nouvelle fonctionnalité pourrait être branchée, puis fusionnée plus tard. Rendre le processus de développement plus fluide. De plus, la nature distribuée permettrait à chaque développeur d'avoir une copie complète du code, donc il n'y a pas à craindre qu'une panne de serveur centralisée ne supprime tout votre code. Il y a probablement plus de raisons, ces deux-là, cependant, sont mes principales raisons d'utiliser Git.

mbreedlove
la source
2
Dans un environnement professionnel, le «serveur centralisé» aurait une redondance, une sauvegarde et des administrateurs chargés de le maintenir (et de tous les autres serveurs) en vie.
JBRWilkinson
2
Dans un environnement de grande entreprise, vous auriez une redondance de serveur. Dans une petite entreprise, une telle redondance de serveurs n'est pas aussi certaine.
Michael Shaw
2
Une panne de serveur centralisée ne supprimerait pas tout votre code. Même si vous ne disposiez pas de sauvegardes, le pire qu'il puisse faire est de supprimer votre historique de révision. Mais tant que tous les développeurs ont extrait le code, il existe également sous sa forme actuelle sur leurs systèmes.
Mason Wheeler
1
@mason: mais c'est tout à fait une hypothèse: "aussi longtemps que tous les développeurs ...". deux.
Inca
Et aussi, je ne sous-estimerais pas la valeur de l'historique des commit. Dans un énorme système, il peut être très utile de voir qui et pourquoi a fait quelque chose au code.
Tamás Szelei
8

Je suppose que vous pouvez plaider en faveur d'un contrôle de version augmentant la productivité (et donc le profit) même lorsqu'un développeur travaille seul.

Un bon DVCS reconnaît les mêmes avantages de productivité même lorsqu'il travaille en équipe - chaque développeur peut bénéficier de tous les avantages du contrôle de version - il peut effectuer des validations fréquentes, des retours en arrière, jouer avec les choses, etc. - sans se soucier des conflits avec ce que les autres développeurs font jusqu'à ce qu'ils soient prêts à pousser leurs modifications.

Anon.
la source
C'est à peu près ce que j'allais publier. Vous devriez certainement voir des améliorations de productivité de la part des développeurs qui s'engagent tôt et souvent dans leur propre référentiel, sans causer de problème à aucun de leurs collègues.
Carson63000
5
Ensuite, vous serez en enfer d'intégration lorsque vous finirez par pousser vos changements. C'est une mauvaise chose pas une bonne chose.
Henry
Comme vous effectuez un développement local avec de nombreuses validations, vous pouvez continuer à extraire les modifications du référentiel central et à maintenir vos modifications locales en ligne avec le développement en cours sur lequel d'autres travaillent. Ainsi, lorsque vient le temps de pousser vos modifications vers le référentiel central, vous devriez déjà avoir la majorité des modifications qui s'y sont produites et l'intégration sera facile.
DaveJohnston
1
À moins que l'un de vos collègues n'ait fait exactement la même chose et que vous ne vous soyez pas tous les deux intégrés depuis un certain temps. Il y a toujours un compromis. J'ai vu des cas où des choses avaient été intégrées sur la ligne principale alors qu'elles n'auraient pas dû l'être (mauvaise solution, tentative sans issue pour une solution, etc.), l'intégration à l'intégralité des fonctionnalités a aussi ses avantages.
Joppe
2
Ne pouvez-vous pas faire toutes ces choses avec (a) des branches SVN ou (b) plusieurs copies de travail?
JBRWilkinson
4
  • Branche par bogue
  • Latence réduite sur vos diffs.
  • Être en mesure de naviguer très rapidement et arbitrairement dans l'historique d'une succursale lorsque vous passez en revue par des pairs.
  • Vous avez toujours accès à l'intégralité de votre historique lorsque vous n'avez pas accès au serveur centralisé: vous n'êtes pas au bureau, l'alimentation vient de s'éteindre mais la batterie de votre ordinateur portable fonctionne toujours, ...

Ces choses vous permettent de travailler plus efficacement, à la fois en solo et en équipe. Travail plus efficace = temps de développement plus rapide = temps de mise sur le marché plus rapide = profit.

Frank Shearar
la source
3

Pardonnez-moi de créer un lien vers mon propre blog, mais j'ai écrit des articles sur ce même sujet:

N'hésitez pas à voter contre si vous ne les trouvez pas pertinents.

En un mot, DVCS facilite les modèles de branchement qui peuvent empêcher de grands groupes de développeurs de marcher les uns sur les autres, ce qui augmente à la fois la productivité et la qualité de construction quotidienne. La partie de collaboration désordonnée du contrôle de version peut être effectuée dans des référentiels locaux, laissant votre référentiel central plus propre et de meilleure qualité. De plus, les décisions sur le moment de la succursale peuvent avoir un grand effet sur l'efficacité, par exemple si un département est prêt à commencer à travailler sur 2.0 alors que 1.0 est toujours nettoyé par d'autres. Le DVCS permet que ces décisions soient prises au niveau local plutôt que par comité.

Karl Bielefeldt
la source
Vos entrées de blog sont bien écrites. Je ne les ai cependant pas encore tous lus. Je me demande pourquoi vous avez choisi Bzr alors que Git et Hg semblent être beaucoup plus populaires. Les gens semblent détester Bzr pour sa lenteur. Je suis aussi un fan de Git à cause des hachages d'arbre au lieu des numéros de révision, ce qui me semble très sûr. Les nombres bzr rev ne seront-ils pas tous brouillés lorsque les branches seront fusionnées?
Keyo
2
@Keyo, j'ai choisi bzr parce que je devais m'enseigner DVCS et bzr est le plus convivial pour les débutants. Depuis, je suis passé à git pour la vitesse, les fonctionnalités et la stabilité. Bazaar hache également ses révisions et possède des identifiants uniques au monde, ils ne sont tout simplement pas ceux par défaut exposés à l'utilisateur. Leurs numéros de révision ne sont pas vraiment différent que d' utiliser HEAD~1, HEAD~2etc. dans git. Il est très rare que vous ayez besoin du hachage réel, mais c'est la première chose que vous apprenez dans git et c'est toujours dans votre visage. Cacher cela à l'utilisateur, sauf si vous en avez vraiment besoin, est une des raisons pour lesquelles bzr est plus convivial pour les débutants.
Karl Bielefeldt
Merci pour la clarification. Git n'était pas exactement facile pour moi de venir de la subversion. Beaucoup de commandes ont le même mot mais font des choses différentes.
Keyo
2

Mes arguments pour DVCS sont les suivants:

  • La ramification n'est pas rompue, ce qui réduit les frictions dans le développement des fonctionnalités et le maintien des correctifs des produits existants. La friction coûte de l'argent à temps.

  • Le passage à un système moderne attire mieux les développeurs de pointe, ce qui conduira à une culture de meilleurs produits, ce qui permettra à l'entreprise de vendre plus de produits.

  • Les validations hors réseau sont plus rapides , ce qui permet aux développeurs de s'engager souvent, ce qui conduit à une détection et une analyse fines des bogues.

Il s'agit essentiellement de réduire la friction. Il y a un terme pour cela: Muda . Plus il y a de friction, plus c'est douloureux de faire les choses. Plus il y a de douleur, moins on en fait, moins il y a de profits.

Paul Nathan
la source
2

Je m'excuse si je suis en règle, mais permettez-moi de présenter l'analyse de rentabilisation en termes non incertains:

SVN rend la vie des développeurs misérable . Et cela rend une entreprise de logiciels misérable.

... d'une manière que beaucoup ne réaliseront pas avant de commencer à utiliser un DVCS. Il s'agit de l'analyse de rentabilisation la plus importante qui puisse être faite . Pourquoi? Eh bien, comparé au coût de la recherche et de la conservation de bons développeurs, le coût du passage à un DVCS est presque inexistant .

Considérer ce qui suit:

  • Toutes les opérations, sauf les plus triviales, dans SVN (et la plupart des autres CVCS) nécessitent un accès réseau. Dans la plupart des DVCS, l'accès au réseau se produit uniquement lorsque vous effectuez une opération pushou pull. Cela signifie que les commandes non triviales sont lentes . Que faites-vous quand une commande prend une éternité? Je vais personnellement parcourir programmers.se ou hacker news en attendant. En termes simples, les DVCS permettent aux programmeurs de se concentrer sur ce qu'ils aiment: écrire les logiciels de l'entreprise .
  • SVN a un soutien pour la ramification de la même manière que les prisons ont un soutien pour laisser tomber votre savon sous la douche: vous pouvez le faire, mais quand vous le faites, vous vous faites baiser. Ainsi, SVN oblige vos développeurs à se battre constamment les uns contre les autres pour apporter des modifications .
  • Lorsque SVN est en panne, c'est en baisse. Il devient terriblement difficile pour les développeurs de faire leur travail s’ils peuvent le faire. Ainsi, SVN oblige vos développeurs à dépendre de votre infrastructure à 100% sans bogue .
  • De nos jours, git gagne rapidement en partage tandis que SVN la perd rapidement. S'il n'y a aucun avantage à utiliser DVCSes sur SVN, pourquoi la communauté de programmation évolue-t-elle aussi vite qu'elle le peut?

Qu'est-ce que tout cela représente? Je n'ai pas encore rencontré un développeur qui a donné un DVCS un essai honnête qui préférerait SVN par la suite. Si je pouvais faire encore une déclaration ennuyeuse et audacieuse, SVN est un "mal nécessaire" que les développeurs se forcent à utiliser. Git est un outil qui rend les développeurs plus productifs et plus heureux .

(Je dois souligner que les déclarations en gras sont celles sur lesquelles vous devez vous concentrer. Les autres fournissent simplement un contexte.)

Jason Baker
la source
5
-1 - vous êtes de grand standing et bien qu'il y ait une part de vérité dans ce que vous écrivez, il est tourné de manière négative au point de s'appuyer sur le FUD plutôt que sur une analyse raisonnée. SVN est-il lent? Seulement si le référentiel est vaste et le réseau glaciaire. SVN étant en panne m'empêche de travailler - euh, je ne me souviens pas qu'il soit en panne et NON car mon ordinateur ne dépend pas de l'existence du référentiel pour éditer / compiler / exécuter la source. La ramification et la fusion de SVN sont-elles médiocres? Wow les gens ont de courts souvenirs ... pourquoi le DVCS gagne-t-il en notoriété? Un méli-mélo de fonctionnalités - qui est amélioré - et, franchement, de mode.
Murph
1
@Murph - Qu'on le veuille ou non, les gens détestent le changement au point d'être torpides. Pour les convaincre de changer, vous devez les convaincre que le statu quo est rompu. Et il est cassé. Le FUD n'est mauvais que lorsqu'il n'y a aucune raison d'être craintif, incertain et douteux. En ce qui concerne la mindshare, je suis d'accord avec vous. Mais ce n'est pas vraiment le point. Il s'agit de savoir si les personnes qui prennent des décisions sont d'accord ou non. Et chaque manager que j'ai rencontré a été convaincu par cet argument (même s'il déteste le git).
Jason Baker
2
Je ne suis pas nécessairement en désaccord avec vous Jason suggérant simplement que vos arguments ne sont pas bien avancés. Plus précisément, je pense que vous exagérez pour l'effet et si vous vous faites prendre, vous avez tendance à perdre des points pour votre argument même si vous avez raison. (Sauf pour les points où vous vous trompez bien sûr ... (
:)
2
Tous vos points sont des opinions plutôt que des faits. J'énumérerais chacun mais il n'y a pas assez d'espace dans les commentaires. Que diriez-vous de répondre à nouveau sans la tribune?
Henry
1
@Henry - Programmers.se est destiné aux questions et réponses subjectives. Subjective == question d'opinion.
Jason Baker
1

La seule chose à laquelle je peux penser est que git fonctionne sans connexion réseau. Tout le reste est même souvent difficile à vendre aux utilisateurs techniques qui utilisent subersion ou perforce depuis un certain temps.

Brainlag
la source
2
Bien sûr, mais Subversion fonctionne également sans connexion réseau. (Ne pas commettre évidemment, mais les choses courantes comme obtenir des informations sur la copie de travail ou différer avec la révision de base fonctionnent toutes.)
j_random_hacker
@j_random_hacker: Le but d'un VCS est de suivre les changements de code. La validation des modifications de code de pistes. Si vous ne pouvez pas vous engager hors ligne, je dirais que votre VCS ne fonctionne pas en mode hors connexion.
Daenyth
1

La différence montre quand il y a des problèmes

Nous sommes passés à git il y a 6 mois après avoir porté notre dépôt vieux de dix ans.

Jusqu'à présent, j'ai trouvé ce qui suit, après un peu d'expérimentation:

  • ramification et fusion est presque indolore. Cela rend beaucoup plus facile de travailler sur des fonctionnalités distinctes et de corriger des bogues sans marcher les uns sur les autres. Cela facilite également l'application d'un correctif de bug donné ailleurs.

  • plus robuste par conception - vous ne comptez pas à 100% sur la disponibilité d'un serveur central, et si ce n'est pas le cas, vous pouvez utiliser la promotion de n'importe quel clone temporairement comme remplacement à chaud. Cela supprime un point de défaillance crucial - si le serveur SVN tombe en panne pour une raison quelconque, personne ne peut faire de travail SVN. Si le référentiel central git tombe en panne pour une raison quelconque, vous pouvez toujours travailler et pousser / tirer localement pour vous assurer que les validations sont répliquées. Vous pouvez même avoir plusieurs référentiels hors site à cet effet.

  • l'interaction du référentiel est simplifiée. Pour CVS, vous aviez essentiellement besoin d'un accès permanent à tout moment et à tout moment. Pour git, l'ensemble du référentiel est disponible localement, permettant à beaucoup de choses d'aller plus vite.

Ainsi, l'avantage n'est pas autant dans la routine quotidienne, mais est très clair au moment où vous avez quelque chose qui ne fonctionne pas correctement!

Par conséquent, je suggère que pour votre analyse de rentabilisation, regardez ce que vous ferez en cas de catastrophe ...


la source
C'est le même argument que pour les sauvegardes: vous n'en avez besoin qu'en cas de catastrophe. La question est de savoir ce que vous ferez quand ce sera le cas, et ce que vous accepterez alors.
0

La facilité de ramification et de fusion est la raison la plus concrète, mais pour convaincre quelqu'un, vous devrez lui donner un exemple concret de la façon dont cela améliore les choses.

Disons que vous avez quelques programmeurs qui travaillent sur l'amélioration des performances d'une application, et qu'ils sont au stade expérimental et ne savent pas si le code qu'ils écrivent fera jamais partie de la branche master / trunk. Cependant, ils doivent fréquemment partager du code entre eux et essayer des idées qui peuvent être des impasses. Comment gérez-vous des branchements et des fusions si fréquents en subversion? La réponse courte est que vous ne le faites pas. Avec un dvcs, c'est vraiment facile, et les programmeurs peuvent rapidement essayer de nouvelles idées dans les branches et partager avec les autres avant de décider si cette idée persistera.

jshen
la source
-1

L'analyse de rentabilisation pour l'abandon de SubVersion est que le support de branchement est un obstacle à la stabilisation et à la maintenance des produits. Si vous devez publier un produit puis poursuivre le développement, vous avez besoin d'une branche. Avec subversion, les développeurs n'utiliseront pas correctement les branchements, et donc vous ne pourrez pas continuer le développement sur le tunk, et vous assurer que les corrections de bugs arrivent réellement à la fois sur le tronc et la branche.

Michael Shaw
la source