Les développeurs bloqués en attendant la fusion du code d'une autre branche à l'aide de GitFlow

17

Notre équipe vient de passer de FogBugz & Kiln / Mercurial à Jira & Stash / Git. Nous utilisons le modèle Git Flow pour créer des branches, en ajoutant des branches de sous-tâches hors des branches de fonctionnalités (relatives aux sous-tâches Jira des fonctionnalités Jira). Nous utilisons Stash pour affecter un réviseur lorsque nous créons une demande d'extraction à fusionner de nouveau dans la branche parente (généralement développée mais pour les sous-tâches de nouveau dans la branche de fonctionnalité).

Le problème que nous constatons est que même avec la meilleure planification et répartition des cas de fonctionnalités, lorsque plusieurs développeurs travaillent ensemble sur la même fonctionnalité, par exemple sur le front-end et le back-end, s'ils travaillent sur du code interdépendant qui est dans des branches distinctes, un développeur finit par bloquer l'autre.

Nous avons essayé de tirer entre les branches les uns des autres au fur et à mesure de notre développement. Nous avons également essayé de créer des branches d'intégration locales que chaque développeur peut extraire de plusieurs branches pour tester l'intégration au fur et à mesure de leur développement. Enfin, et cela semble fonctionner le mieux pour nous jusqu'à présent, bien qu'avec un peu plus de frais généraux, nous avons essayé de créer une branche d'intégration à partir de la branche de fonctionnalité dès le départ. Lorsqu'une branche de sous-tâche (hors de la branche de fonctionnalité) est prête pour une demande d'extraction et une révision de code, nous fusionnons également manuellement ces ensembles de modifications dans cette branche d'intégration de fonctionnalité. Tous les développeurs intéressés peuvent alors passer de cette branche d'intégration à d'autres branches de sous-tâches dépendantes. Cela empêche quiconque d'attendre une branche dont il dépend pour passer l'examen du code.

Je sais que ce n'est pas nécessairement un problème Git - cela a à voir avec le travail sur du code interdépendant dans plusieurs branches, mélangé avec notre propre processus de travail et notre culture. Si nous n'avions pas la politique stricte de révision de code pour le développement (véritable branche d'intégration), le développeur 1 pourrait fusionner pour se développer pour le développeur 2. Une autre complication est que nous sommes également tenus de faire des tests préliminaires dans le cadre du processus de révision du code avant de remettre la fonctionnalité à QA, ce qui signifie que même si le développeur frontal 1 tire directement de la branche du développeur principal 2 car ils si le développeur principal 2 se termine et que sa demande d'extraction est en attente de révision de code pendant une semaine, le développeur frontal 2 ne peut techniquement pas créer sa demande d'extraction / révision de code car son réviseur de code ne peut pas tester car développeur back-end 2 '

En fin de compte, nous nous trouvons dans une approche beaucoup plus sérielle plutôt que parallèle dans ces cas, en fonction de la route que nous empruntons, et nous aimerions trouver un processus à utiliser pour éviter cela.

La dernière chose que je mentionnerai est que nous réalisons en partageant le code entre les branches qui n'ont pas été revues et finalisées, mais nous utilisons essentiellement le code bêta des autres. Dans une certaine mesure, je ne pense pas que nous puissions éviter cela et sommes prêts à l'accepter dans une certaine mesure.

git workflows branching jira gitflow loup de brume
la source
Je vérifie simplement - la révision du code est en cours lors de la fusion de la tâche avec la fonctionnalité? et il n'y a pas de révision de code sur la fusion des fonctionnalités à développer?
Ça dépend. Nous avons pour règle générale qu'aucun cas Jira qui correspond à une branche dans laquelle nous vérifions directement le code et qui n'agit pas comme un cas "parapluie" dans un sens hiérarchique ne prend plus de 2 jours. Donc, si un cas de fonctionnalité prend <= 2 jours, il y aura un examen du code pour fusionner la fonctionnalité à développer. S'il existe des sous-tâches, une fois qu'elles ont toutes été fusionnées dans leur ticket de fonctionnalité, quelqu'un observe la demande de tirage pour fusionner cette branche de fonctionnalité en développement, mais pas le même niveau de révision de code, car toutes les sous-tâches ont déjà suivi ce processus.
fogwolf

Réponses:

11

Le problème pourrait également résider dans une séparation trop rigide des tâches entre le développement principal et le développement frontal.

Si un développeur frontal a besoin d'une nouvelle API, n'est-il pas possible de lui permettre de créer une API factice sur le back-end (en renvoyant toujours la même valeur par exemple) pour valider la mise en page? Ensuite, validez cette implémentation partielle avec un stub, et dans un deuxième temps, un développeur principal implémentera la fonctionnalité réelle.

En brisant la dépendance, vous obtiendrez un meilleur flux et vous n'aurez pas tout arrêter en attendant une seule tâche qui agit comme un goulot d'étranglement.

Xavier T.
la source
J'y ai pensé, mais cela ne fait pas partie de notre processus de développement actuel et représente un surcoût supplémentaire. Je ne pense pas que le problème soit entièrement dû au fait que le développeur frontal ne puisse pas accéder au code du développeur principal à tester pendant le développement. Il s'agit davantage des réviseurs de code qui effectuent un test de fumée de l'intégralité de l'intégration (rien de moqué ou de tronqué) avant de l'envoyer à QA.
fogwolf
6
Bien que cela ne fasse pas partie de votre processus de développement, cela représente-t-il un surcoût supplémentaire que d'avoir deux développeurs se tordant les pouces pendant trois jours en attendant que quelqu'un d'autre valide son code? Vous avez 8 heures de temps de développeur perdues par twiddler. Comparez cela au temps nécessaire pour éliminer les dépendances de backend.
Greg Burghardt
5

Votre problème: les branches développeur A de Master, les branches développeur B de Master, fonctionnent toutes deux sur des fonctionnalités étroitement liées, et le fait inévitable que les fusions dans la branche Master sont difficiles à cause des conflits inévitables est ce qui retient tout le monde.

Si cela est prévisible, A et B pourraient d'abord créer une branche commune, puis chaque branche pour leur travail séparé de cette branche commune, fusionner chacun de leur travail séparé dans la branche commune, et maintenant vous avez une branche sans conflit qui est beaucoup plus facile à intégrer.

gnasher729
la source
0

Si le développeur 1 fonctionne sur la fonctionnalité A et que le développeur 2 a fini de travailler sur la fonctionnalité B qui dépend de la fonctionnalité A, il n'y a aucun moyen de contourner cela - la fusion de la fonctionnalité B est en attente. Vous ne pouvez pas le tester sans la fonctionnalité A, et il n'y a pas de raison de l'examiner pour le moment car des progrès supplémentaires dans la fonctionnalité A peuvent entraîner des modifications dans la fonctionnalité B.

Cela ne signifie cependant pas que le développeur 2 est en attente! Le développeur 2 peut commencer à travailler sur la fonctionnalité C et revenir au cycle de révision-correction de la fonctionnalité B une fois la fonctionnalité A terminée. Je sais que le changement de contexte n'est pas optimal, mais comme le temps qu'il faudra pour terminer la fonctionnalité A est probablement mesuré en jours, ce n'est pas si mal (vous ne les retirez pas de "The Zone" pour une tâche parallèle de 15 minutes)

Idan Arye
la source
Bien sûr, mais ce n'est pas tout à fait le problème. C'est plus pour une seule fonctionnalité que le processus devient un peu plus sérialisé qu'il ne doit l'être. Si nous prévoyons de publier une fonctionnalité le x date, et que les tickets ne peuvent pas être examinés en parallèle, cela entraîne la désactivation de nos estimations et pourrait entraîner la sortie de la version.
fogwolf
0

Une chose que vous pouvez faire pour remédier à la situation est d'examiner attentivement les moyens de raccourcir le cycle de développement.

Dans le cas où un développeur attend une fonctionnalité d'un autre développeur, existe-t-il un moyen pour qu'une partie des premiers développeurs puisse passer en revue et intégrer avant la fonctionnalité entière pour libérer le bloc?

Existe-t-il des moyens de diviser les fonctionnalités en unités de travail plus petites pour maintenir le cycle d'intégration?

De plus, combien de temps l'intégration prend-elle? S'il y a un long tour sur une construction ou une intégration, cela peut ralentir toute la file d'attente. Voyez s'il y a quelque chose que vous pouvez faire pour accélérer le temps de génération afin que les files d'attente soient libérées plus rapidement.

Steve Mitcham
la source
C'est ce que mes principaux espoirs sont. Je ne pense pas que nous puissions éliminer le problème, mais en me familiarisant avec le nouveau flux de travail, j'espère que nous améliorerons la planification et la décomposition de notre travail en collaboration au sein de ce nouveau système afin de minimiser le problème. Je vérifiais simplement si quelqu'un avait rencontré quelque chose de similaire, cependant, et avait quelque chose de processus ou lié au modèle de branchement que nous utilisons qui pourrait aider. Merci.
fogwolf