Mon entreprise fusionne-t-elle ses succursales?

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é.

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.

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é.

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.

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.

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.

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.

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.