L'Agilitateur - Qui a besoin de plusieurs branches ? - CommentairesCréation de logiciels : de l'agilité à l'artisanat2021-10-09T15:11:31+02:00urn:md5:7668924f626a6543fa389f1b4e47e529DotclearQui a besoin de plusieurs branches ? - sebfauvelurn:md5:9b9196cccc99b496d6df5644748599822013-07-02T10:54:20+02:002013-07-02T09:54:20+02:00sebfauvel<p>Je partage complètement cette vision avec une version continuellement fonctionnelle.<br />
Toutefois, je pense que les branches restent intéressantes pour embarquer des patchs sur une version en production.<br />
La principale raison que je vois, c'est que l'application en cours de développement, même si les fonctionnalités sont désactivées, contient des parties "actives" modifiées. Je pense en particulier au code qui va permettre de gérer les abstractions pour les fonctionnalités en cours de développement. Ce code est peut être simple et présente peu de risque de régression mais cela me gêne de relivrer en production du code modifié (même minime) et qui n'a rien à voir avec le correctif en cours. Les vérifications nécessaires ne seront pas de même niveau. A moins de se reposer entièrement sur une validation automatisée (ce qui est rare) cela me semble présenter un risque supplémentaire inutile.</p>Qui a besoin de plusieurs branches ? - Oazurn:md5:e424f95e405efd5850b90faffb73e7b52013-06-29T09:09:35+02:002013-06-29T08:09:35+02:00Oaz<p>@gedefah,</p>
<p>Il me faudrait faire un nouveau billet avec un exemple concret.<br />Ca viendra, mais pas dans l'immédiat...</p>Qui a besoin de plusieurs branches ? - gedefahurn:md5:d479846a28a2118d7a15d9dd13d4aba02013-06-13T12:20:24+02:002013-06-13T11:20:24+02:00gedefah<p>Bonjour,</p>
<p>Je suis très intéressé par le concept de polymorphisme pour gérer le développement de nouvelles versions de fonctionnalités et leur activation progressive.<br />
Peux-tu développer un peu plus?</p>
<p>A+</p>Qui a besoin de plusieurs branches ? - Oazurn:md5:1fc02593b1e9898c83121f36443d92fb2013-05-16T14:03:58+02:002013-05-16T13:03:58+02:00Oaz<p>@Fluf,<br />Moi je constate que, au contraire, rajouter des abstractions me permet de simplifier mon code, de supprimer des duplications et de rendre le code plus modulaire donc plus facilement testable.<br />En fait, toutes les abstractions sont utiles tout au long de la vie du logiciel car elles ont toujours au moins 2 implémentations : celle qui est utilisée en prod et celle qui est utilisée en test pour vérifier le comportement des composants utilisateurs de l'abstraction en question.<br />Je renvoie à <a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle" rel="ugc nofollow">ma série de billets sur la conception logicielle pour plus de détails</a>.</p>
<p>@Yohann,<br />Peut être que toutes les réponses ne sont pas dans le présent billet mais celui-ci s'inscrit inévitablement dans le cadre de tout ce qui a pu être écrit jusqu'ici sur ce blog !<br />En fait, je ne me suis jamais levé un matin en me disant "je vais arrêter d'utiliser des branches". C'est plus une conséquence qu'autre chose.<br />Pour lister ce qui m'a amené à cette conséquence, il faut probablement chercher</p>
<ul><li>du côté des <a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle" rel="ugc nofollow">bonnes pratiques de conception</a>, du TDD, de SOLID, etc. car c'est ce qui permet d'écrire un code modulaire et facilement adaptable</li>
<li>du côté d'une <a href="https://agilitateur.azeau.com/post/2011/04/05/Bye-Bye-Scrum" rel="ugc nofollow">gestion en flux d'un produit logiciel</a> car c'est ce qui permet de ne plus travailler par gros morceaux de fonctionnalités qui prendront des semaines (ou plus) à réaliser</li>
</ul><p>Pour répondre plus précisément sur la "fonctionnalité annulée", il faut bien comprendre que les fonctionnalités restent présentes dans notre logiciel. Il se trouve qu'elles ne sont tout simplement pas activées.<br />Que faut-il préférer ? Une fonctionnalité non utilisée qui reste quelque part dans une branche qui diverge du reste ? Ou un fonctionnalité non utilisée qui reste dans la branche principale et dont le lien avec l'abstraction garantit l'abscence de divergence ?</p>
<p>Pour le workflow, c'est simple : on garde les pastilles jaunes et on vire le reste.</p>Qui a besoin de plusieurs branches ? - Yohannurn:md5:d093fb1c0b90e6650d8009b8bda265ae2013-05-16T09:37:15+02:002013-05-16T08:37:15+02:00Yohann<p>Bonjour,</p>
<p>Je suis complètement en accord avec les réponses de Fluf. Vous soulevez des points intéressants dans votre billet, mais au final vous faites une croix sur certaines fonctionnalités d'un VCS. Le concept de branches a été créé pour cette utilisation, quelle est la raison de ne pas l'utiliser ? Vous ne répondez pas réellement à cette question dans votre exposé.</p>
<p>De plus, l'utilisation de branches "Features" et "Hotfix" permet d'avoir une plateforme de "Prod" et/ou de "Dev" saine. J'expose un exemple :<br />
Imaginez le développement d'une nouvelle fonctionnalité. A 30% de vos développements, on vous fait part de l'annulation de celle-ci et de travailler sur autre chose. Si vous utilisez le "Feature flipping", il y aura un bout de fonctionnalité dans votre plateforme qui sera inutilisable. Vous allez peut être me répondre de faire un "Revert" et d'oublier cette fonctionnalité, mais si vous aviez une branche elle pourrait être conservée ; On ne sait jamais, le client va peut être demander la finalisation de cette tâche.</p>
<p>Personnellement j'utilise ce type de "Workflow" en local : <a href="http://paikialog.wordpress.com/2010/11/06/git-workflow/," title="http://paikialog.wordpress.com/2010/11/06/git-workflow/," rel="ugc nofollow">http://paikialog.wordpress.com/2010...</a> et je "Push" exclusivement mes branches "Master" et "Develop" sur le serveur de Git. Quelle est votre "Workflow" généralement ?</p>Qui a besoin de plusieurs branches ? - Flufurn:md5:f7195a32e5aee62773015a10dbb790002013-05-15T19:09:05+02:002013-05-15T18:09:05+02:00Fluf<p>Ok, je n'avais pas vu ca comme ca.<br />
Mais justement ce type développement, ne rajoute t'il pas de la complexité pour au final pas grand chose ?<br />
Le temps de penser l'abstraction, de l'implémenter de modifier un code(qui va etre abandonné) pour qu'il colle au nouveau systeme, et seulement une fois ca fait, on commence la nouvelle fonctionnalité.<br />
On passe beaucoup d'energie sur une modification de code non nécessaire.<br />
Alors qu'avec un VCS qui gère les branches on aurait sauté les 1eres étapes et ne se concentrer que sur celle qui est obligatoire: "développement de la nouvelle fonctionnalité".</p>
<p>Je suis d'accord sur le fait qu'il faut essayer de rajouter de l'abstraction, mais si c'est pour au final avoir 50 concepts qui cohabitent alors qu'à un instant T dans la vie du logiciel une seule n'est utile.</p>
<p>J'ai du mal à imaginer des cas ou un VCS ne facilite pas énormément le travail.</p>Qui a besoin de plusieurs branches ? - Oazurn:md5:2489a3ebcdb45a4b16b779c9b2c0ae942013-05-15T18:16:08+02:002013-05-15T17:16:08+02:00Oaz<p>@Fluf,</p>
<p>Le cas de correction de bug en prod pendant le dev d'une nouvelle fonctionnalité rejoint les notions de feature swapping / branch by abstraction mentionnés dans le billet et le commentaire.<br />Concrètement, les changements induits par la nouvelle fonctionnalité doivent être conceptualisés. Si on prend l'exemple de la modification du système de facturation, on pourrait avoir (je schématise car je ne connais pas du tout l'application en question) une abstraction "facturation" qui a deux implémentations "facturation avant livraison" et "facturation à 30 jours". Au départ, l'abstraction "facturation" n'existe pas car on n'a jamais pensé à avoir autre chose qu'une facturation avant livraison. Donc on commence par faire émerger l'abstraction à iso-fonctionnalité, c'est à dire avec "facturation avant livraison" comme seule implémentation. Puis, on peut commencer à introduire une deuxième implémentation "facturation à 30 jours". Pendant tout ce temps, l'application reste entièrement fonctionnelle. Tant que l'implémentation de "facturation à 30 jours" n'est pas finalisée, elle est tout simplement désactivée et invisible pour les utilisateurs.<br />Cette approche permet de conserver une application dont la branche de développement est systèmatiquement utilisable pour la prod. Du coup, si un bug fix urgent survient, on le fait sur cette branche unique que l'on met en prod aussitôt.</p>
<p>Pour l'exemple des deux équipes qui travaillent en parallèle sur des features différentes, c'est la même chose. Il faut que le développement se fasse en permanence avec une application qui reste toujours fonctionnelle malgré les commits des uns et des autres. Pour cela, il faut encore et toujours faire émerger les abstraction adéquates lorsque le besoin se présente.<br />Non seulement ça évite la gestion des branches mais en plus ça permet de tendre vers une architecture beaucoup plus maintenable car de plus en plus capable d'absorber en douceur les évolutions à venir.</p>Qui a besoin de plusieurs branches ? - Flufurn:md5:2ba7439777b923bcb6be8593c2aed3812013-05-15T06:57:40+02:002013-05-15T05:57:40+02:00Fluf<p>Bonjour,</p>
<p>Je partage ta vision sur le fait qu'il vaut mieux maintenir une seule "version stable" de l'application.<br />
Parcontre pour moi le système de branche est vraiment l'outil qui facilite le travaille et je ne me verrais pas vivre sans, j'en crée tous les jours.</p>
<p>Exemple:<br />
J'ai un logiciel SAAS, avec un système de facturation qui ne permettait de "livré" une commande seulement si la société avait reçu le règlement (on ne visait que les particuliers/TPE)<br />
Sauf qu'on a décroché un contrat avec une grosse société qui elle voulait un paiement à 30jrs.</p>
<p>Donc modification du système de facturation (~1semaine)<br />
Sauf que pendant cette semaine, j'ai constaté pendant mon developpement l'existance d'un bug rare, mais grâve.</p>
<p>Donc j'ai fais une branche de ma version "production", fait ma correction de bug, mis en prod, et fusionné cette correction avec ma branche "nouveau systeme de facturation"<br />
Sans branche, comment vous auriez fait ?<br />
Vous auriez repoussé la livraison du patch à la fin de la nouvelle fonctionnalité ?</p>
<p>Autre situation, une partie de mon équipe travaille sur la fonctionnalité A, et une autre sur la fonctionnalité B.<br />
l'équipe A est en a ses tests, alors que l'équipe B est en plein développement(et donc l'appli n'est plus fonctionnelle)</p>
<p>Si tous les dev' utilise la même branche, comment l'équipe A peut elle livrer sa fonctionnalité, si lors de ses tests l'appli n'est plus fonctionnelle ?<br />
Alors qu'une branche "feature-A" pour l'équipe A et une branche "feature-B" pour l'équipe B<br />
Tout le monde peut "commit", partagé sans impacter le travail des autres.</p>Qui a besoin de plusieurs branches ? - Oazurn:md5:e892e14d985da8e785463a87508a412b2013-04-14T21:25:41+02:002013-04-14T20:25:41+02:00Oaz<p>@Armaklan</p>
<p>Merci !</p>
<p>Question articles sur l'aspect architecture, il y en a <a href="https://agilitateur.azeau.com/post/2012/03/06/Le-logiciel%2C-un-organisme-multicellulaire" rel="ugc nofollow">quelques uns de très théoriques</a> sur ce que l'on met en oeuvre chez nous. Il y a aussi des exemples de mise en pratique (on voit par exemple transparaître l'émergence des abstractions <a href="https://agilitateur.azeau.com/post/2013/04/07/Un-code-propre-est-plus-utile-qu-un-code-efficace" rel="ugc nofollow">dans mon dernier billet</a>, il y aussi <a href="https://agilitateur.azeau.com/post/2012/02/15/Je-n-aime-pas-les-conteneurs-d-injection-de-d%C3%A9pendances" rel="ugc nofollow">celui-là sur l'injection de dépendances</a>) mais c'est difficile de faire un billet concret sur le sujet sans embarquer le poids du contexte...</p>
<p>Les idées générales, on les retrouve aussi sur la toile dans tout ce qui parle de "branch by abstraction" et sinon il y a <a href="http://vimeo.com/43612849" rel="ugc nofollow">une video d'Uncle Bob incontournable</a> sur le sujet.</p>Qui a besoin de plusieurs branches ? - Armaklanurn:md5:904fbcbf029451713b60ab2fd188692d2013-04-14T15:29:51+02:002013-04-14T14:29:51+02:00Armaklan<p>Bonjour,</p>
<p>Même si tu m'a déjà expliquer rapidement ta solution par twitter, je serai assez intéressé par voir un article plus approfondi sur ta solution pour utiliser une branche unique et ce que tu met en oeuvre au niveau de l'architecture du logiciel en lui même.</p>
<p>En tout cas, ton blog est très intéressant et donne à réfléchir au sujet de certaines habitudes qu'on nous a inculqués et qu'on applique peut être de façon un peu trop systématique.</p>Qui a besoin de plusieurs branches ? - Oazurn:md5:1f9194f86e4571301473997712c53d0d2013-04-03T10:01:19+02:002013-04-03T09:01:19+02:00Oaz<p>@Xavier,<br />Concernant le poste du développeur, si on voulait être précis dans les termes, il faudrait plutôt parler de "divergence de code" dont la réalité technique dépend de l'outil considéré (branche, working copy...)<br />Parler de "branche unique" est en fait un raccourci simplificateur pour dire que les divergences de code doivent être réduites au strict minimum dans l'espace et dans le temps.<br />En fait, je n'ai pas d'avis sur le mode de travail de chaque développeur du moment du moment que son code de production ne reste pas plus de 2 ou 3 heures hors de la version de référence de l'équipe...<br />En ce qui me concerne, peut importe si je fais un spike sur une copie ou sur une branche locale. Tout dépend de l'outil à disposition. Par contre, je ne mélange jamais essais et code de prod. Je considère par exemple que le cherry picking depuis un spike vers le "vrai" code est une pratique risquée car elle ne garantit pas le transfert du pilotage par les tests.</p>
<p>@Laurent,<br />Evoluant moi même dans un environnement proche du SaaS par le modèle économique mais encore largement "traditionnel" par les aspects techniques (induits notamment par la forte présence de matériel spécifique), je peux comprendre le problème des versions. Mais je crois que celui-ci n'est pas une fatalité. Même s'il y a des morceaux de systèmes versionnés pour diverses raisons, on peut rendre d'autres parties "version-less". C'est en tout cas ce que nous faisons dans notre équipe en communiquant avec les parties versionnées à travers des plug-ins dédiés (un par version) et qui implémentent tous le même contrat vis à vis du reste de notre logiciel.</p>Qui a besoin de plusieurs branches ? - Laurenturn:md5:c31ce6cf4b6c22432c0657a17f2987192013-04-02T09:44:26+02:002013-04-02T08:44:26+02:00Laurent<p>Bonjour Olivier,<br />
merci pour cet article très interessant.<br />
Le sujet des branches est effectivement souvent central en développement logiciel et assez peu souvent traité.<br />
Comme écrit par Xavier, il faut distinguer les éditeurs en mode SAAS et les traditionnels. Pour le SAAS, la question ne se pose pas...<br />
Mon experience (en mode traditionnel) est que ce sont les clients qui exigent souvent une gestion de branche, par frilosité de récupérer une nouvelle version qui contiennent trop de changements et qui leur prennent trop de temps à intégrer. A leur décharge, on peut aussi considerer le fait qu'ils ont pu souffrir de nouvelles versions qui contenaient des regressions ou des changements d'API non/mal communiqués et qu'ils sont refroidis.<br />
Laurent</p>Qui a besoin de plusieurs branches ? - Xavier NOPREurn:md5:cd3f3915cfdb6d783711480e4b9a39a62013-04-02T08:26:23+02:002013-04-02T07:26:23+02:00Xavier NOPRE<p>Salut Olivier,</p>
<p>Merci pour cet article auquel j'adhère (presque) totalement. C'est très (trop) courant de voir un fort engouement, pour un outil et ses fonctionnalités, entraîner les utilisateurs de cet outil dans des dérives les éloignant des fondamentaux de l'outil lui-même (les branches en l'occurence).</p>
<p>Pour les "features branches" sur le tronc commun ne devrait pas être utilisées, surtout en mode agile, où une fonctionnalité devrait pouvoir être intégrée petit à petit. Par contre, j'y suis favorable sur le poste de chaque développeur. Moi même, j'utilise Git sans modération pour les travaux en court, mais à court terme, ou les essais en tous genres.</p>
<p>Et concernant les "releases branches", elles ne sont plus nécessaires pour le développement d'application SaaS qui pourrait représenter une grosse partie des futures développements.</p>
<p>Xavier</p>