Le développeur web aime beaucoup son ordinateur, un portable avec des autocollants subversifs dessus. Ce qu'il apprécie le plus, c'est que sur sa machine, tout fonctionne. Ensuite, c'est le drame, il faut se compromettre et mettre le code en production, sur une machine souvent moins puissante que la machine de dev, et surtout avec des utilisateurs, des gens qui font n'importe quoi et qui ne comprennent rien de toute façon. Voilà, un quart d'heure après la mise en prod, tout est pété, pourtant, on avait pourtant du Jenkins et même du Vagrant. La vie est injuste, il serait tellement plus simple de docker le portable dans une baie.
Donc voilà, il faut pouvoir tester les innovations que l'ont souhaite apporter dans le bon contexte : la production. Le staging permet d'installer l'application dans des conditions matérielles très proche du réel, mais avec un seul utilisateur : le chef de projet qui valide les changements avec son intuition et sa souris. Il faudrait quelque chose de plus réaliste.
Le A/B testing est une possibilité, mais une partie des utilisateurs se transforment en cobaye, et les actions ont réellement des conséquences. C'est un poil complexe à mettre en place.
Le load testing est pratique pour voir la résistance à la violence, mais se retrouve dépourvue face au vice ou à la malchance. Tsung propose bien des scénarios vicieux (en XML ou en enregistrant une session de référence via un proxy), mais on est encore loin de la vie réelle.
Le log replay propose une approche intéressante. On utilise les logs d'un serveur en prod pour rejouer les actions sur le serveur en staging. Bon, ok, on perd le corps des requêtes (les POST et les PUT, quoi), mais on retrouve l'usage erratique des utilisateurs.
La dernière innovation dans ce domaine est le replay proxy. Plutôt que d'attendre des logs et de considérer qu'aujourd'hui sera comme hier, on met un petit sniffer sur le serveur de prod qui va diffuser les requêtes à qui veut en UDP (pour ne pas trop gêner les autres? ce choix ressemble à du cargo cult). Des clients de replay vont alors solliciter des serveurs de staging ou de test avec de vraies données. Pour ne pas avoir à reproduire à l'échelle 1 la prod en staging, il est possible de choisir le débit de replay. Voilà, vous avez le principe de fonctionnement de Gor , un petit outil en Go, qui profite de sa facilité de déploiement (on pose l'application sur le serveur et ça suffit) et de sa capacité de parallélisation. Il ne gère que les GET (pour ne pas avoir à batailler avec la limite de taille des paquets UDP). Sa stratégie de replay et de throttle ne fonctionne que sur les sites sans session, ou chacune des requêtes sont autonomes, ce qui reste quand même courant sur le Web.
