Desplegar a producción en cada cambio puede dar miedo, pero no desplegar directamente a producción da más miedo.
Este es el proceso que dirigí en Amazon, liderando un equipo que desplegaba para cientos de millones de clientes. A través de mi consultoría, he llevado a equipos de ingeniería desde despliegues con releases programados quincenalmente hasta desplegar en cada merge.
Empecemos con lo obvio:
Vas a causar una caída. No es cuestión de si, sino de cuándo.
Ninguna cantidad de pruebas unitarias, de integración, dogfooding, end-to-end o lo que sea, ni sacrificios a los dioses del deploy, atrapará todos los bugs.
Las pruebas que hiciste originalmente en tu feature hace una semana no se probaron con 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 ya cambió e incluye un cambio retroincompatible.
Mientras más esperas, más cambios se acumulan en un release. Si necesitas hacer rollback, tendrás que revertir dos semanas de cambios en lugar de solo 1 o 2 horas de trabajo.
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 cambio, deberíamos enfocar nuestros recursos en monitorear y observar el release y estar preparados para atender una caída cuando ocurra.
Ahora, veamos cómo llegar ahí:
Requisitos previos:
CI/CD
Las pruebas importan mucho menos de lo que crees. Las pruebas no pueden demostrar que tu cambio sea seguro en producción. Nada puede. Lo que hacen las pruebas es hacer que fallar sea barato. 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. Mientras más avanza el bug por el pipeline, más cuesta resolverlo.
Monitoreo / Observabilidad
La clave es poder detectar una regresión lo antes posible. Para lograrlo, necesitas un monitoreo excelente. Esto toma la forma de:
- métricas: errores, latencia, disponibilidad
- logs con IDs de correlación
- alarmas para sev-3 y sev-2 (paging) conectadas a los dos anteriores
Ajustar los umbrales de tus alarmas tiene algo de arte y de ciencia. Es un equilibrio entre la sensibilidad y la rapidez con la que respondes ante un incidente real. Tu objetivo de tiempo hasta la alerta para sev-2 debería ser de 5 a 10 minutos.
Al principio, es probable que te equivoques y que seas demasiado sensible. Desafortunadamente, esto se aprende principalmente por ensayo y error, así que probablemente tendrás algunos despertares a las 2 a. m. al principio.
Feature Flags
Para cualquier cambio con riesgo, deberías publicarlo 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 función de forma incremental por porcentaje o por cohorte, lo que reduce 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 marca un antes y un después en la reducción de riesgos.
Nota: necesitarás un proceso para limpiarlos. Idealmente, crea un ticket de eliminación por cada flag que crees. 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 una cantidad o un porcentaje de errores mientras lo despliegas por toda la flota. La mayoría de los proveedores de nube ya tienen esto con una simple casilla.
Cambios retrocompatibles
Esto ya deberías estar haciéndolo, pero desplegar en cada commit obliga a la práctica. Durante un rolling deployment, tendrás la versión anterior y la nueva corriendo al mismo tiempo. Cada cambio tiene que 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 a medida que despliegas tus cambios.
Un solo servidor (canary)
Un despliegue de tipo one box coloca tus cambios en un solo servidor dentro de la flota más grande. Esto te permite reducir el impacto de cualquier cambio malo a un solo host.
Despliegas y lo dejas reposar por un tiempo, recibiendo una pequeña fracción del tráfico total. Tienes tu monitoreo y alertas configurados en ese servidor para que te avisen si algo se rompe.
Rolling Deployments
Un rolling deployment te permite implementar los cambios por porcentaje a lo largo del tiempo, de modo que si hay un error catastrófico, puedas detectarlo antes de que afecte a todas las máquinas y entonces comenzar a revertirlas.
Despliegue regional
A medida que tu empresa crece, terminarás teniendo despliegues en múltiples regiones. En lugar de desplegar en todas las regiones al mismo tiempo, 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 aplicación móvil no es totalmente compatible con esta guía. La cola de revisión de la 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 el control de la actualización. Aun así puedes hacer despliegue continuo en todo lo que operas, pero tienes que versionar cada cambio y es tu cliente quien decide cuándo se adopta.
Por dónde empezar
No hagas todo esto de una vez. El orden importa:
- Logra que la CI esté en verde y sea rápida. Idealmente en menos de 15 minutos
- Configura métricas y alarmas para la tasa de errores, latencia y disponibilidad. Esta es la parte más importante de todo el proceso
- Pon cualquier cambio riesgoso detrás de un flag
- Agrega one-box + rollback automático
- Elimina el calendario de releases
- Encuentra un nuevo uso para todo tu tiempo extra ahora que ya no está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. La parte difícil es el proceso organizacional y romper la ilusión de que los releases programados son seguros.
Si tu equipo está en un calendario de releases y quiere salirse, eso es lo que hago. Mándame un DM.
