Catégories
Astuces et Design

Comment désactiver le code: le commutateur d'arrêt de production du développeur

Ce qui suit est un post invité écrit par Carlos Schults.

La possibilité de désactiver le code en production est une puissance que de nombreux développeurs ne connaissent pas. Et c’est dommage. La possibilité de désactiver certaines parties – ou même des fonctionnalités complètes – de la base de code peut considérablement améliorer le processus de développement logiciel en permettant les meilleures pratiques qui peuvent raccourcir les cycles de rétroaction et augmenter la qualité globale.

Voilà donc ce que cet article couvrira: les mécanismes que vous pouvez utiliser pour effectuer cette désactivation, pourquoi ils sont utiles et comment commencer. Creusons.

Pourquoi voudriez-vous désactiver le code?

Avant de nous plonger dans les indicateurs de fonctionnalités, d'expliquer ce qu'ils sont et comment ils sont mis en œuvre, vous vous demandez peut-être: pourquoi les gens voudraient-ils désactiver certaines parties de leur base de code? Quel est l'avantage de faire cela?

Pour répondre à ces questions, nous devons remonter dans le temps pour voir comment le logiciel a été développé il y a quelques décennies. Il est temps pour une leçon d'histoire!

The Dark Ages: Integration Hell

Historiquement, l'intégration a été l'un des défis les plus difficiles pour les équipes essayant de développer ensemble des logiciels.

Imaginez plusieurs équipes au sein d'une organisation, travaillant séparément pendant plusieurs mois, chacune développant sa propre fonctionnalité. Alors que les équipes travaillaient dans un isolement complet, leurs versions de l'application évoluaient dans des directions différentes. Maintenant, ils doivent à nouveau converger en une seule version non conflictuelle. Il s'agit d'une tâche herculéenne.

C’est ce que signifie «l’enfer de l’intégration»: la lutte pour fusionner des versions de la même application qui ont été autorisées à diverger trop longtemps.

Entrez dans la solution: intégration continue

"Si ça fait mal, faites-le plus souvent." Ce que signifie ce dicton, c'est qu'il y a des problèmes que nous différons à résoudre parce que le faire est difficile. Ce que vous rencontrez souvent avec ce genre de problèmes, c'est que les résoudre plus fréquemment, avant qu'ils ne s'accumulent, est beaucoup moins douloureux, voire trivial.

Alors, comment pouvez-vous rendre les intégrations moins douloureuses? Intégrez plus souvent.

C'est une intégration continue (CI) en un mot: demandez à vos développeurs d'intégrer leur travail à un référentiel public partagé, tout au moins une fois par jour. Demandez à un serveur de déclencher une génération et d'exécuter la suite de tests automatisés chaque fois que quelqu'un intègre son travail. De cette façon, s'il y a des problèmes, ils sont exposés le plus tôt possible.

Comment gérer les fonctionnalités partiellement terminées

Un défi auquel de nombreuses équipes doivent faire face dans CI est de savoir comment gérer les fonctionnalités qui ne sont pas complètes. Si les développeurs fusionnent leur code avec la ligne principale, cela signifie que tous les développements qui prennent plus d'une journée à terminer devront être divisés en plusieurs parties.

Comment éviter que le client accède à des fonctionnalités inachevées? Il existe des scénarios triviaux avec des solutions tout aussi triviales, mais des scénarios plus difficiles nécessitent une approche différente: la possibilité de désactiver complètement une partie du code.

Drapeaux à la rescousse

Définition des indicateurs de fonctionnalité

Il existe de nombreux noms pour les mécanismes qui permettent aux développeurs d'activer et de désactiver une partie de leur code. Certains les appellent «bascule de fonction» ou «coupe-circuit». Mais "indicateurs de fonctionnalité" est le nom le plus populaire, c'est donc ce que nous utiliserons pour le reste de ce post. Alors, quels sont les indicateurs de fonctionnalité?

En termes simples, les indicateurs de fonctionnalité sont des techniques qui permettent aux équipes de modifier le comportement d'une application sans modifier le code. En général, les indicateurs sont utilisés pour empêcher les utilisateurs d'accéder et d'utiliser les modifications introduites par un morceau de code, car elles ne sont pas encore adaptées à la production pour un certain nombre de raisons.

Désactiver le code: quels sont les cas d'utilisation?

Nous allons maintenant couvrir certains des cas d'utilisation les plus courants pour désactiver le code en production.

Désactivation des fonctionnalités inachevées

Comme vous l'avez vu, l'un des principaux cas d'utilisation des indicateurs de fonctionnalité empêche les utilisateurs d'accéder à des fonctionnalités qui ne sont pas encore prêtes à l'emploi.

De cette façon, les programmeurs développant des fonctionnalités plus complexes et plus longues à terminer ne sont pas empêchés d'intégrer leur travail souvent et d'en bénéficier.

Activation des tests A / B

L'adoption de drapeaux de fonctionnalités permet l'utilisation de plusieurs pratiques précieuses dans le processus de développement logiciel, dont l'une est Test A / B.

Le test A / B est une technique de recherche sur l'expérience utilisateur qui consiste à comparer deux versions d'un site Web ou d'une application pour décider laquelle conserver. Cela implique de diviser au hasard les utilisateurs en deux groupes, A et B, puis de livrer une version différente de l'application à chaque groupe. Un groupe pourrait recevoir la version de production actuelle, que nous appelons le «contrôle», tandis que le deuxième groupe recevrait le candidat pour la nouvelle version, appelée le «traitement».

Les testeurs surveillent ensuite le comportement des deux groupes et déterminent laquelle des versions a obtenu de meilleurs résultats.

Les indicateurs de fonctionnalité sont un moyen pratique d'activer les tests A / B car ils vous permettent de basculer rapidement et facilement entre les versions de contrôle et de traitement de votre application.

Activation des versions Canaries

Si vous livrez la nouvelle version de votre application à l'ensemble de votre base d'utilisateurs en même temps, 100% de vos utilisateurs seront affectés si la version est mauvaise d'une manière ou d'une autre. Et si vous pouviez progressivement déployer la nouvelle version à la place? Vous devez d'abord déployer sur un petit sous-ensemble d'utilisateurs, en surveillant ce groupe pour détecter les problèmes. Si quelque chose tournait mal, vous pouvez le faire reculer. Si tout allait bien, vous pourriez ensuite libérer progressivement la version pour les grands groupes. C'est un libération des canaris en un mot. C'est une autre technique puissante avec des indicateurs qui pourrait vous aider.

Personnalisation des fonctionnalités selon les préférences des utilisateurs

Il n'est pas rare de devoir personnaliser votre application en fonction des besoins d'utilisateurs spécifiques, et il existe plusieurs façons pour les équipes logicielles de le faire, certaines plus efficaces et d'autres moins (les entreprises qui créent des succursales distinctes ou des référentiels entiers pour chaque client). venir à l'esprit).

C'est un autre domaine où les indicateurs de fonctionnalité pourraient aider, permettant aux équipes de basculer dynamiquement entre différentes versions de la même fonctionnalité.

Désactiver le code en production 101

Comment procédez-vous pour désactiver le code? C’est ce que nous allons voir maintenant, en trois phases de plus en plus sophistiquées.

Première étape: l'approche la plus élémentaire

Nous commençons par une approche si primitive, elle ne devrait peut-être pas du tout être considérée comme un indicateur de fonctionnalité. Considérez le pseudocode ci-dessous:

calculateAdditionalWorkHours(Employee employee, Date start, Date end) {
  // return calculateAdditionalWorkHoursSameOldWay(employee, start, end);
  return calculateAdditionalWorkHoursImproved(employee, start, end);
}

Dans le code ci-dessus, nous commentons simplement l'ancienne version d'une méthode et la remplaçons par une nouvelle version. Lorsque nous voulons que l'ancienne version soit utilisée, nous faisons juste le contraire. (Eh bien, j'ai dit que c'était primitif.) Cette approche n'a pas l'une des propriétés les plus fondamentales d'un indicateur de fonctionnalité: la capacité de changer le comportement de l'application sans changer son code.

Cependant, il plante la graine pour des approches plus sophistiquées.

Deuxième étape: retirer la décision du code

L'approche précédente ne permettait pas aux développeurs de sélectionner la version souhaitée de la fonctionnalité sans modifier le code. Heureusement, ce n'est pas si difficile à faire. Tout d'abord, nous introduisons une variable logique pour déterminer la version que nous allons utiliser:

calculateAdditionalWorkHours(Employee employee, Date start, Date end) {

  var result = useNewCalculation
    ? calculateAdditionalWorkHoursImproved(employee, start, end)
    : calculateAdditionalWorkHoursSameOldWay(employee, start, end);

  return result;
}

Ensuite, nous utilisons un mécanisme pour pouvoir attribuer la valeur à la variable à partir d'une source externe. Nous pourrions utiliser un fichier de configuration:

var useNewCalculation = config(newCalculation);

La transmission d'arguments à l'application peut être une autre option. Ce qui importe, c'est que nous avons maintenant la possibilité de modifier le comportement de l'application de l'extérieur, ce qui est un grand pas vers le "vrai" signalement des fonctionnalités.

Gardez à l'esprit que les exemples de code que vous voyez sont tous des pseudocodes. En utilisant votre langage de programmation préféré, rien ne vous empêche de commencer avec cette approche et de la prendre d'un cran. Vous pouvez, par exemple, utiliser des classes pour représenter les fonctionnalités et les modèles de conception (par exemple, les usines) pour éviter les instructions if.

Étape 3: Gestion complète des indicateurs de fonctionnalité

L'approche précédente peut être suffisante lorsque votre application n'a qu'un petit nombre d'indicateurs. Mais à mesure que ce nombre augmente, les choses commencent à devenir désordonnées.

Premièrement, vous avez le problème de la dette technique. Les indicateurs de fonctionnalité implémentés manuellement peuvent créer des flux conditionnels extrêmement déroutants dans votre base de code. Cela ne fait qu'empirer avec l'introduction de nouveaux drapeaux chaque jour. De plus, ils pourraient rendre le code plus difficile à comprendre et à naviguer, en particulier pour les développeurs plus juniors, ce qui est une invitation aux bogues.

Un autre problème est qu'à mesure que le nombre de drapeaux augmente, il devient de plus en plus courant d'oublier de supprimer les anciens, obsolètes.

Le principal problème d'une approche locale est qu'elle ne vous donne pas un moyen facile de voir et de gérer tous vos indicateurs à la fois. C'est pourquoi notre troisième et dernière étape est un seul conseil: au lieu de déployer votre propre approche des indicateurs de fonctionnalités, adoptez un système de gestion des indicateurs de fonctionnalités tiers.

Les indicateurs de fonctionnalité sont un catalyseur CI / CD

Nous avons couvert les mécanismes que les développeurs peuvent utiliser pour désactiver des parties de leur base de code en production sans avoir à toucher au code. Cette capacité est puissante et permet des techniques telles que les tests A / B et les versions canaries, qui sont toutes les caractéristiques d'un processus de développement logiciel moderne et agile.

Les noms des techniques peuvent varier: indicateurs de fonctionnalité, basculement de fonctionnalité, retournement de fonctionnalité, etc. La manière dont les techniques sont mises en œuvre peut également varier, de la simple déclaration if aux solutions sophistiquées basées sur le cloud.

Mais peu importe comment vous les appelez, vous ne pouvez pas surestimer les avantages de ces mécanismes. Ils facilitent l'intégration continue, ce qui est essentiel pour toute organisation logicielle moderne qui souhaite rester à flot.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *