Releases sin miedo en apps fintech: flags, kill switches y rollouts graduales

En una web, si un despliegue sale mal, vuelves a la versión anterior en minutos. En una app móvil no existe ese botón. El binario que publicaste se queda en los teléfonos de tus usuarios durante semanas o meses, y cualquier corrección pasa otra vez por la revisión de la tienda y por la decisión de cada persona de actualizar.

En una app de banca o pagos, además, un error no es un botón desalineado: es un pago duplicado, un saldo que se muestra mal o una transferencia que no se puede completar. Por eso la forma de publicar no es un tema de DevOps que se resuelve al final. Es una decisión de arquitectura que se toma semanas antes del release.

“En móvil no hay rollback del binario. El rollback es una decisión de arquitectura que tomaste antes de publicar.”

1. Asume que cada versión vivirá mucho tiempo

Siempre habrá usuarios con versiones antiguas: personas que no actualizan, dispositivos que ya no reciben la última versión del sistema o actualizaciones automáticas desactivadas. Tenerlo presente cambia varias decisiones:

• Las APIs evolucionan de forma compatible: se agregan campos, no se cambia el significado de los existentes.
• Un campo no se elimina mientras exista una versión en producción que todavía lo lea.
• El cliente tolera campos nuevos o desconocidos en las respuestas sin romperse.
• La actualización obligatoria existe, pero como último recurso: es la medida más cara para el usuario.

2. Separa desplegar de activar

La idea central es que publicar código y encender una funcionalidad sean dos eventos distintos. El código nuevo viaja en la app apagado, detrás de un feature flag, y se activa desde el servidor cuando tú decides: primero para el equipo interno, luego para un porcentaje pequeño y después para todos.

• Cada flag tiene un valor por defecto seguro para cuando la app no puede consultar la configuración, por ejemplo sin conexión.
• Las funcionalidades de riesgo arrancan apagadas: ante la duda, el comportamiento por defecto es el conocido.
• La app guarda el último valor recibido y define cuándo vuelve a consultarlo.

Con esto, el día del release deja de ser el día de mayor riesgo. El riesgo se reparte en pasos pequeños que puedes observar y detener.

3. Kill switches para todo lo que mueve dinero

Un kill switch se parece a un flag, pero su propósito es otro: apagar rápido un flujo que está causando daño, como pagar con un proveedor nuevo, un método de autenticación o una pantalla de transferencias. Para que funcione el día que lo necesitas, tiene que cumplir cuatro condiciones:

• El estado apagado está diseñado y probado: el usuario ve un mensaje claro o una alternativa, no una pantalla rota.
• Sabes cuánto tarda el cambio en llegar a los dispositivos y en qué momento la app lo lee.
• Está definido quién puede activarlo y queda registro de cada cambio.
• Se ensaya: un kill switch que nunca se probó es una esperanza, no un control.

4. Rollouts graduales en dos capas

Las tiendas ofrecen la primera capa. En el App Store, la publicación por fases reparte la actualización automática a lo largo de siete días, y en Google Play el lanzamiento escalonado te deja elegir el porcentaje de usuarios. La segunda capa son tus flags, que exponen una funcionalidad a un grupo todavía más pequeño aunque ya tenga la versión instalada.

La parte que más se olvida es decidir antes de empezar qué significa que todo va bien. Escribe los criterios para avanzar y para pausar antes del release:

• Sesiones sin crash por encima del valor habitual de la app.
• Tasa de error del flujo nuevo, medida en el servidor y en el cliente.
• Una métrica de negocio: conversión del pago, tiempo hasta completar una transferencia o contactos a soporte.

Si los criterios están escritos, pausar un rollout es una decisión técnica tranquila y no una discusión en medio de un incidente.

5. Idempotencia: la red móvil falla en el peor momento

Alguien confirma un pago dentro de un ascensor. La petición llega al servidor, el pago se procesa y la respuesta se pierde. La app ve un error y reintenta, o la persona pulsa otra vez. Sin protección, terminas con dos cargos.

La solución es que cada intención del usuario tenga una clave de idempotencia generada en el cliente y que el servidor la use para no ejecutar dos veces la misma operación. La interfaz acompaña: muestra que el pago está en proceso, evita el doble toque y, ante la duda, consulta el estado antes de reintentar.

6. Observabilidad que habla el idioma del negocio

La tasa de crashes es necesaria, pero no suficiente: un pago puede fallar sin que la app se cierre. Para saber si un release va bien necesitas seguir el flujo completo:

• Eventos que incluyen la versión de la app y el estado de los flags que vio el usuario.
• Un identificador que permite seguir la operación desde el toque en la pantalla hasta el servidor.
• Alertas sobre la métrica de negocio, no solo sobre errores técnicos.

7. Los flags también son deuda

Cada flag duplica caminos de código y estados posibles. Con decenas de flags activos, nadie sabe qué combinación ve cada usuario. Trata cada flag como algo temporal: tiene un dueño, una fecha de retiro y una tarea para eliminarlo cuando llega al cien por ciento. Los kill switches de flujos críticos son la excepción: se quedan, pero se documentan y se ensayan.

Checklist antes de publicar

• El cambio funciona con las versiones de la API que siguen en producción.
• La funcionalidad nueva está detrás de un flag con un valor por defecto seguro.
• Los flujos de dinero tienen un kill switch probado en su estado apagado.
• Los criterios para avanzar y pausar el rollout están escritos.
• Las operaciones críticas usan claves de idempotencia.
• Los eventos incluyen versión y flags para diagnosticar rápido.

Si tu equipo está diseñando un flujo de pagos o quiere revisar su estrategia de releases, puedes ver la consultoría de arquitectura iOS. Para entrenar este tipo de decisiones en un proyecto real, revisa el curso de arquitectura de software.