Migrar una automatización de Zapier o Make a un nuevo host de geocodificación
Las automatizaciones sin código basadas en un paso de geocodificación necesitan un enfoque de migración distinto al del código propio. Así puedes gestionar ese cambio.
Planificar una vuelta atrás antes de migrar nada
Un plan de reversión es la parte de una migración que, si se hace bien, nadie llega a necesitar nunca, y precisamente por eso se suele omitir cuando el tiempo aprieta. Omitirlo es un error justamente porque el coste de necesitar una reversión y no tenerla es mucho mayor que el de preparar una que no se llegue a usar.
El punto de partida de un buen plan de reversión es suponer que el nuevo proveedor se comportará de forma distinta al anterior en al menos un aspecto que no previste, por muy a fondo que hayas probado antes. No es pesimismo, es simplemente una descripción honesta de cómo suelen ir las integraciones con sistemas externos. Planificar en torno a esa suposición, en lugar de en torno a la esperanza de que las pruebas lo detectaron todo, da como resultado un plan mejor.
Un plan de reversión para un cambio de proveedor de datos de ubicación debe cubrir:
- Un mecanismo de cambio rápido. Ya sea un feature flag, una variable de entorno o un valor de configuración leído en el momento de la solicitud en lugar de fijado en una compilación desplegada, las credenciales y el endpoint del proveedor anterior deben seguir siendo válidos y estar listos para volver a usarse sin desplegar código, durante un periodo definido después del cambio
- Una condición de activación clara. Decide de antemano qué justificaría concretamente una reversión: una tasa de errores por encima de cierto umbral, el fallo de una categoría específica de solicitudes o un determinado volumen de quejas de usuarios, en lugar de dejar que la decisión se tome bajo presión sin un criterio acordado
- Un responsable de la reversión. Una persona o un grupo pequeño que tenga la responsabilidad explícita de decidir la reversión, para que la decisión no se atasque mientras varias personas esperan a que otra dé la orden
- Una fecha de caducidad definida para el periodo de reversión. Mantener activas indefinidamente las credenciales de ambos proveedores anula el propósito de migrar; fija una fecha concreta a partir de la cual el acceso al proveedor anterior se retire definitivamente
Como los hosts de compatibilidad de My Geocode reproducen exactamente la forma de las solicitudes y respuestas de un proveedor, una reversión en una migración basada en compatibilidad suele ser simplemente un cambio de configuración para volver al host y la clave anteriores, sin necesidad de desplegar otro código de análisis, lo que acorta el tiempo que realmente lleva ejecutar una reversión si hace falta. Dicho esto, esto funciona en ambos sentidos: también significa que vale la pena comprobar de forma deliberada, una vez durante la fase de planificación, que la reversión funciona, y no limitarse a suponerlo, ya que una vía de reversión sin probar no se diferencia en nada significativo de no tener ningún plan de reversión.
También conviene decidir qué ocurre con los datos o las solicitudes procesados durante el periodo del que te estás revirtiendo. Si un proceso por lotes se ejecutó de noche contra el nuevo proveedor antes de que se detectara un problema a la mañana siguiente, ¿hay que volver a procesar ese lote o la discrepancia es aceptable? Decidirlo de antemano, y no durante un incidente real, elimina una decisión más de un momento que ya es estresante.
Un plan de migración que solo describe cómo avanzar es, en un sentido real, un plan incompleto. La mitad dedicada a la reversión es lo que convierte una migración de una apuesta sin vuelta atrás en una decisión meditada que puede revertirse limpiamente si las pruebas así lo indican.