Quelles sont les différentes façons d'utiliser les bascules d'indicateur de fonctionnalité dans les applications?
Si vous deviez expliquer à un développeur les choses exactes à faire pour passer de rien à une application complète avec indicateur de fonctionnalité, quelles seraient ces étapes?
Réponses:
Les indicateurs de fonctionnalité sont un dispositif d'ingénierie qui peut être utilisé pour éviter une branche de longue durée et des conflits dans le développement de produits. Voici comment il peut être utilisé dans le contexte d'un langage orienté objet pour aider les développeurs à collaborer sur une fonctionnalité de produit spécifique pendant que l'on gère une nouvelle version. Cette solution peut également être utilisée dans des contextes non orientés objet, à condition qu'il existe une notion d '«interface». ( cf. système de module OCaml.)
À des fins d'illustration, nous supposons un outil présentant des rapports sur les données stockées dans une base de données. Le code implémente une classe DatabaseClient utilisée pour effectuer des requêtes. Au fur et à mesure que l'ensemble de données se développe, il devient clair qu'une autre disposition des données améliorerait les performances de l'application. Par conséquent, Alice développera une nouvelle version de DatabaseClient capable de récupérer des données des structures avec une mise en page améliorée, tandis que Bob conservera l'historique DatabaseClient .
Avec les étapes suivantes, Alice et Bob peuvent collaborer sur des branches de courte durée tout en minimisant leurs conflits.
Alice renomme DatabaseClient en DatabaseClient_v1 et crée une classe déléguée appelée DatabaseClient qui utilise un objet DatabaseClient_v1 et implémente une interface appelée DatabaseClientInterface. (Si possible, cette DatabaseClientInterface doit être un artefact de code mais les langages de type canard ne le prennent pas toujours en charge.)
Bob passe en revue les modifications apportées par Alice en 1 et sait que son travail de maintenance doit avoir lieu sur DatabaseClient_v1 .
Alice introduit un nouvel indicateur de configuration dans l'application qui régit le comportement du délégué DatabaseClient et implémente un espace réservé DatabaseClient_v2 , une classe implémentant DatabaseClientInterface dont les méthodes lèvent toutes une exception «Non implémenté».
Après cela, Alice et Bob peuvent collaborer sans synchronisation explicite, car le code écrit dans leurs itérations respectives est soumis à DatabaseClientInterface . Cela minimise le risque de conflit résultant de leur travail simultané.
Les itérations d'Alice peuvent être très courtes, comme l'implémentation d'un test, l'implémentation d'une méthode, ou même partiellement, car en production, le code n'est pas sélectionné pour être utilisé et n'a pas besoin d'être entièrement fonctionnel. La suite de tests automatisée doit être configurée de sorte que DatabaseClientInterface utilise toujours DatabaseClient_v1 tandis qu'Alice peut facilement basculer vers DatabaseClient_v2 lors de l'exécution locale de la suite de tests - ou dans une configuration CI personnalisée. Une fois que tout est prêt, une seule validation peut effectuer la modification, en mettant à jour la valeur de configuration régissant le délégué DatabaseClient .
Les étapes sont assez "faciles", pour passer à une application d'indicateur de fonctionnalité, vous avez essentiellement besoin de deux choses:
La base de l'indicateur de fonctionnalité est de les activer / désactiver, mais vous souhaiterez rapidement publier une nouvelle fonctionnalité de manière accélérée, par exemple: 1 serveur sur 5 hébergeant l'application a la fonctionnalité "on" pour démarrer, vous activez ensuite la fonctionnalité sur un autre serveur, jusqu'à ce que tous les serveurs l'aient "on".
Cela signifie que vous devez faire attention à ce que votre fonctionnalité soit compatible avec l'application sans elle (colonne supplémentaire dans DB par exemple).
Les cadres existent en plusieurs langues pour éviter de réinventer la roue, celle qui n'est plus maintenue par Etsy a un readme intéressant pour expliquer comment cela fonctionne.
Le monde du logiciel embarqué utilise souvent des indicateurs de construction, dans le code de l'application elle-même ( #define/ #ifdefinstructions, par exemple) et / ou dans les fichiers de configuration des outils de construction ( makefileles, par exemple).
Les indicateurs de construction peuvent être utilisés, de manière similaire, non seulement pour les fonctionnalités, mais aussi pour toutes sortes de refactorisation de code, migrations, prise en charge du débogage, etc.). Ils permettent de valider dans la branche d'intégration des modifications partielles ou non vérifiées sans interrompre la construction ou provoquer des régressions dans les fonctionnalités / projets qui fonctionnent déjà dans la branche. Excellent pour gérer les corrections de points aux côtés de changements de progression importants / risqués / lents (qui nécessiteraient autrement une branche à longue durée de vie) d'une manière d'intégration continue.
Mais en plus de vérifier le code de branche déjà existant pour les régressions, il est également possible d'effectuer des vérifications de progression / stabilité du nouveau code. Pour cela, les drapeaux de construction doivent être basculés.
Une façon de basculer les drapeaux serait d'utiliser, dans un pipeline de vérification distinct du système CI de la même branche (s'il prend en charge une telle fonctionnalité), un fichier de patch basculant le drapeau - à appliquer à un espace de travail séparé avant la construire. Un ensemble d'artefacts différent serait construit dans cet espace de travail, puis vérifié.
Alternativement, une branche de fonctionnalité longue durée peut être extraite de la branche d'intégration principale, mais le seul changement dans cette branche de fonctionnalité serait l'indicateur basculé. En raison de ce petit changement, la branche de fonctionnalité peut être automatiquement synchronisée extrêmement rapidement - en observant pratiquement de très près la branche d'intégration principale. Une exécution distincte de CI sur cette branche n'aurait plus besoin d'un fichier de patch préliminaire. Il serait trivial de transporter une telle branche de fonctionnalités même pendant une période de temps prolongée.
Il peut également être possible de créer, dans la branche d'intégration principale, de nouveaux artefacts de build qui ne seraient en réalité que des clones des artefacts de build existants mais avec les drapeaux basculés. De cette façon, ni le fichier de patch préliminaire ni la branche de fonctionnalité ne seraient nécessaires pour vérifier le nouveau code, directement dans la branche principale.