Migrer une automatisation Zapier ou Make vers un nouvel hôte de géocodage
Les automatisations sans code construites autour d'une étape de géocodage demandent une autre approche de migration que le code sur mesure. Voici comment gérer ce changement.
Planifier un retour arrière avant de migrer quoi que ce soit
Un plan de retour arrière est la partie d'une migration que, si elle est bien faite, personne n'a jamais besoin d'utiliser, et c'est précisément pour cela qu'elle est souvent sautée quand le temps manque. La sauter est une erreur, justement parce que le coût d'avoir besoin d'un retour arrière sans en avoir prévu est bien plus élevé que le coût d'en préparer un qui ne servira pas.
L'hypothèse de départ d'un bon plan de retour arrière est que le nouveau fournisseur se comportera différemment de l'ancien d'au moins une manière que vous n'aviez pas anticipée, aussi minutieux qu'aient été vos tests préalables. Ce n'est pas du pessimisme, c'est simplement une description honnête de la façon dont se déroulent généralement les intégrations avec des systèmes externes. Planifier autour de cette hypothèse, plutôt qu'autour de l'espoir que les tests ont tout détecté, donne un meilleur plan.
Un plan de retour arrière pour un changement de fournisseur de données de localisation doit couvrir :
- Un mécanisme de bascule rapide. Qu'il s'agisse d'un feature flag, d'une variable d'environnement ou d'une valeur de configuration lue au moment de la requête plutôt que figée dans un build déployé, les identifiants et l'endpoint de l'ancien fournisseur doivent rester valides et prêts à être réutilisés sans déploiement de code, pendant une période définie après la bascule
- Une condition de déclenchement claire. Décidez à l'avance ce qui justifierait précisément un retour arrière : un taux d'erreur au-dessus d'un certain seuil, l'échec d'une catégorie précise de requêtes ou un certain volume de plaintes d'utilisateurs, plutôt que de laisser la décision se prendre sous pression sans critère convenu
- Un responsable du retour arrière. Une personne ou un petit groupe explicitement chargé de décider du retour arrière, pour que la décision ne reste pas en suspens pendant que plusieurs personnes attendent que quelqu'un d'autre tranche
- Une date d'expiration définie pour la période de retour arrière. Garder indéfiniment les identifiants des deux fournisseurs actifs va à l'encontre de l'objectif de la migration ; fixez une date précise après laquelle l'accès à l'ancien fournisseur est définitivement supprimé
Comme les hôtes de compatibilité de My Geocode reproduisent exactement la forme des requêtes et des réponses d'un fournisseur, un retour arrière dans une migration fondée sur la compatibilité se résume souvent à un changement de configuration pour revenir à l'ancien hôte et à l'ancienne clé, sans redéployer un code d'analyse différent, ce qui réduit le temps nécessaire pour exécuter un retour arrière si besoin. Cela dit, c'est à double tranchant : cela signifie aussi qu'il vaut la peine de tester délibérément, une fois pendant la phase de planification, que le retour arrière fonctionne, au lieu de simplement le supposer, car un chemin de retour arrière non testé ne diffère pas vraiment de l'absence totale de plan de retour arrière.
Il vaut aussi la peine de décider ce qu'il advient des données ou des requêtes traitées pendant la période que vous annulez. Si une tâche par lots a tourné pendant la nuit sur le nouveau fournisseur avant qu'un problème ne soit détecté le lendemain matin, faut-il retraiter ce lot, ou l'écart est-il acceptable ? Le décider à l'avance, plutôt que pendant un incident réel, retire une décision de plus d'un moment déjà stressant.
Un plan de migration qui ne décrit que la marche en avant est, en un sens réel, un plan incomplet. La moitié consacrée au retour arrière est ce qui transforme une migration d'un pari à sens unique en une décision réfléchie qui peut être annulée proprement si les faits l'exigent.