Stratégie de branchement Git pour le code non publié de longue durée
Dans notre équipe, en plus des unités de travail individuelles (Histoires), nous avons des thèmes de travail plus longs (Epics). Plusieurs histoires font une épopée.
Traditionnellement, nous avons eu des branches de fonctionnalités pour chaque histoire, et avons fusionné celles-ci directement à maîtriser lorsqu'elles passent le contrôle qualité. Cependant, nous aimerions commencer à retarder la sortie des histoires terminées dans une épopée jusqu'à ce que l'épopée soit considérée comme "fonctionnalité terminée". Nous ne publierions ces fonctionnalités en production que lorsque Epic serait fermé. De plus, nous avons un serveur de construction nocturne - nous aimerions que toutes les histoires fermées (y compris celles qui font partie d'Epics incomplètes) soient déployées automatiquement sur ce serveur nocturne.
Y a-t-il des suggestions sur la façon de gérer notre repo pour y parvenir? J'ai envisagé d'introduire des "branches épiques", où nous fusionnions des histoires fermées à la branche épique connexe au lieu de les diriger directement vers le maître, mais mes préoccupations sont les suivantes:
- Je m'inquiète des conflits de fusion qui peuvent survenir si les branches épiques restent ouvertes longtemps
- Les constructions nocturnes nécessiteraient de fusionner toutes les branches épiques en une branche "nocturne". Encore une fois, des conflits de fusion peuvent survenir, et cela doit être fait automatiquement
Suggestion simple: ne faites pas ça.
les branches git ne sont pas pour les fourches à long terme du code, comme indiqué ici et https://blog.newrelic.com/2012/11/14/long-running-branches- considéré comme nuisible / . Les succursales sont mieux traitées comme des éléments transitoires utilisés pour organiser les validations par un développeur individuel au niveau quotidien. Donc, s'ils ont un nom qui correspond à quelque chose qu'un gestionnaire de projet (sans parler de l'utilisateur final) pourrait se soucier de vous, vous faites quelque chose de mal.
La pratique recommandée consiste à utiliser une intégration continue avec bascule de fonction ou branche par abstraction pour garantir que:
- tout le code est intégré à tout moment (au moins tous les jours, de préférence plus souvent)
- ce qui est déployé est sous contrôle explicite.
C'est un problème délicat mais auquel beaucoup de gens sont confrontés. Je préfère utiliser la configuration Gitflow comme point de départ.
Développement -> De nouvelles choses en cours d'élaboration
Master -> Trucs finis nécessitant des tests Production -> Trucs qui ont été publiés en production.
Pour les fonctionnalités mineures (plus courtes), je crée une branche à partir du développement, je fais le travail, puis je fusionne la branche au développement.
Pour les fonctionnalités principales (à long terme), je crée une branche à partir du développement, je crée des branches plus petites à partir de cette branche, puis je fusionne de nouveau avec la première branche. Une fois que la fonctionnalité principale est terminée, elle revient dans la branche de développement.
À intervalles réguliers (selon le projet), je fusionne à nouveau le développement dans le maître et un cycle de test commence. Si des correctifs surviennent lors des tests, ils sont effectués dans la branche principale (sous-branche puis fusionnez). Et le développement peut continuer sur la branche principale pendant les tests.
À tout moment, le maître doit être fusionné avec le développement, et le développement doit être fusionné avec l'une de ses sous-branches à long terme.
le maître doit toujours (en théorie) être prêt pour la production. Le développement doit toujours (en théorie) être prêt pour la production. La seule raison pour laquelle il existe une différence est de fournir un ensemble solide de fonctionnalités aux testeurs.
Une fois prêt, une validation dans le maître qui est testée est fusionnée dans la production et le déploiement en production se produit à partir de cette branche. Les HOTFIX qui doivent être effectués en cas d'urgence peuvent alors avoir lieu sur la branche Production sans avoir à fusionner dans le maître (qui peut avoir de nombreuses modifications non testées).
Mon arbre normal ressemble
LongTerm -> Development -> Master -> Production
LongTerm <- Development | |
| Development -> Master |
LongTerm <- Development -> Master |
Development <- Master |
Master -> Production
C'est ma règle générale qu'aucun changement ne devrait prendre plus de quelques heures. Si c'est le cas, il doit être transformé en changements plus petits. Si c'est une fonctionnalité énorme (comme une réécriture d'interface utilisateur), cela se poursuit à long terme afin que le développement normal puisse se poursuivre en même temps. Les succursales LongTerm ne sont normalement que des succursales locales tandis que Développement, Maître et Production sont des succursales distantes. Toutes les sous-branches sont également locales uniquement. Cela garde le référentiel propre pour les autres, sans perdre l'utilité de git sur un ensemble de fonctionnalités à long terme.
Je voudrais cependant noter que l'existence d'une succursale à long terme est une chose rare. Normalement, tout mon travail est en développement. Ce n'est que lorsque j'ai une fonctionnalité (ensemble) qui va prendre si longtemps que je dois aussi pouvoir travailler sur des choses de développement normales que j'utilise la branche LongTerm. Si c'est juste un ensemble de changements qui devraient être ensemble, alors je ne fusionne tout simplement pas jusqu'à ce que tout soit fait.
Je pense que c'est un problème assez courant et se résume à choisir les fonctionnalités à inclure dans une version après que les fonctionnalités ont été codées plutôt qu'avant.
par exemple.
J'ai les fonctionnalités A, B et C pour la v2 de mon produit. B et C sont liés, je ne veux pas libérer B à moins que C ne soit également terminé.
J'ai trois développeurs qui travaillent tous en même temps sur les fonctionnalités.
J'ai un set in stone date de sortie D
B est terminé et fusionné, A est terminé et fusionné. C est retardé ... que dois-je faire?!
Je ne pense pas qu'il existe de solution technique à ce problème. Vous souhaitez publier une version non testée du produit avec uniquement la fonctionnalité A incluse. À moins que vous ne fusionniez et testiez toutes les combinaisons possibles de fonctionnalités, cela sera toujours une possibilité.
La solution est plus humaine. Vous avez manqué votre date de sortie et devez la repousser.