J'espère que vous ne bossez pas en agilité dans ta boite ? Auquel cas, ce message ne te concerne pas.
Déjà cette drôle d'idée de reporter toutes les versions de prod sur la branche master et de dédier develop à ça.
Quand un gars arrive dans une équipe pour se joindre aux forces vives, quoi de plus naturel que de bosser dans master. Si je veux connaitre le version de prod, y'a quoi de compliqué de s'appuyer sur une convention de nommage et de lister les tags avec un petit grep des familles.
Ensuite cette manie de créer une branche de release pour la recette et la maintenance. En agilité que ce soit en scrum, kanban, lean ou à fortiori en continuous deployment, on a coutume de réintégrer les demandes de corrections plus tard (sprint suivants). On ne s'amuse pas relivrer des corrections en recette ou en prod sauf cas du hotfix qui est le seul qui nécessite une branche dédié à réintégrer dans la master. Evidemment on automatise un max avec une batterie de test pour qu'une recette ne dure une éternité (test exploratoires). La branche de release avec un environnement stable pour tester est le signe avant coureur que le projet va partir en couille et que les prestataire de monkey tester vont débarquer en masse. Le cône glacé va vous refroidir.
Enfin les feature branch. Le jour où on comprendra que développer à base de feature branche, et pour aller encore plus loin de pull request avec revue online comme veulent absolument nous les refiler Atlassian, Github, Gitlab et consors qui ont tout intérêt a centraliser encore plus les workflowws autour de leurs outils pour nous revendre leur bidules, on aura fait de grands progrès.
L'agilité ça consiste à discuter au plus tôt sur les questions qui pourraient poser problème. La base de l'agilité c'est l'intégration continue. Tout ce qui y contrevient est malvenu. Relisez c'est article de Martin Fowler pour comprendre pourquoi c'est le mal:
(Je l'ai déjà posté plus haut mais là je vais appuyer l'argumentaire). Dans une feature branch,vous retardez l'intégration de vos devs et par delà la découverte de problèmes d'architecture. Vous pouvez vous réalignez régulièrement par rapport à master (merge from upstream) mais il n'en reste pas moins que vous êtes isolés de toutes les features pas encore intégrées et les autres de la vôtre. Ce n'est qu'au moment où vous intégrez que les problèmes arrivent et notamment le big bang merge, les conflits sémantiques et c'est souvent le plus mauvais moment... peu avant la fin du sprint.
Certains parlent alors du mini effet tunnel qui vous fait retomber dans les travers des méthodes traditionnelles, consustant à tout intégrer dans l'urgence et souvent au détriment de la qualité (on n'a pas le temps de refactorer nos tests là, on est à la bourre).
Au fait, reposons-nous la question: Quelle sont les raisons pour lesquelles on souhaiterait mettre en place des feature branch?
La réponse qui vient immédiatement concerne la souplesse que ça nous apporte. On peut décider d'intégrer une feature au moment d'une livraison ou de la reporter si elle n'est pas prête.
Alors déjà, première chose: Pourquoi passer systématiquement par une branche surtout en début de sprint ?
Ensuite, quel est le problème de livrer une feature incomplète ... si elle n'affecte pas votre produit ?
Vous voyez poindre la solution qui permet de continuer à développer dans le trunk tout en conservant cette souplesse ? Vous l'avez tous déjà fait un jour. Supprimer un item dans un menu, ou un bouton dans un formulaire...
Ca s'appelle le feature toggling(http://martinfowler.com/bliki/FeatureToggle.html). Vous structurez votre code pour activer ou non des fonctionnalités au déploiement (http://martinfowler.com/articles/feature-toggles.html).
Ceci vous permettra même de valider ou non la pertinence d'une fonctionnalité sur un panel de clients précis ou de les comparer en environnement réel. le fameux A/B testing.
Après, il est vrai qu'une des conséquences est que ça génère de la dette technique, et qu'il faut supprimer le code d'activation lorsque la feature est intégrée ou écartée. Mais il existe des frameworks pour vous y aider.
Alors si vous voyez débarquer dans vos équipes un type qui vous vante les mérites du feature branching, et que c'est peanuts avec git et que Git flow c'est une tuerie, le même qui ne s'est jamais paluché un vrai merge des familles avec du refactoring sur le nom des packages et des classes, les changements sur les schémas de base de données, un conseil ... Fuyez !!!
Toujours pas convaincus ?
Peut-être que lui y parviendra.
[^] # Re: Workflow git
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 7. Dernière modification le 17 septembre 2016 à 18:47.
Ah ce fameux git-flow. Il y a tant à dire.
J'espère que vous ne bossez pas en agilité dans ta boite ? Auquel cas, ce message ne te concerne pas.
Déjà cette drôle d'idée de reporter toutes les versions de prod sur la branche master et de dédier develop à ça.
Quand un gars arrive dans une équipe pour se joindre aux forces vives, quoi de plus naturel que de bosser dans master. Si je veux connaitre le version de prod, y'a quoi de compliqué de s'appuyer sur une convention de nommage et de lister les tags avec un petit grep des familles.
Ensuite cette manie de créer une branche de release pour la recette et la maintenance. En agilité que ce soit en scrum, kanban, lean ou à fortiori en continuous deployment, on a coutume de réintégrer les demandes de corrections plus tard (sprint suivants). On ne s'amuse pas relivrer des corrections en recette ou en prod sauf cas du hotfix qui est le seul qui nécessite une branche dédié à réintégrer dans la master. Evidemment on automatise un max avec une batterie de test pour qu'une recette ne dure une éternité (test exploratoires). La branche de release avec un environnement stable pour tester est le signe avant coureur que le projet va partir en couille et que les prestataire de monkey tester vont débarquer en masse. Le cône glacé va vous refroidir.
Enfin les feature branch. Le jour où on comprendra que développer à base de feature branche, et pour aller encore plus loin de pull request avec revue online comme veulent absolument nous les refiler Atlassian, Github, Gitlab et consors qui ont tout intérêt a centraliser encore plus les workflowws autour de leurs outils pour nous revendre leur bidules, on aura fait de grands progrès.
L'agilité ça consiste à discuter au plus tôt sur les questions qui pourraient poser problème. La base de l'agilité c'est l'intégration continue. Tout ce qui y contrevient est malvenu. Relisez c'est article de Martin Fowler pour comprendre pourquoi c'est le mal:
(Je l'ai déjà posté plus haut mais là je vais appuyer l'argumentaire). Dans une feature branch,vous retardez l'intégration de vos devs et par delà la découverte de problèmes d'architecture. Vous pouvez vous réalignez régulièrement par rapport à master (merge from upstream) mais il n'en reste pas moins que vous êtes isolés de toutes les features pas encore intégrées et les autres de la vôtre. Ce n'est qu'au moment où vous intégrez que les problèmes arrivent et notamment le big bang merge, les conflits sémantiques et c'est souvent le plus mauvais moment... peu avant la fin du sprint.
Certains parlent alors du mini effet tunnel qui vous fait retomber dans les travers des méthodes traditionnelles, consustant à tout intégrer dans l'urgence et souvent au détriment de la qualité (on n'a pas le temps de refactorer nos tests là, on est à la bourre).
Au fait, reposons-nous la question: Quelle sont les raisons pour lesquelles on souhaiterait mettre en place des feature branch?
La réponse qui vient immédiatement concerne la souplesse que ça nous apporte. On peut décider d'intégrer une feature au moment d'une livraison ou de la reporter si elle n'est pas prête.
Alors déjà, première chose: Pourquoi passer systématiquement par une branche surtout en début de sprint ?
Ensuite, quel est le problème de livrer une feature incomplète ... si elle n'affecte pas votre produit ?
Vous voyez poindre la solution qui permet de continuer à développer dans le trunk tout en conservant cette souplesse ? Vous l'avez tous déjà fait un jour. Supprimer un item dans un menu, ou un bouton dans un formulaire...
Ca s'appelle le feature toggling(http://martinfowler.com/bliki/FeatureToggle.html). Vous structurez votre code pour activer ou non des fonctionnalités au déploiement (http://martinfowler.com/articles/feature-toggles.html).
Ceci vous permettra même de valider ou non la pertinence d'une fonctionnalité sur un panel de clients précis ou de les comparer en environnement réel. le fameux A/B testing.
Après, il est vrai qu'une des conséquences est que ça génère de la dette technique, et qu'il faut supprimer le code d'activation lorsque la feature est intégrée ou écartée. Mais il existe des frameworks pour vous y aider.
Alors si vous voyez débarquer dans vos équipes un type qui vous vante les mérites du feature branching, et que c'est peanuts avec git et que Git flow c'est une tuerie, le même qui ne s'est jamais paluché un vrai merge des familles avec du refactoring sur le nom des packages et des classes, les changements sur les schémas de base de données, un conseil ... Fuyez !!!
Toujours pas convaincus ?
Peut-être que lui y parviendra.