Que se passe-t-il si une fonctionnalité fusionnée dans develop est reportée par la direction?
Nous avons récemment rencontré un problème en raison duquel une fonctionnalité de notre application Web (inscription automatique) a été reportée par la direction, car ils pensaient que le démarrage était trop "froid", mais ils voulaient que toutes les autres fonctionnalités sur lesquelles nous travaillions soient mises en ligne.
Le problème est que cette fonctionnalité a été fusionnée pour se développer lorsqu'elle a été terminée avec toutes les autres fonctionnalités que nous nous attendions à pousser en direct sur la prochaine version, nous ne pouvions donc pas simplement fusionner dev -> test -> master comme nous le faisons habituellement.
Comment aurions-nous pu éviter ce problème?
Une approche consiste à le signaler. Il peut vivre dans la base de code mais être désactivé par configuration.
Une autre option consiste à effectuer un commit de restauration qui annule la fusion des fonctionnalités afin qu'elle ne soit plus en développement. Une nouvelle branche peut être créée qui annule la restauration et reste en attente pour fusionner plus tard. Si vous utilisez des demandes d'extraction Github, vous pouvez le faire facilement avec le bouton "annuler la fusion" sur une demande d'extraction fusionnée.
Comment aurions-nous pu éviter ce problème?
Du point de vue du processus, déterminez:
- Qui a été le décideur pour commencer ce travail?
- Pourquoi la décision de publier cette fonctionnalité a-t-elle changé?
- Des attentes manquées?
- Miscommunication?
- Soutien aux entreprises inadéquat?
- Aucune implication client?
Il est plus que probable que la communication a chuté en cours de route. Ceci est important car lorsque cela ne fonctionne pas, vos processus de développement seront basés sur une compréhension fausse et erronée des exigences commerciales.
Oubliez un instant le problème de votre gestion et imaginez que vous disposiez déjà de la "fonctionnalité d'inscription automatique" dans votre dernière version de production, profondément intégrée dans votre base de code. Maintenant, vous obtenez la nouvelle exigence d'ajouter un "interrupteur" pour "l'inscription automatique". Comment géreriez-vous cela dans votre flux de travail Git?
Je suppose que vous déclareriez la "désactivation de l'inscription automatique par configuration" simplement comme une fonctionnalité supplémentaire (ce n'est qu'une forme de Feature Toggle ), donc cela devrait s'intégrer en douceur dans votre flux de travail. Vous pouvez estimer l'effort, si vous le souhaitez, vous pouvez utiliser une branche de fonctionnalité pour cela (ou non, si vous n'utilisez pas de branches de fonctionnalité pour de tels problèmes). Et vous pouvez certainement utiliser le flux usuel "fusionner dev -> test -> master" que vous avez décrit.
Et c'est en fait la façon dont vous pouvez gérer cela dans votre situation actuelle. Du point de vue du flux de travail git, peu importe si la demande de changement provient de la direction de la version 1.0, ou si la demande de changement est un nouveau souhait du client pour la version 2.0.
C'est le problème exact que j'ai avec gitflow et GitHub flow, et il semble qu'avec les applications Web, cela se produit souvent - ou plus comme la norme. Il semble que vous résolviez ce problème de manière rétroactive (mentionnée ci-dessus) ou proactive (exemple ci-dessous).
J'ai créé des `` branches de bundle '' en plus des branches gitflow standard. Le bundle comprend toutes les fonctionnalités prêtes pour uat/qa. Une liste des fonctionnalités uat/qa est créée. Ceux-ci sont fusionnés dans le bundle temporaire, et ce bundle est déployé sur uat/qa. Toute correction de bogue se produit sur la branche de fonctionnalité d'origine, qui est réintégrée dans le bundle et déployée. Cela sépare la prochaine version et permet de tester ces fonctionnalités ensemble avant de trouver leur chemin vers la branche de développement. Les branches approuvées reçoivent une demande d'extraction dans develop - après le processus gitflow. Les fonctionnalités prêtes à être testées peuvent être ajoutées ou supprimées de la branche de bundle temporaire et redéployées.
- Cela permet au maître de toujours refléter l'état prêt pour la production (peut être automatisé avec le crochet)
- Développer reflète toujours le dernier candidat à la prochaine version (et testé)
Les inconvénients incluent la gestion de la liste des bundles et l'ajout d'un autre type de branche; cependant, en plus du correctif rétroactif, qui je pense est trop tard, cela semble être la solution la plus viable.
Avec un add-on GUI, il peut être optimal de cocher les branches de fonctionnalités par déploiement de bundle - avec l'automatisation à l'esprit.