Résolution d'une erreur de production

Vous êtes-vous déjà demandé comment déboguer une application lorsqu'elle est en cours de production? Fiddler Everywhere vous aide à faire exactement cela … sans affecter vos systèmes de production!

Si vous nous suivez dans cette série de blogs, vous saurez que je suis un assez grand fan de Fiddler . La capacité d'inspecter et de déboguer les requêtes et réponses HTTP / S des applications de tous types (bureau, Web et mobile) peut être un élément essentiel de notre expérience de développement et de débogage.

Fiddler Everywhere est une toute nouvelle version de Fiddler. La plupart de ce que vous aimez (et rien de ce que vous détestez) à propos du Fiddler original se trouve dans Fiddler Everywhere. C'est un outil multiplateforme qui inclut une expérience repensée qui fonctionne de manière identique sur macOS, Linux et Windows.

REMARQUE: Fiddler Classic (le Fiddler original) ne va nulle part! Vous pouvez toujours télécharger Fiddler et l'utiliser comme vous l'avez toujours fait sur Windows.

Aujourd'hui nous amène à la quatrième partie des scénarios de débogage courants que beaucoup d'entre nous ont rencontrés. Nous rencontrons des échecs d'API distantes, nous recherchons des erreurs 404 et 500 et, comme aujourd'hui, nous essayons de répliquer et de résoudre les problèmes signalés par les clients alors qu'une application est déjà en production. Yikes! ?

Si vous êtes juste à l'écoute, assurez-vous de consulter quelques autres articles de cette série:

Au sujet du nouvel outillage Fiddler – jetez un œil à Fiddler Jam si vous souhaitez inspecter les problèmes des clients distants!

Passons au problème redouté de ne pas pouvoir répliquer localement une erreur de production. Nous y avons tous été. Lorsque nous ne pouvons pas diagnostiquer efficacement une erreur au niveau de la production, il est évidemment difficile de déboguer, de tester et finalement de résoudre un changement.

Notre scénario: résoudre une erreur de production … en production

En tant que développeur Web, j'ai vu des clients surgir des problèmes qui affichent une erreur dans l'environnement de production de mon application. Malheureusement, avec les informations dont je dispose, il m'est pratiquement impossible de reproduire le problème localement en raison de l'un des facteurs suivants.

L'erreur ne semble se produire …

• qu'après que les scripts ont été minimisés pendant le processus de construction
• lorsque les fichiers sont servis à partir d'un CDN
• parce que mon application fait partie d'une solution monolithique massive qui ne peut pas être exécutée localement

La solution de Fiddler Everywhere

En utilisant Fiddler Everywhere, nous allons simuler notre application et faites-lui penser qu'il fonctionne en production. Mais au lieu de charger les éléments clés de notre environnement de production, nous allons dire à notre application de production de les charger à partir d'une source différente (dans ce cas, notre bureau local).

De cette façon, nous pouvons exécuter la plupart de l'application "en production , "tout en chargeant des scripts / fichiers / tout ce que nous soupçonnons comme étant les coupables, depuis notre machine de développement locale. Pour ce faire, nous pouvons tirer parti de la fonction Auto Responder de Fiddler Everywhere.

Voyons comment cela fonctionne dans la pratique:

1. Ouvrez Fiddler Everywhere et basculez l'option Live Traffic sur Capture :

   actions supplémentaires du répondeur automatique que vous pouvez expérimenter aujourd'hui:

   en le téléchargeant aujourd'hui pour macOS, Linux ou Windows.

2. Découvrez un nouveau produit passionnant de la famille Fiddler: Fiddler Jam . [19659013] Profitez du reste de votre été (ou de l'hiver pour vous, les gens de l'hémisphère sud!) Et restez en sécurité là-bas. ?