Que se passe-t-il si une fonctionnalité fusionnée dans develop est reportée par la direction?

53

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 elle estimait que le début était trop "froid", mais elle souhaitait que toutes les autres fonctionnalités sur lesquelles nous avions travaillé soient mises en ligne.

Le problème est que cette fonctionnalité avait été intégrée à develop quand elle était finie avec toutes les autres fonctionnalités que nous nous attendions à mettre en production lors de la prochaine version, de sorte que nous ne pourrions pas simplement fusionner dev -> test -> master comme nous le faisons habituellement.

Comment avons-nous pu éviter ce problème?

project-management git gitflow

— Steve
source

Selon votre point de vue sur la façon dont vous voulez résoudre ce problème, cette question convient mieux au lieu de travail, si vous ne recherchez pas de solution technique.

— Malavos

74

Une approche consiste à la signaler. Il peut vivre dans la base de code mais être désactivé par configuration.

Une autre option consiste à effectuer une validation qui annule la fusion des fonctionnalités afin qu’elle ne soit plus en développement. Vous pouvez créer une nouvelle branche qui annule le retour et laisser en attente pour une fusion ultérieure. Si vous utilisez des demandes d'extraction Github, vous pouvez le faire facilement avec le bouton "annuler la fusion" d'une demande d'extraction fusionnée.

— Daenyth
source

9

Le marquage de la configuration n'implique-t-il pas un doublement des efforts de test pour ce code? Vous devez tester les deux chemins.

16

Dans ce cas, étant donné que vous n'activerez pas ce drapeau en production, vous pouvez tester le casse-tête maintenant pour la sortie, puis le caser quand il sera prêt. Cela devrait être à peu près le même travail que de tester un revert et un nouvel engagement.

— Alan Shutko

4

Le terme commun est Feature Toggle . S'il existe un petit "point d'entrée de fonction", cela peut probablement être fait après la décision de gestion. Sinon, on rencontrera des problèmes avec cette méthode ainsi qu'avec n'importe quelle méthode.

— Doc Brown le

3

Nous avons des fonctionnalités qui sont en développement depuis plus de 6 mois et qui sont cachées par Feature Toggling, comme l'appelait Doc Brown. Cela nous permet également de tester la fonctionnalité (ou son absence) dans des environnements non productifs. Parfois, ces fonctionnalités s'ajoutent aux fonctionnalités existantes, auquel cas nous devrions avoir des tests unitaires pour l'ancien et le nouvel ensemble de fonctionnalités. Chaque test unitaire définit simplement le drapeau sur ce dont il a besoin pour effectuer le test en cours.

— ps2goat

25

Comment avons-nous pu éviter ce problème?

Du point de vue du processus, déterminez:

Qui était le décideur pour commencer ce travail?
Pourquoi la décision de publier cette fonctionnalité a-t-elle changé?
- Attentes manquées?
- Miscommunication?
- Soutien aux entreprises inadéquat?
- Aucune implication du client?

Plus que probablement il y avait des baisses de communication en cours de route. Ceci est important car, lorsque cela ne fonctionne pas, votre processus de développement sera basé sur une compréhension fausse et erronée des exigences de l'entreprise.

— Enderland
source

9

+10. Dès que la direction a commencé à douter de la sortie de la fonctionnalité, elle aurait dû en informer les développeurs, de sorte que la suppression éventuelle aurait pu être prise en compte lors de la décision de fusionner la fonctionnalité en développement.

— Bart van Ingen Schenau

14

Ce n'est pas une réponse très constructive - parfois les choses vont de travers pour toutes sortes de raisons. Bien sûr, il est important de savoir qu'il ne devrait pas être fusionné plus tôt que prévu, mais cela ne signifie pas pour autant qu'une fonctionnalité sera supprimée à la dernière minute. Peut-être que des changements de contrat, que vos clients ne paient pas, que des problèmes juridiques apparaissent… vous devez toujours gérer le problème au lieu de tout reprocher

— gbjbaanb

11

Si certaines personnes de votre organisation sont suffisamment puissantes pour refuser d'admettre une faute, et également suffisamment enfantines pour ne pas vouloir éviter des fautes, vous devriez toujours avoir des problèmes de post-mortem pour votre propre information. Vous ne voulez simplement pas leur dire (ou l'écrire trop explicitement). Cela dit, enderland n'utilise pas le mot "blâme" et si l'organisation interprète ce conseil comme "trouver qui est à blâmer", il s'agit en soi d'un problème sur lequel l'organisation doit travailler. Tout ce que cela dit, c'est "comprendre pourquoi le problème est survenu", ce qui est essentiel pour l'éviter à l'avenir.

— Steve Jessop

2

Je suis tout à fait d’accord, c’est un fouillis de la gestion, pas un développeur.

— durron597

3

@enderland Mon point est que vous ne pouvez pas éviter certains problèmes, vous devez donc réfléchir à la façon de réparer la situation. J'espère que vous n'irez pas aussi souvent, mais cela se produira tôt ou tard, alors planifiez-vous en conséquence.

— gbjbaanb

19

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 à votre base de code. Vous obtenez maintenant la nouvelle exigence d'ajouter un "interrupteur" pour "inscription automatique". Comment géreriez-vous cela dans votre workflow Git?

Je suppose que vous déclareriez la "désactivation de l'inscription automatique par configuration" simplement comme une fonctionnalité supplémentaire (il ne s'agit que d'une forme de fonctionnalité bascule ), elle devrait donc s'intégrer facilement dans votre flux de travail. Vous pouvez estimer l'effort, si vous le souhaitez, vous pouvez utiliser une branche de fonctionnalité pour celle-ci (ou non, si vous n'utilisez pas de branche de fonctionnalité pour de tels problèmes). Et vous pouvez certainement utiliser le flux usal "merge 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 workflow git, peu importe si la demande de modification provient de la direction pour la version 1.0 ou si la demande de modification correspond à un nouveau souhait du client pour la version 2.0.

— Doc Brown
source

Fowler a de très bons résultats, mais je ne peux pas supporter cette méthode pour l'introduction des fonctionnalités. L'effort coordonné pour de tels échanges semble être un fardeau inutile. Je peux prendre en charge l'ajout de commutateurs de fonctionnalités pour supprimer des fonctionnalités après la fusion, mais la création d'un commutateur dans le cadre de l'exigence me met mal à l'aise.

— Gusdor

@Gusdor: voir mon édition.

— Doc Brown

1

C’est exactement le problème que j’ai avec gitflow et le flux GitHub, et il semble que cela se produise souvent avec les applications Web - ou plutôt comme la norme. Il semble que vous puissiez résoudre ce problème de manière rétroactive (mentionnée ci-dessus) ou de manière proactive (exemple ci-dessous).

J'ai créé des «branches de bundles» en plus des branches standard de gitflow. Le bundle comprend toutes les fonctionnalités prêtes pour uat / qa. Une liste de caractéristiques uat / qa est créée. Celles-ci sont fusionnées dans le paquet temporaire et ce dernier est déployé sur uat / qa. Toute correction de bogue se produit sur la branche de fonctionnalité d'origine et est restituée dans l'ensemble et déployée. Cela sépare la prochaine version et permet de tester ces fonctionnalités ensemble avant qu'elles ne se retrouvent dans la branche develop. Les branches approuvées reçoivent une demande d'extraction en développement - en suivant le processus gitflow. Des fonctionnalités de test peuvent être ajoutées ou supprimées de la branche de l'ensemble temporaire et redéployées.

Ceci garde le maître toujours reflétant l'état de production (peut être automatisé avec le crochet)
Développer reflète toujours la dernière version disponible (et testée) de la prochaine version candidate

Inconvénients: gestion de la liste des lots et ajout d’un autre type de branche; Cependant, à part la solution rétro, qui me semble trop tardive, cela semble être la solution la plus viable.

Avec un complément d'interface graphique, il peut être optimal d'activer le déploiement de branches de fonctionnalités par ensemble, en gardant à l'esprit l'automatisation.

— David Latty
source