Feature Flipping en Scala

Feature Flipping en Scala

Dans le cadre du décommissionnement de systèmes legacy vers des systèmes plus modernes, avec une deadline très courte, nous avons rencontré le problème suivant :

Comment faire cohabiter les deux systèmes afin de pouvoir migrer progressivement en limitant au maximum les cas non gérés en un temps record ?

Méthode

Dans le cadre de la migration d’un de nos projets critiques de MongoDB vers un PostgreSQL sur Google Cloud Platform avec une deadline courte, j’ai implémenté une fonction permettant d’abstraire le concept de Feature Flipping.

Si le projet est critique et massivement fréquenté, il est préférable d’utiliser la nouvelle base de données en lecture de manière progressive, tout en écrivant dans les deux bases de données.

De même, il est nécessaire de pouvoir switcher rapidement vers l’ancienne base de données en cas de problème sur la plateforme.

Implémentation

Pour cela, j’ai d’abord utilisé un type générique qui représente une fonction prenant une unique entrée :

Ce type va nous permettre de définir d’une manière abstraite nos deux fonctions A et B.

Nous aurons ainsi une fonction « newFeatureFunction » et une fonction « oldFeatureFunction »ayant les même paramètres et la même sortie.

Finalement, il nous reste à appliquer l’algorithme que nous souhaitons utiliser, notamment dans le cas où la nouvelle fonction échoue.

Dans notre cas, nous souhaitons que si la nouvelle feature échoue, l’ancienne feature prenne le relais afin d’éviter toute interruption de service pour les utilisateurs.

Ici, la fonction « handleFeatureFlipping » prend en paramètre :

• un booléen indiquant s’il faut appliquer la nouvelle feature
• un unique input du type de notre choix
• la fonction de la nouvelle feature
• la fonction de l’ancienne feature

Cette fonction nous permet également de centraliser dans le code notre algorithme, ce qui améliore la maintenabilité de notre code.

Finalement, nous allons encapsuler tout cela dans une classe afin d’obtenir tous les éléments nécessaires.

Voici un exemple d’implémentation :

Conclusion

Cet utilitaire qui permet le passage progressif d’un système ancien vers un système plus récent (cloud par exemple) s’est révélé très utile.

Nous sommes maintenant capables de tester et repérer les bugs liés à la migration sur nos différents environnements en faisant cohabiter les systèmes :

	recette et pré-production	production
Ecriture	Cloud ET MongoDB	Cloud ET MongoDB
Lecture	Cloud	MongoDB
UX	Résolution de bugs et tests	Aucun changement pour l’utilisateur

A noter que cet utilitaire peut également être utilisé pour de l’A/B testing en passant en paramètre le résultat de votre règle d’A/B testing.

Vous pouvez retrouver le code ici.