Mon entreprise fusionne-t-elle ses succursales?


28

J'ai récemment rencontré un article MSDN sur la ramification et la fusion et SCM: Branching and Merging Primer - Chris Birmele .

Dans l'article, ils disent que la fusion du big bang est un contre-modèle fusionnant:

Big Bang Merge - reporter la fusion des branches à la fin de l'effort de développement et tenter de fusionner toutes les branches simultanément.

J'ai réalisé que cela est très similaire à ce que mon entreprise fait avec toutes les branches de développement qui sont produites.

Je travaille dans une très petite entreprise avec une personne agissant en tant qu'autorité de révision finale + fusion de tronc. Nous avons 5 développeurs (dont moi), chacun de nous se verra assigner une tâche / bogue / projet distinct et nous dériverons chacun du tronc actuel (subversion) et ensuite effectuerons le travail de développement dans notre branche, testons les résultats, rédiger la documentation si nécessaire, effectuez une revue par les pairs et une boucle de rétroaction avec les autres développeurs, puis soumettez la branche pour révision + fusion sur notre logiciel de gestion de projet.

Mon patron, la seule autorité sur le référentiel de troncs, reportera en fait toutes les révisions des branches jusqu'à un seul moment où il effectuera des révisions autant que possible, certaines branches seront renvoyées pour des améliorations / corrections, certaines les branches fusionneront directement dans le tronc, certaines branches seront rejetées en raison de conflits, etc.

Il n'est pas rare que nous ayons 10 à 20 succursales actives dans la file d'attente finale pour être fusionnées dans le tronc.

Nous devons également fréquemment résoudre les conflits lors de la phase finale de révision et de fusion, car deux branches ont été créées à partir du même tronc mais ont modifié le même morceau de code. Habituellement, nous évitons cela en rebranchant simplement le tronc et en réappliquant nos modifications et en résolvant les conflits, puis en soumettant la nouvelle branche pour révision (pauvre homme rebase).

Voici quelques questions directes que j'ai:

  • Présentons-nous le très anti-modèle qui a été décrit comme la «fusion du big bang»?
  • Certains des problèmes que nous constatons sont-ils le résultat de ce processus de fusion?
  • Comment pouvons-nous améliorer ce processus de fusion sans augmenter le goulot d'étranglement sur mon patron?

Edit: je doute que mon patron desserre son emprise sur le référentiel de coffre, ou permette à d'autres développeurs de fusionner dans le coffre. Je ne sais pas quelles sont ses raisons, mais je n'ai pas vraiment l'intention de soulever le sujet parce qu'il a déjà été soulevé et abattu assez rapidement. Je pense qu'ils ne nous font tout simplement pas confiance, ce qui n'a pas de sens car tout est suivi de toute façon.

Tout autre aperçu de cette situation serait apprécié.


2
Pourquoi la fusion est-elle différée? Habituellement, il y a une raison pour ne pas le faire immédiatement. le célibataire est-il surmené et l'arriéré devient tellement gros? y a-t-il une autre raison pour laquelle la fusion ne se fait pas en temps opportun?
Polygnome

1
J'étais dans une position similaire à vous, plusieurs fois. Je peux dire par expérience personnelle que de nombreuses entreprises font du contrôle de version, en particulier des succursales, horriblement mal.
MechMK1

3
Que se passe-t-il lorsque le patron part en vacances?
Liath

Comment définiriez-vous la stratégie de branchement / fusion du noyau Linux?
Braiam

Les modifications qui sont annulées en raison de conflits mais pas d'autres défauts doivent-elles être soumises à nouveau au processus d'approbation une fois les conflits résolus ou sont-ils considérés comme "provisoirement approuvés"?
Gregory Nisbet

Réponses:


60

Quelques suggestions:

  • Il n'y a rien de mal à avoir beaucoup de branches de fonctionnalités ou de corrections de bogues tant que les modifications effectuées dans chaque branche sont suffisamment petites, vous pouvez toujours gérer les conflits de fusion résultants de manière efficace. Cela devrait être votre critère si votre façon de travailler est correcte, pas un article MSDN.

  • Chaque fois qu'une branche est fusionnée en tronc, le tronc doit être fusionné dans toutes les branches de développement ouvertes dès que possible. Cela permettrait à tous les membres de l'équipe de résoudre les conflits de fusion en parallèle dans leur propre branche et ainsi de décharger le gardien du coffre.

  • Cela fonctionnerait beaucoup mieux si le portier n'attendait pas que 10 branches soient "prêtes à fusionner dans le tronc" - la résolution des conflits de fusion des dernières intégrations de tronc a toujours besoin de temps pour l'équipe, il est donc probablement préférable de travailler dans des intervalles de temps entrelacés. - une intégration par le portier, une nouvelle fusion par l'équipe, une prochaine intégration par le portier, une nouvelle fusion par l'équipe, etc.

  • Pour garder les branches petites, il peut être utile de diviser des fonctionnalités plus grandes en plusieurs tâches plus petites et de développer chacune de ces tâches dans une branche qui lui est propre. Si la fonctionnalité n'est pas prête pour la production tant que toutes les sous-tâches ne sont pas implémentées, masquez-la de la production derrière une bascule de fonctionnalité jusqu'à ce que toutes les sous-tâches soient terminées.

  • Tôt ou tard, vous rencontrerez des tâches de refactorisation qui affectent de nombreux fichiers dans la base de code - celles-ci ont un risque élevé de provoquer de nombreux conflits de fusion avec de nombreuses branches. Ceux-ci peuvent être mieux gérés en les communiquant clairement dans l'équipe, et assurez-vous de les gérer exactement comme je l'ai écrit ci-dessus: en les intégrant d'abord dans toutes les branches de développement avant la réintégration, et en les divisant en sous-refactorings plus petits.

  • Pour la taille de votre équipe actuelle, avoir un seul gardien peut toujours fonctionner. Mais si votre équipe grandit, il n'y a aucun moyen d'avoir un deuxième gardien (ou plus). Remarque Je ne suggère pas de permettre à tout le monde de fusionner dans le coffre, mais cela ne signifie pas que seul votre patron est capable de le faire. Il y a probablement un ou deux développeurs seniors qui pourraient également être candidats pour faire le travail de gardien. Et même pour la taille de votre équipe actuelle, un deuxième contrôleur d'accès pourrait faciliter l'intégration de votre équipe au tronc plus souvent et plus tôt, ou lorsque votre patron n'est pas disponible.


2
Je pense que vous avez le meilleur commentaire ici, reconnaissant que nous ne pouvons pas simplement ouvrir le coffre à tout le monde et que notre pile de succursales n'est pas toujours un problème (uniquement en cas de conflit). Je pense que vous avez fait du bon travail en montrant comment nous pouvons réduire les conflits et assurer le bon déroulement du cycle de fusion.Je pense également que vous avez tout à fait raison lorsque vous dites que nous pourrions avoir besoin d'un autre contrôleur d'accès. Merci beaucoup pour cet aperçu!
user6567423

@ user6567423 Une autre chose que vous voudrez peut-être envisager est de créer des branches pour chaque version de développement (par exemple 5.2.3 ou autre), que chaque développeur peut dériver pour le travail de fonctionnalité puis fusionner, et qui peuvent ensuite être fusionnées à nouveau sur le principal libérer la branche par le patron lorsque le développement est terminé.
nick012000

@ nick012000: cette suggestion ne rendrait-elle pas plus difficile pour le contrôleur d'accès d'accepter ou de rejeter des branches de fonctionnalités individuelles pour / contre l'intégration dans le tronc? Je veux dire, si plusieurs fonctionnalités sont mélangées dans une branche de développement, la réintégration de ces changements en partie dans le tronc deviendrait vraiment difficile. Ou est-ce que je manque quelque chose?
Doc Brown

10
" résoudre les conflits de fusion en parallèle dans leur propre branche et ainsi prendre un peu de charge au portier du coffre. " - J'ai l'impression que cette partie est injustement réduite à une note secondaire. "C'est mieux pour l'entreprise MAIS AUSSI plus facile pour vous " semble être le principal argument de vente en suggérant cela au patron. Cela va plus dans la politique du bureau de direction, dont SE ne parle pas - mais dans cette situation, sans l'adhésion du patron, tout le reste de cette excellente réponse technique ne se produira tout simplement pas.
R. Schmitz

@DocBrown Oui, ce serait le cas, mais cela signifierait également que vous auriez beaucoup moins de conflits entre les branches de développement et cela vous donnerait toujours le degré de sécurité donné en ne fusionnant pas directement sur la branche principale - et il peut simplement refuser d'accepter le travail comme terminé et d'effectuer la fusion jusqu'à ce qu'il soit satisfait de l'état du code dans son ensemble.
nick012000

18

Présentons-nous le très anti-modèle qui a été décrit comme la «fusion du big bang»?

Ça sonne comme ça.

Certains des problèmes que nous constatons sont-ils le résultat de ce processus de fusion?

Absolument

Comment pouvons-nous améliorer ce processus de fusion sans augmenter le goulot d'étranglement sur mon patron?

Dans mon entreprise, chaque développeur a la possibilité de fusionner. Nous attribuons une demande de fusion à un autre développeur, passons par le cycle de révision / rétroaction / mise à jour jusqu'à ce que les deux parties soient satisfaites. Ensuite, le réviseur fusionne le code.

10 à 20 succursales en attente de fusion indiquent que votre processus est défectueux. Si nous en avions autant, tout le travail de développement s'arrêterait jusqu'à ce qu'il soit clarifié.


1
Ce n'est pas la réponse que je cherchais, car je doute que mon patron va desserrer son emprise sur le référentiel de coffre. Mais une réponse incroyablement utile néanmoins, merci pour la perspicacité!
user6567423

5
@ user6567423: Si votre patron devient le goulot d'étranglement, ce qu'il est maintenant selon votre description, il devra soit changer son approche, soit accepter qu'il est à l'origine de retards (ce dont ses employés ne peuvent alors pas être blâmés). Refuser de changer votre approche, ignorer les problèmes que vous créez et rejeter la faute sur les autres n'est pas un moyen de gérer une entreprise.
Flater

1
Il reconnaît qu'il est le goulot d'étranglement et il n'en blâme certainement pas les autres. Mais oui, je cherchais des astuces qui pourraient ne pas être évidentes et qui pourraient éventuellement réduire notre goulot d'étranglement. Merci pour la perspicacité
user6567423

1
@ user6567423 Je suis curieux de savoir s'il a déjà expliqué pourquoi il est le seul à pouvoir fusionner avec le tronc.
Matthew

13

C'est essentiellement ainsi que fonctionnent de nombreux projets open source, notamment le noyau Linux, qui a beaucoup plus de branches en vol que vous n'en avez à un moment donné. La manière typique d'éviter les fusions soudaines dans ces projets est de créer une autre branche (ou plusieurs branches) pour une intégration continue. Il s'agit de la branche que vous utilisez pour vous assurer que vos modifications fonctionnent avec vos collègues, et elle est périodiquement rebasée sur le coffre lorsque le contrôleur d'accès se déplace pour effectuer des révisions.

En option, vous pouvez utiliser cette branche pour combiner plusieurs de vos propres demandes d'extraction en une seule grande demande cohérente que votre patron doit examiner. Linus Torvalds reçoit généralement des demandes d'extraction qui ont été intégrées à deux niveaux ou plus, et peuvent avoir une taille de l'ordre, par exemple, d'un nouveau pilote de système de fichiers complet.


Merci, je pense que les conseils sur la combinaison des branches et la prévention des conflits seront probablement notre meilleur plan d'action.
user6567423

8

Je suis d'accord avec Doc Brown mais je vois aussi un autre motif:

Mon patron, la seule autorité sur le référentiel de troncs , reportera en fait toutes les révisions des branches jusqu'à un seul moment où il effectuera des révisions autant que possible, certaines branches seront renvoyées pour des améliorations / corrections, certaines les branches fusionneront directement dans le tronc, certaines branches seront rejetées en raison de conflits , etc.

Dans mon humble il y a quelques patrons de gestion:

  1. Il / elle est le point d'étranglement unique contraignant la vitesse de l'équipe. Votre facteur de bus est 1. La théorie des contraintes dit que vous devez vous efforcer d'améliorer la partie la plus lente de la chaîne.
  2. Votre manager ralentit votre cycle de feedback et réduit l'agilité de votre équipe. Pouvez-vous sortir chaque semaine?
  3. La complexité des fusions croît de façon exponentielle avec la quantité de code. Il vaut mieux faire 10 fusions avec 100 lignes que 1 de 1000 lignes. Ce n'est qu'une des raisons pour lesquelles vous devriez le faire dès que possible
  4. Si vous détectez une défaillance dans le coffre, vous le ferez à temps. Laquelle des différentes branches a posé problème
  5. Les décisions devraient être prises par ceux qui ont plus de connaissances à leur sujet. Qui en sait plus dans ce cas? Je parie que les développeurs qui ont fait le code.
  6. Vous ne pouvez pas corriger un bug en production si votre manager est en vacances.
  7. Vous refaites du travail et rejetez des branches. C'est une perte de temps. Le temps qu'il attend pour atteindre la production est également un gaspillage.

Recommandations:

  • Votre manager doit déléguer la responsabilité à l'équipe. Vous devez montrer que l'équipe est mature et professionnelle. Expliquez clairement qu'ils peuvent faire confiance à l'équipe
  • Mettez en œuvre une méthode de révision. Peut-être avez-vous besoin de l'approbation de deux autres membres de l'équipe.
  • L'utilisation de SVN complique la tâche. Essayez Git et voyez si cela vous aide. Encore plus. Si vous utilisez GitHub, vous pouvez utiliser le mécanisme de demande d'extraction afin qu'une fusion nécessite certains votes.
  • Lisez et partagez des informations sur les pratiques agiles, l'intégration continue et les DevOps.

7
J'ai travaillé professionnellement à la fois avec SVN et git, et je dirais que SVN fait définitivement partie du problème: il impose une politique de fusion-retour unique sur les branches qui n'est pas présente dans git. Dans git, toutes les fusions sont égales, dans SVN, certaines sont plus égales que d'autres. En outre, le manque de commits locaux rend beaucoup plus difficile l'expérimentation avec SVN qu'avec git, et l'absence d'une zone de stadification ne fait qu'ajouter à l'inflexibilité de SVN. Il y a une raison pour laquelle Torvalds n'a pas simplement utilisé SVN au lieu de développer git ...
cmaster

Git est tellement mieux que svn à mon avis pour les raisons @cmaster énoncées et plus
reggaeguitar

Je suis d'accord que git résoudrait probablement certains de nos problèmes de fusion, et bon dieu, j'aimerais avoir un rebase disponible. Mais je ne pense pas que nous allons faire le changement de sitôt :(
user6567423

1
@ user6567423, j'ai fait une consultation l'année dernière où j'ai aidé une petite équipe à passer de svn à Git et à changer leur flux de travail, y compris en les formant sur Git et en les configurant avec GitLab Community Edition (qui est open source) pour les révisions de code et la collaboration . Ils en étaient très enthousiastes; c'était une différence de jour et de nuit. (De plus, cela n'a pris que trois jours.)
Wildcard

2

Lorsque vous travaillez sur des fonctionnalités dans des branches distinctes, vous ne pouvez pas facilement effectuer de test d'intégration jusqu'à ce que l'une des branches soit fusionnée dans le tronc et tirée dans les autres branches de fonctionnalité. D'après mon expérience, c'est le principal problème avec l'anti-motif Big Bang Merge. Idéalement, vous feriez un travail de fonctionnalité, le testeriez dans la branche de fonctionnalité, le fusionneriez dans le tronc, et à ce stade, vous en auriez fini avec la fonctionnalité. S'il n'a pas été fusionné, vous devez le revoir à chaque fois que quelque chose d'autre est fusionné dans le tronc avant. La douleur de cet anti-modèle est que vous avez beaucoup de bogues de type intégration qui apparaissent à la fin du cycle de développement.


1

Vous avez donc 20 succursales. La branche 1 vient d'être fusionnée. Ensuite, le développeur de la branche 2 doit fusionner la branche 1 dans sa branche pour pouvoir fusionner en principal sans conflit, puis fusionne. Ensuite, le développeur de la branche 3 doit fusionner la branche 1 et la branche 2 dans leur branche pour pouvoir fusionner en principal sans conflit, puis fusionne.

Exercice pour le lecteur: écrivez un programme qui imprime mon message complet :-)

C'est de la folie. Vous passerez un temps incroyable à fusionner.


Eh bien pas nécessairement, à moins que les branches ne soient en conflit, il peut simplement les fusionner toutes en tronc de façon transparente. Nous essaierons généralement d'empêcher tout conflit en effectuant un test de fusion avant de soumettre la branche pour examen, mais les conflits surviennent inévitablement à mesure que le nombre de branches dans la file d'attente augmente. Je suis d'accord pour dire que cela ressemble à de la folie.
user6567423

2
Comportement de fusion SVN normal, pour autant que je
sache

0

Compte tenu de la façon dont vous travaillez et du fait que votre patron est un maniaque du contrôle responsable, la ramification elle-même semble être le problème. Plutôt que de créer une branche pour chaque fonctionnalité, demandez à chaque développeur de valider sa fonctionnalité en plusieurs parties, directement dans le tronc. Cela met le fardeau de l'intégration sur le développeur en plusieurs étapes plus petites (gagnant-gagnant). Gate keeper peut suivre le suivi des modifications plus petites sur une période plus longue plus tôt dans le cycle de développement et être toujours le réviseur principal.

La ramification elle-même est quelque chose que vous ne voulez pas faire sauf si vous avez une très bonne raison de le faire ou si vous n'avez pas d'autre option. Vous êtes assez petit pour maintenir la synchronisation plus étroitement, ce qui sera plus facile et plus sûr.


1
Et comment allez-vous gérer la version si une seule de ces fonctionnalités présente un bogue ou n'est pas terminée à temps? "La branche elle-même est quelque chose que vous ne voulez pas faire à moins d'avoir une très bonne raison de le faire" - Une fois que vous avez 5 personnes travaillant sur plusieurs fonctionnalités chacune, vous devez utiliser la branche à moins d'avoir une très bonne raison de ne pas le faire.
Ivo van der Veeken

Il s'agissait de deux choses: le patron veut rester le seul et unique gardien et les choses ne sont pas censées trop diverger. Oui, il y aura un moment où quelque chose a été poussé qui n'a pas encore été examiné par le patron. Il devrait cependant être en mesure de le faire rapidement et, dans le cas peu probable où il devrait livrer immédiatement, il peut revenir sur les derniers commits. Cela gardera les choses synchronisées et si vous échouez à quelque chose, vous échouerez certainement rapidement. Cela me semble être un bon compromis pour la situation actuelle.
Martin Maat

1
Je considérerais cela comme un dernier recours
reggaeguitar
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.