Utiliser le feature flipping plutôt que NODE_ENV pour activer/désactiver des fonctionnalités

27 septembre 2023

TL;DR

Pour activer ou désactiver certaines fonctionnalités, nous utilisons une approche indépendante de la variable d'environnement NODE_ENV, ce qui nous permet de contrôler ces fonctionnalités, y compris lors de l'exécution de tests automatisés. Les prochaines étapes incluent la création d'un ticket du board tech pour répertorier les utilisations de NODE_ENV dans un fichier ou un tableur, suivi d'un traitement en BSR (Board de Suivi de Réalisation).

Contributeurs

Gauthier Fiorentino, Dorian De Rosa, Guillaume Moizan

Statut

Accepté

Contexte

Dans le développement d'applications, il est courant d'avoir besoin d'activer ou de désactiver certaines fonctionnalités, telles que la journalisation avec Sentry, en fonction de l'environnement de déploiement ou des tests automatisés.

Certaines de ces activations/désactivation se font directement en testant la valeur de NODE_ENV, ce qui ne permet pas autant de souplesse qu'un feature flipping.

Décision

Nous utilisons une approche indépendante de la variable d'environnement NODE_ENV pour activer ou désactiver certaines fonctionnalités en faveur du feature flipping.

Conséquences

L'utilisation de cette approche nous donne la capacité de gérer les fonctionnalités activées/désactivées de manière flexible, indépendamment de NODE_ENV. Cela simplifie la gestion des configurations et permet de contrôler les fonctionnalités lors de l'exécution de tests automatisés.

Prochaines étapes

Nous allons créer un ticket sur le board tech pour répertorier toutes les utilisations de NODE_ENV dans nos fichiers. Une fois la liste complète, nous effectuerons un traitement en mode BSR pour effectuer les modifications nécessaires.