Desplegar a producción con cada cambio puede dar miedo, pero no desplegar directamente a producción da más miedo aún.
Este es el proceso que implementé en Amazon, liderando un equipo que desplegaba para cientos de millones de clientes. A través de mi consultoría, he guiado a equipos de ingeniería desde desplegar en releases programados cada dos semanas hasta publicar en cada merge.
Empecemos por lo obvio:
Vas a causar una caída del servicio. No es un «si», sino un «cuándo».
Por más pruebas unitarias, de integración, dogfooding, end-to-end o lo que sea, y por más sacrificios que hagas a los dioses del deploy, no vas a detectar todos los bugs.
Las pruebas que hiciste a tu funcionalidad hace una semana no se probaron contra los últimos cambios de tu compañero de equipo.
Tus pruebas se hicieron contra la versión de pre-producción del servicio de tu compañero, que ahora ha cambiado e incluye un cambio que rompe la compatibilidad hacia atrás.
Cuanto más esperes, más cambios se acumulan en un release. Si necesitas hacer rollback, tendrás que revertir dos semanas de cambios en lugar de solo una o dos horas.
Si aceptamos la premisa de que una caída es inevitable, tiene mucho menos sentido dedicar recursos masivos a hacer QA de un release; en su lugar, debemos enfocar nuestros recursos en monitorear y observar un release y estar preparados para manejar una caída cuando ocurra.
Ahora, veamos cómo llegamos a eso:
Prerrequisitos:
CI/CD
Las pruebas importan mucho menos de lo que piensas. Las pruebas no pueden demostrar que tu cambio es seguro en producción. Nada puede. Lo que hacen las pruebas es abaratar el fracaso. Un bug detectado en CI cuesta minutos. Un bug detectado en producción te cuesta la noche haciendo un rollback.
Así que ejecuta la suite completa en cada merge, o al menos como parte del pipeline: pruebas unitarias, de integración y end-to-end. Cuanto más avanza el bug en el pipeline, más cuesta resolverlo.
Monitoreo/Observabilidad
El objetivo del juego es poder detectar una regresión lo antes posible. Para lograrlo, necesitas un monitoreo excelente. Esto incluye:
- métricas: errores, latencia, disponibilidad
- logs con ids de correlación
- alarmas para sev-3 y sev-2 (paging) configuradas sobre las dos anteriores
Hay algo de arte y ciencia en ajustar los umbrales de tus alarmas. Es un equilibrio entre la sensibilidad y la rapidez con la que respondes ante un incidente real. El tiempo objetivo para la alerta de sev-2 debería ser de 5 a 10 minutos.
Al principio, es probable que te equivoques y que tus alarmas sean demasiado sensibles. Desafortunadamente, esto se aprende principalmente por prueba y error, así que es probable que te despiertes un par de veces a las 2 de la madrugada.
Feature Flags
Para cualquier cambio con riesgo, deberías desplegarlo detrás de un feature flag / configuración remota. Un feature flag te permite hacer rollback y desactivar cualquier cambio en cuestión de minutos, en lugar de tener que revertir todo el despliegue. Además, si tu servicio de feature flags lo permite (y debería), puedes implementar la funcionalidad de forma incremental por porcentaje o por cohorte, reduciendo aún más el impacto de un cambio malo.
Esto nos permite desacoplar el despliegue del código de la activación del código. Es sutil, pero cambia las reglas del juego para reducir el riesgo.
Nota: necesitarás un proceso para limpiarlos. Idealmente, crea un ticket de eliminación por cada flag creado. De lo contrario, cuando tu servicio de feature flags se caiga (y se caerá), tendrás una regresión significativa. Pregúntame cómo lo sé.
Rollback Automático (Circuit breaker en tiempo de deploy)
Un circuit breaker en tiempo de deploy es una funcionalidad que te permite revertir el despliegue si ves un conteo o porcentaje de errores mientras lo despliegas en la flota. La mayoría de los proveedores de nube tienen esto con una simple casilla de verificación.
Cambios Retrocompatibles
Ya deberías estar haciendo esto, pero desplegar en cada commit obliga a esta práctica. Durante un rolling deployment, tendrás la versión antigua y la nueva ejecutándose al mismo tiempo. Cada cambio debe funcionar junto con la versión anterior. Tu truco de desplegar a medianoche para evitar esto ya no funciona.
Estrategias de Despliegue
Ahora, con todo esto en su lugar, podemos revisar algunas estrategias de despliegue que pueden ayudar a reducir el riesgo mientras despliegas tus cambios.
One box (canary)
Un despliegue one box despliega tus cambios en una sola máquina dentro de la flota completa. Esto te permite reducir el impacto de cualquier cambio malo a un solo host.
Despliegas y lo dejas correr por un tiempo, recibiendo una pequeña fracción del tráfico total. Tienes tu monitoreo y alertas configurados en esta máquina, que te alertarán si algo se rompe.
Rolling Deployments
Un rolling deployment te permite desplegar por porcentaje a lo largo del tiempo, de modo que si hay un error catastrófico, lo detectarás antes de que afecte a todas las máquinas y puedas comenzar a revertirlas.
Despliegue Regional
A medida que tu empresa crece, terminarás teniendo despliegues multi-región. En lugar de desplegar en todas las regiones simultáneamente, puedes desplegar primero en una región específica (normalmente la de menor tráfico).
Casos en los que esto no aplica
App store
Publicar una app móvil no es totalmente compatible con esta guía. La cola de revisión del app store limita tu cadencia de despliegue y requiere una estrategia diferente.
Entornos Certificados
Dispositivos médicos, aviónica, control industrial, etc. No puedes hacer despliegue continuo si necesitas que un regulador certifique el build.
On-prem / Self-hosted
No tienes control sobre la actualización. Aún puedes hacer despliegue continuo en todo lo que operas, pero tienes que versionar cada cambio y tu cliente determina cuándo se adopta.
Por dónde Empezar
No hagas todo esto a la vez. El orden importa:
- Haz que el CI esté en verde y sea rápido. Idealmente en menos de 15 minutos
- Configura métricas y alarmas sobre tasa de error, latencia y disponibilidad. Esta es la parte más importante del ejercicio
- Pon cualquier cambio riesgoso detrás de un flag
- Añade one-box + rollback automático
- Elimina el calendario de releases
- Encuentra un nuevo uso para todo tu tiempo extra ahora que ya no estarás programando releases
La mayoría de los equipos con los que he trabajado tardan alrededor de un trimestre en completar esto. Las herramientas son la parte fácil. El proceso organizacional y romper la ilusión de que los releases programados son seguros es la parte difícil.
Si tu equipo está en un calendario de releases y quiere salir de él, ese es el trabajo que hago. Mándame un DM.
