Comment convaincre les développeurs de commencer à utiliser les bascules d'indicateur de fonctionnalité?

En supposant que les bascules d'indicateur de fonctionnalité sont une bonne idée et devraient être implémentées dans du code que les développeurs écrivent. Par exemple, Etsy ne jure que par eux comme une partie importante de leur culture .

Quelle est la bonne façon de persuader (et d'appliquer) les développeurs de commencer à utiliser les bascules d'indicateur de fonctionnalité?

Plus d'informations sur les bascules d'indicateur de fonction sont expliquées dans Q: Comment utiliser les bascules d'indicateur de fonction , Q: Que sont les bascules d'indicateur de fonction et très largement dans l' article de Pete Hodgson sur le sujet sur le blog de Martin Fowler .

Les bascules de fonction sont une pratique courante dans le développement à grande vitesse car elles dissocient le développement de la version. Les équipes de développement peuvent "publier en douceur" une nouvelle fonctionnalité en production, dans un état désactivé. Cela permet à la fonctionnalité d'être libérée à tout moment. Si la fonctionnalité dépend d'autres travaux ou préparations, elle n'a pas à attendre qu'une version majeure soit mise en production.

Pour ce qui est de «convaincre» les développeurs de les utiliser, c'est un exercice pour défendre la liberté qu'il offre. D'après mon expérience, ce n'est pas difficile à vendre aux développeurs. C'est la gestion qui a tendance à hésiter à essayer de nouvelles choses. Essaye ça:

• Trouvez un cadre de basculement de fonctionnalités. La direction / l'entreprise peut être plus disposée à essayer quelque chose soutenu par un système commun
• Commencer petit. Présentez le système à bascule à titre d'essai pour une fonctionnalité qui démontrera son utilité.
• Démontrer la capacité de la bascule à effectuer des tests A / B. Activez la bascule pour un sous-ensemble de votre batterie de serveurs Web, puis rassemblez des mesures sur le comportement. Il a été démontré que de minuscules différences dans la mise en page ont des effets énormes sur les revenus des applications de vente au détail (par exemple Ebay, Amazon)

Dans un monde idéal, je pense que vous déployez une nouvelle construction et surprenez! Rien ne change. En effet, toutes vos nouvelles fonctionnalités sont derrière des interrupteurs qui s'éteignent avec l'interrupteur éteint.

Après le déploiement, vous vérifiez que votre service déployé fonctionne toujours, les téléphones ne sonnent plus (sauf si la sonnerie des téléphones est votre objectif, etc.), etc. Une fois que vous êtes revenu à une opération stable connue, vous commencez à activer et à vérifier vos fonctionnalités nouvellement déployées.

Maintenant, pour votre réponse: Comment aimeriez-vous travailler dans une équipe où être sur appel est pratiquement une évidence et nos utilisateurs nous aiment parce que nos sites et services sont stables comme le roc?

C'est l'équipe sur laquelle je veux travailler.

Vous pouvez arrêter de lire ici si vous le souhaitez.

Tout mettre derrière un commutateur de fonctionnalités semble pouvoir conduire à du code spaghetti partout. Si vous utilisez l'IoC et que vous pouvez choisir entre vNow / vNext / vPrevious, cela revient à maintenir votre configuration. Oui plus de check-ins, oui plus de classes (componentV1, componentV2, componentV3, etc.) mais vous avez réellement un système plus stable? Comment? vNext est bancal? Revenez à vNow avec votre tour de contrôle. Cela fait une semaine et vNow a un bug subtil? Même chose - revenez à vPrevious tout aussi facilement.

Pas de soucis, pas de soucis, pas de sommeil perdu, pas de stress.

Ce n'est pas un rêve de pipe. J'y travaillais. J'aimerais pouvoir vendre cela à mon équipe actuelle.

Un environnement de développement à haute vitesse réussi repose généralement sur un système automatisé assez strict impliquant des vérifications de qualité avec détection et rejet des modifications défectueuses provoquant des régressions.

Les bascules de fonctionnalités offrent la possibilité de valider même des travaux en cours, des modifications non testées sans être rejetées pour avoir provoqué des régressions dans la branche d'intégration. Ce qui constitue une très bonne incitation à introduire la fonction bascule très tôt dans la vie de la fonction.

L'un des inconvénients de s'écarter du véritable CI et de déplacer le développement de fonctionnalités sur les branches de fonctionnalités est le manque d'une telle incitation. L'ajout de la fonction bascule plus tard, lors de la fusion de la branche de fonction dans la branche d'intégration est généralement plus difficile, comme toute intégration tardive.

Les développeurs (et généralement les responsables du développement) recherchent généralement deux résultats associés au framework: la facilité de gestion et la vitesse de déploiement. Vous souhaitez expédier du code plus rapidement et plus facilement.

Fournir la preuve que l'approche fonctionne; essayez de construire un petit POC en utilisant des indicateurs de fonctionnalité par rapport à l'ancienne. Les études de cas importent moins aux personnes tactiques (développeurs \ ingénieurs) qu'aux personnes stratégiques (cadres moyens \ concepteurs de produits).

La raison d'être des bascules de fonctionnalités n'est pas du ressort des développeurs. C'est quelque chose dont les propriétaires de produits doivent se soucier. Les développeurs permettent ce changement de la manière la plus durable et la plus sûre. Je critique cette question même.