Des maux de tête à l'aide du contrôle de version distribué pour les équipes traditionnelles?

Bien que j'utilise et aime le DVCS pour mes projets personnels, et que je puisse totalement voir comment cela facilite la gestion des contributions à votre projet par d'autres (par exemple, votre scénario Github typique), il semble que pour une équipe "traditionnelle", il pourrait y avoir des problèmes approche centralisée employée par des solutions comme TFS, Perforce, etc. (Par «traditionnel», j'entends une équipe de développeurs dans un bureau travaillant sur un projet que personne ne «possède», avec potentiellement tout le monde touchant le même code.)

Quelques-uns de ces problèmes que j'ai prévus par moi-même, mais veuillez apporter d'autres considérations.

Dans un système traditionnel, lorsque vous essayez de vérifier votre modification sur le serveur, si quelqu'un d'autre a précédemment consigné une modification conflictuelle, vous êtes obligé de fusionner avant de pouvoir enregistrer la vôtre. Dans le modèle DVCS, chaque développeur vérifie sa change localement et à un moment donné pousse à un autre dépôt. Ce dépôt a alors une branche de ce fichier que 2 personnes ont changé. Il semble que maintenant quelqu'un doit être chargé de faire face à cette situation. Une personne désignée dans l'équipe peut ne pas avoir une connaissance suffisante de l'intégralité de la base de code pour pouvoir gérer la fusion de tous les conflits. Alors maintenant, une étape supplémentaire a été ajoutée où quelqu'un doit approcher l'un de ces développeurs, lui dire de tirer et de faire la fusion, puis de pousser à nouveau (ou vous devez construire une infrastructure qui automatise cette tâche).

De plus, comme DVCS a tendance à rendre le travail local si pratique, il est probable que les développeurs puissent accumuler quelques modifications dans leurs dépôts locaux avant de les pousser, ce qui rend ces conflits plus courants et plus compliqués.

Évidemment, si tout le monde dans l'équipe ne travaille que sur différentes zones du code, ce n'est pas un problème. Mais je suis curieux de savoir si tout le monde travaille sur le même code. Il semble que le modèle centralisé oblige les conflits à être traités rapidement et fréquemment, minimisant ainsi la nécessité de procéder à des fusions importantes et douloureuses ou de confier à quiconque le contrôle du référentiel principal.

Donc, pour ceux d'entre vous qui utilisent un DVCS avec votre équipe dans votre bureau, comment gérez-vous de tels cas? Trouvez-vous que votre flux de travail quotidien (ou plus probablement hebdomadaire) est affecté négativement? Y a-t-il d'autres considérations à prendre en compte avant de recommander un DVCS sur mon lieu de travail?

Nous utilisons Mercurial depuis environ un an. Bien que le casse-tête que vous mentionnez existe, de loin, le plus grand défi pour une adoption complète pour nous était d'entrer dans l'état d'esprit DVCS des référentiels locaux (= commit souvent.) aller.

Tu as dit:

Dans le modèle DVCS, chaque développeur vérifie ses modifications localement et à un moment donné pousse vers un autre référentiel. Ce dépôt a alors une branche de ce fichier que 2 personnes ont changé. Il semble que maintenant quelqu'un doit être chargé de faire face à cette situation.

Une installation par défaut de Mercurial bloque ce comportement. Il ne permettra pas une poussée si plus d'une tête sera créée dans le référentiel distant, sans confirmation supplémentaire. Pour les activités quotidiennes, nous évitons cela. (Git a nommé des têtes et chacune ne peut être mise à jour que si elle fusionne complètement la version précédente, sans confirmation supplémentaire, donc encore une fois la situation ne peut pas se produire. Les autres DVCS ont également une protection similaire.)

Donc, à la fin de chaque journée de travail, un certain temps doit être réservé pour la validation, qui est vraiment ces activités:

1. Validez les modifications locales.
2. Tirez du dépôt central.
3. Fusionner (& valider la fusion.)
4. Poussez vers le référentiel central.

Cela conserve l'activité de fusion sur une personne qui travaillait récemment sur ce code et devrait pouvoir intégrer leurs modifications aussi rapidement que n'importe qui d'autre.

Comme indiqué dans la question, cela n'ajoute vraiment d'effort que lorsque deux personnes travaillent sur le même domaine de code. Si tel est le cas, l'utilisation de DVCS présente de toute façon plus d'avantages, de sorte que le gain est déjà évident pour ces développeurs. (Les avantages supplémentaires incluent que chaque développeur puisse valider séparément le code et jouer avec son propre référentiel sans qu'un autre développeur ne gêne.)

Un autre problème que vous mentionnez:

De plus, comme DVCS a tendance à rendre le travail local si pratique, il est probable que les développeurs puissent accumuler quelques modifications dans leurs dépôts locaux avant de les pousser, ce qui rend ces conflits plus courants et plus compliqués.

Cela ne crée pas de problème de fusion pour nous, mais pourrait créer un problème différent:

La flexibilité du DVCS signifie que de nombreux flux de travail différents sont possibles, mais certains d'entre eux sont irresponsables. Avec DVCS, le besoin de processus ou de procédures clairs augmente. L'activité consistant à conserver les changements locaux peut être appropriée ou non, selon de nombreuses choses.

Par exemple: un développeur peut-il travailler sur une fonction d'animal de compagnie pendant des temps libres sur quelques semaines? Dans certains environnements, cela est encouragé, dans certains, ce serait inapproprié et tous les changements devraient être centralisés rapidement. Mais si un développeur conserve les modifications localement, il voudra certainement retirer toutes les modifications connexes pour s'assurer que son travail continuera à bien fonctionner avec la dernière version commune.

Lorsque le caoutchouc rencontre la route, les versions ou déploiements de logiciels proviennent généralement d'un référentiel central, les développeurs doivent donc y apporter leurs modifications pour les tests et le déploiement.

C'est mon histoire, et je m'y tiens, pendant au moins quelques minutes ...

La prémisse de votre question semble être autour de "Les fusions sont difficiles et doivent être évitées". Les systèmes DVCS éliminent cette barrière, en fait ils en font plus, ils embrassent l'idée de fusionner - vous ne devriez pas avoir peur des fusions et des conflits de fusion en conséquence, car contrairement aux outils centralisés, les outils DVCS le soutiennent par conception.

Comme l'exprime l'excellente réponse de Jamie F - Le flux de travail de Commit-Pull-Merge-Push fait régulièrement (quotidiennement) signifie que si vous marchez sur certains travaux d'autrefois, vous le voyez tôt - tant qu'il est visible, il peut être géré .

Les problèmes que vous décrivez concernent davantage la façon dont vous choisissez d'utiliser les outils.

Nous sommes passés de SVN à GIT il y a 6 mois, après avoir utilisé SVN et GIT localement pendant quelques années. Personne ne reviendra en arrière et les douloureux conflits de fusion appartiennent au passé. Le mantra «Commettre petit et souvent» est la clé.

Lorsque je travaillais dans une équipe qui utilisait git, la règle générale était la suivante: travailler sur une branche privée, puis, lorsque vous êtes prêt à mettre votre travail à la disposition du reste de l'équipe, rebasez votre branche sur master avant de pousser. (Validez ensuite votre agence.)

Cette stratégie signifiait que master était une série de validations linéaires et que tous les problèmes d'intégration étaient résolus sur les succursales avant leur publication.

Un outil comme SVN encourage fortement une manière de travailler étroitement intégrée.

C'est-à-dire que vous vous engagez fréquemment dans une branche partagée (tronc ou branche de développement).

C'est A-OK pour la plupart des environnements de développement d'entreprise que j'ai connus, et est facilité et encouragé encore plus grâce à l'utilisation de l'intégration continue soutenue par des tests d'intégration, des tests de régression et des tests unitaires étendus (aider les développeurs individuels à avoir confiance qu'ils n'ont pas rompu quoi que ce soit par leurs changements).

DVCS vous donne la liberté de travailler de manière plus indépendante, dont vous avez besoin dans certaines situations, et la prise en charge améliorée (tant vantée) des fusions ne peut faire aucun mal.

L'inquiétude qui persiste toujours dans mon esprit est la suivante: avec une grande liberté vient la tentation d'utiliser cette liberté.

Certes, dans mon expérience (limitée), je passe beaucoup plus de temps à travailler de manière indépendante dans mon équipe actuelle (en utilisant Mercurial) que dans les rôles précédents (où nous avons utilisé SVN, CVS et P4).

Cela n'est que partiellement attribuable à l'outil, mais je pense que c'est une observation raisonnable de dire qu'en l'absence d'une raison impérieuse de consacrer des efforts à la communication et à la coordination, les gens auront tendance à travailler séparément et isolément.

Ce n'est pas nécessairement une mauvaise chose, mais je pense que c'est quelque chose qui doit être pris en considération.

La chose avec le contrôle de version de type git / mercurial, est de valider souvent et de pousser vers le serveur centralisé lorsque le code est bon. Un gros avantage avec cela est qu'il crée de petits correctifs, qui sont faciles à appliquer en cas de conflits. En outre, votre flux de travail devrait être quelque chose comme:

1. Beaucoup d'engagement local
2. Extraire du serveur
3. Envoyer au serveur

Cette extraction du serveur peut créer des conflits, mais pour résoudre ce problème, il suffit souvent de rebaser simplement, au lieu d'une fusion. Je pense que cela gardera l'historique du réseau principal assez propre et supprimera un grand nombre de conflits.

C'est également le cas lorsque vous retirez du dépôt local d'un collègue, car deux choses peuvent se produire. Soit il pousse d'abord vers le serveur, ce qui est bien puisque vous avez déjà ses correctifs, et aucun conflit ne devrait se produire, soit vous poussez d'abord, ce qui signifie qu'il n'obtiendra vos correctifs que lorsqu'il tirera.

Bien sûr, parfois une fusion est une meilleure solution, par exemple si vous travaillez sur une branche de fonctionnalité qui devrait être fusionnée dans master.

Dans votre flux de travail, vous parlez de personnes qui doivent explicitement aller vers un autre développeur et lui dire de résoudre le conflit, mais cela ne devrait pas être nécessaire. Le serveur central est le "boss", et ce contre quoi vous devriez principalement travailler. Si vos modifications s'appliquent au référentiel central, alors ça va. Sinon, c'est VOTRE travail de résoudre le conflit, ce qui pourrait nécessiter que le développeur avec lequel vous êtes en conflit vous aide à comprendre ses modifications. C'est quelque chose que vous voyez lorsque vous essayez de tirer / rebaser du serveur. Soyez donc heureux de vous engager et de gérer les conflits lorsque vous devez vous retirer du serveur.

Le principe de travailler avec un référentiel centralisé est le même lorsque vous travaillez avec un système centralisé ou distribué non verrouillable:

• Dans un système centralisé, vous:
  1. Obtenez la dernière version de mainline ("trunk" en subversion, "master" en git, ...)
  2. Modifier les fichiers
  3. Fusionner les modifications avec la dernière version de la ligne principale en utilisant la commande "update"
  4. S'engager sur la ligne principale
• Dans un système distribué, vous:
  1. Obtenez la dernière version de mainline
  2. Modifier les fichiers
  3. S'engager localement
  4. Fusionnez les modifications avec la dernière version de la ligne principale et validez le résultat localement
  5. Poussez vers la ligne principale.

Aucune version distribuée ne vous permettra de pousser la révision qui ne fusionne pas complètement la révision de tête précédente (sans remplacement spécial; parfois c'est utile), donc elle ne passera pas sans faire l'étape de fusion (donc il n'y aura pas deux versions quelqu'un devrait consolider comme vous le souhaitez).

Notez maintenant que quatre des étapes sont les mêmes, sauf pour la terminologie, mais les systèmes distribués ajoutent une étape supplémentaire "3. Valider localement". Le gros avantage de cette étape est que lorsque la mise à jour / extraction crée des conflits et que vous ne savez pas comment les résoudre ou commettre une erreur en les résolvant, vous pouvez revenir en arrière, revoir ce que vous avez fait et refaire la fusion. Subversion ne s'en souviendra pas, donc si vous faites une erreur de résolution de mise à jour, vous êtes foutu.

Quant à l'accumulation des changements, les gens ont tendance à le faire aussi avec le système centralisé. Surtout si vous devez souvent basculer entre les fonctionnalités (comme interrompre un travail plus long pour corriger un bogue ou faire quelques ajustements dont le client a un besoin urgent), les gens devront souvent conserver les modifications localement simplement parce qu'elles ne sont pas terminées. Il est donc préférable que le système prenne au moins en charge le sens.

Dans les deux cas, ces problèmes doivent être traités par des directives et une communication appropriées au sein de l'équipe et non par les outils. Avec des outils plus flexibles, les directives sont plus importantes, mais les outils plus flexibles permettent de mieux traiter divers cas d'angle.