Le Branching by Abstraction je ne crois pas que ce soit autre chose qu'une vue de l'esprit. Je n'ai jamais vu des gens en faire pour de vrai. Je pense que c'est trop complexe pour véritablement être mis en place.
Je suis tristesse de l'avoir mis en place plusieurs fois avec succès alors :-(
Pour donner un peu une idée : le soft était une app mobile, multiplateforme, de pilotage de drones. On a du, plusieurs fois, réaliser de gros chantiers dans l'app tout en continuant à ajouter des features. Et quand je dis gros chantiers c'est aussi chantiers critiques, genre refonte totale de tous les checks fait avant le décollage, refonte de tout le mécanisme de détection de problème en vol. Un poil sensible.
Et le problème c'était surtout que chacun de ses taffs dépassaient une itération de boulot. Hors on avait besoin d'avoir des versions utilisables à chaque itération.
La solution classique c'est de faire une branche, qui va durer le temps qu'il faut, et qui sera mergée un jour. C'est hyper fatiguant. Encore plus quand, durant les refactorings un autre dev doit ajouter des features utilisant la partie refactoré (par exemple ajout d'un nouveau check avant décollage). Et il n'est pas question de le faire attendre plusieurs semaines.
Donc tout s'est passé suivant du Branching by Abstraction. J'ai pu introduire une couche de compatibilité très rapidement, puis développer une nouvelle archi en parallèle (dans master pour simplifier un poil). Pendant un temps d'ailleurs les deux archi ont coexisté, puis tout l'existant a été converti sur la nouvelle archi, l'ancienne n'étant alors qu'une coquille vide elle a disparu. Tout c'est fait avec des branches de courtes durée (pour avoir de la review) et mergé dans master. Ainsi, alors que le boulot n'était pas fini et simplement désactivé par un ifdef, des versions utilisables était toujours présentes.
L'un des gros avantages (qui est commun aux features branches et qui contredit _ il n'y a pas de différence notable entre un mec qui développe dans son workspace sans soumettre son code et sans mettre à jour sa base de code et le feature branche_) est que le code de la nouvelle feature, bien que partiellement désactivé en prod, était dans la CI, les tests se jouaient dessus en permanence, tout le monde utilisait la nouvelle abstraction. Ce qui fait d'ailleurs que la transition old->new fut simple et avec beaucoup moins de risques que si on avait fait une branche qui avait existé pendant 3-4 semaines.
[^] # Re: Workflow git
Posté par CrEv (site web personnel) . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 3.
Je suis tristesse de l'avoir mis en place plusieurs fois avec succès alors :-(
Pour donner un peu une idée : le soft était une app mobile, multiplateforme, de pilotage de drones. On a du, plusieurs fois, réaliser de gros chantiers dans l'app tout en continuant à ajouter des features. Et quand je dis gros chantiers c'est aussi chantiers critiques, genre refonte totale de tous les checks fait avant le décollage, refonte de tout le mécanisme de détection de problème en vol. Un poil sensible.
Et le problème c'était surtout que chacun de ses taffs dépassaient une itération de boulot. Hors on avait besoin d'avoir des versions utilisables à chaque itération.
La solution classique c'est de faire une branche, qui va durer le temps qu'il faut, et qui sera mergée un jour. C'est hyper fatiguant. Encore plus quand, durant les refactorings un autre dev doit ajouter des features utilisant la partie refactoré (par exemple ajout d'un nouveau check avant décollage). Et il n'est pas question de le faire attendre plusieurs semaines.
Donc tout s'est passé suivant du Branching by Abstraction. J'ai pu introduire une couche de compatibilité très rapidement, puis développer une nouvelle archi en parallèle (dans master pour simplifier un poil). Pendant un temps d'ailleurs les deux archi ont coexisté, puis tout l'existant a été converti sur la nouvelle archi, l'ancienne n'étant alors qu'une coquille vide elle a disparu. Tout c'est fait avec des branches de courtes durée (pour avoir de la review) et mergé dans master. Ainsi, alors que le boulot n'était pas fini et simplement désactivé par un ifdef, des versions utilisables était toujours présentes.
L'un des gros avantages (qui est commun aux features branches et qui contredit _ il n'y a pas de différence notable entre un mec qui développe dans son workspace sans soumettre son code et sans mettre à jour sa base de code et le feature branche_) est que le code de la nouvelle feature, bien que partiellement désactivé en prod, était dans la CI, les tests se jouaient dessus en permanence, tout le monde utilisait la nouvelle abstraction. Ce qui fait d'ailleurs que la transition old->new fut simple et avec beaucoup moins de risques que si on avait fait une branche qui avait existé pendant 3-4 semaines.