My Geocode

Migration

Une checklist pour faire fonctionner deux fournisseurs en parallèle

· 3 min de lecture · My Geocode · #checklist-de-migration#géocodage#double-fournisseur#architecture#tests

Faire fonctionner deux fournisseurs en même temps est généralement un état délibéré et temporaire pendant une migration, pas une architecture permanente, mais cela demande assez de structure pour ne pas devenir un enchevêtrement confus de logique conditionnelle disséminée dans le code. Une checklist aide à garder cette phase courte et son objectif clair.

Avant de commencer à envoyer du trafic réel à un second fournisseur :

  • Vérifiez que les formats de réponse des deux fournisseurs ont été mis en correspondance avec une structure de données interne commune, afin que le code de votre application lise un seul format normalisé, quel que soit le fournisseur qui a effectivement répondu à une requête donnée
  • Décidez dès le départ de la logique de répartition : pourcentage du trafic, endpoints précis, segments de clientèle précis, ou mode fantôme où le second fournisseur est appelé mais où son résultat est seulement journalisé, sans être utilisé
  • Mettez en place une journalisation ou un marquage séparé pour pouvoir savoir après coup quel fournisseur a servi une requête donnée, ce qui compte énormément lorsque quelque chose tourne mal et que vous devez savoir où regarder en premier

Pendant que les deux fournisseurs sont actifs :

  • Comparez régulièrement les taux d'erreur et les temps de réponse des deux, pas seulement une fois au début, car le comportement peut dériver sur des jours ou des semaines d'une manière qu'un seul test initial ne détecterait pas
  • Surveillez les écarts entre les résultats réels des deux fournisseurs pour une même entrée, et définissez un processus de décision clair pour les cas où ils divergent, plutôt que de supposer que l'un a tout simplement raison
  • Tenez à jour une liste de tous les schémas de requête qui se comportent sensiblement différemment entre les deux, car ce sont précisément les cas qui méritent d'être testés plus à fond avant de retirer l'ancien fournisseur

Avant de retirer le fournisseur d'origine :

  • Vérifiez que chaque chemin de code susceptible d'appeler l'ancien fournisseur a réellement été exécuté avec le nouveau, pas seulement les cas courants
  • Recherchez toute logique de repli codée en dur qui suppose que l'ancien fournisseur est toujours disponible, car les périodes à double fournisseur laissent parfois derrière elles du code de repli que personne ne pense à supprimer
  • Fixez une date précise pour couper l'ancien fournisseur plutôt que de laisser la période à double fournisseur s'éterniser, car une transition sans échéance a tendance à ne jamais vraiment se terminer

Les hôtes compatibles de My Geocode sont conçus précisément pour rendre la première moitié de ce processus, la normalisation du format de réponse, en grande partie inutile si le fournisseur que vous quittez dispose déjà d'un hôte correspondant, car le format reste identique à l'original et votre code de normalisation existant (si vous en aviez) continue de fonctionner sans modification. La liste complète des 17 hôtes compatibles se trouve sur /compatibility/. Chaque requête transporte aussi des en-têtes de quota, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining et d'autres, documentés sur /docs/rate-limits/, qui sont utiles pour l'étape de journalisation comparative ci-dessus, quel que soit le fournisseur évalué en second.

Une période à double fournisseur bien menée est courte, bien instrumentée et se termine à une date prévue. Mal menée, elle devient un élément permanent et déroutant. La différence tient presque entièrement au fait qu'une checklist comme celle-ci soit suivie plutôt qu'ignorée sous la pression des délais.

Plus d'articles sur la migration