Desplegar en Viernes: ¿Mito o Realidad?

¿Deberías desplegar un viernes? Es una de las preguntas más debatidas en tecnología. Algunos juran por los “Viernes de Solo Lectura”, mientras que otros argumentan que las prácticas modernas lo convierten en un no-problema. Profundicemos.

Introducción: El Dilema del Despliegue en Viernes

La sola frase “despliegue en viernes” puede provocar escalofríos a los desarrolladores e ingenieros de operaciones experimentados. Evoca imágenes de noches largas, salas de guerra de fin de semana y la temida llamada del jefe interrumpiendo el precioso tiempo de descanso. Pero, ¿dónde se originó este miedo y sigue siendo relevante en el mundo actual de CI/CD, pruebas robustas e infraestructura resiliente?

Este post explora el antiguo debate, sopesando las preocupaciones legítimas frente a los argumentos a favor de un enfoque más flexible. Veremos los pros, los contras y algunos consejos prácticos para navegar esta difícil decisión.

El Caso en Contra: Por Qué el “Viernes de Solo Lectura” se Hizo Popular

Los argumentos tradicionales contra los despliegues en viernes se basan en el sentido común y (a menudo dolorosa) experiencia:

• Disponibilidad Reducida de Soporte: Si algo sale mal, los miembros clave del equipo podrían ser más difíciles de contactar o ya estar en modo fin de semana. Esto puede prolongar las interrupciones y aumentar el estrés.
• Impacto en las Operaciones de Fin de Semana: Un despliegue fallido puede impactar directamente los procesos críticos del fin de semana, la actividad del cliente o las ventas, lo que podría llevar a pérdidas comerciales significativas.
• Agotamiento del Equipo: Pedir regularmente a los equipos que estén de guardia o solucionen problemas durante el fin de semana conduce al agotamiento, reduce la moral y aumenta la tasa de rotación. Los fines de semana son cruciales para el descanso y la recuperación.
• El “Efecto Dominó”: Un despliegue puede parecer bien inicialmente, pero errores sutiles o degradaciones de rendimiento podrían surgir horas después, cuando hay menos ojos en el sistema.
• Ansiedad de los Interesados: Incluso si es técnicamente factible, los despliegues en viernes pueden poner nerviosos a los interesados, lo que lleva a presión y a un entorno menos indulgente si surgen problemas.

Históricamente, con procesos de despliegue más lentos y manuales y un monitoreo menos sofisticado, estos riesgos eran sustanciales. De ahí el auge de los “Viernes de Solo Lectura” o políticas que prohíben estrictamente los despliegues después, digamos, del jueves por la tarde.

El Contraargumento: Cuándo los Despliegues en Viernes Podrían Estar Bien (o Incluso Ser Necesarios)

Los tiempos han cambiado. Con las prácticas modernas de DevOps, los argumentos para ser más flexibles están ganando terreno:

• Pipelines de CI/CD Maduros: Las pruebas automatizadas, los lanzamientos progresivos (canary, blue/green) y los mecanismos de rollback automatizados reducen significativamente el riesgo de despliegue.
• Lanzamientos Más Pequeños y Frecuentes: Desplegar cambios pequeños e incrementales es inherentemente menos arriesgado que las actualizaciones masivas e infrecuentes. Si despliegas varias veces al día, el viernes es solo otro día.
• Monitoreo y Observabilidad Robustos: Las herramientas avanzadas pueden detectar rápidamente anomalías y ayudar a identificar problemas, a menudo antes de que los usuarios se vean afectados significativamente.
• Rotaciones de Guardia y Sistemas de Soporte: Los horarios de guardia bien definidos y las rutas de escalada claras pueden garantizar que el soporte esté disponible, incluso fuera de horario.
• Correcciones o Funcionalidades Urgentes: A veces, una corrección de error crítica o una funcionalidad vinculada a un evento de fin de semana debe salir. Retrasarlo podría ser más perjudicial.
• Equipos Globales: Para las empresas con equipos distribuidos en diferentes zonas horarias, el “viernes” es relativo. Un despliegue podría ser viernes para un equipo, pero madrugada para otro responsable del monitoreo.
• Equipos Empoderados y Responsables: Los equipos que son dueños de sus servicios de extremo a extremo suelen estar en la mejor posición para decidir sus ventanas de despliegue, entendiendo los riesgos y su capacidad de respuesta.

Historias del Mundo Real: Lo Bueno, lo Malo y lo Feo

Seamos honestos, la mayoría de nosotros tenemos una historia de despliegue en viernes.

• La Pesadilla del “Será Rápido”: (Comparte una historia breve y anónima de un despliegue en viernes aparentemente simple que salió mal. Ejemplo: Un pequeño cambio de configuración que se convierte en una interrupción importante debido a una dependencia imprevista, lo que lleva a un fin de semana solucionando problemas.)
• El Éxito del “En Realidad, Estuvo Bien”: (Comparte una historia donde un despliegue en viernes fue necesario y transcurrió sin problemas debido a una buena preparación o una necesidad crítica. Ejemplo: Un parche de seguridad para una vulnerabilidad de día cero desplegado un viernes por la tarde, protegiendo exitosamente el sistema durante el fin de semana.)

(Comunidad: ¡Nos encantaría escuchar sus historias en los comentarios! Manténganlas respetuosas y constructivas.)

Cómo Minimizar el Riesgo si Debes Desplegar un Viernes

Si un despliegue en viernes es inevitable, aquí tienes una checklist para hacerlo lo más seguro posible:

1. ¿Es REALMENTE necesario? Cuestiona la urgencia. ¿Podría esperar hasta el lunes por la mañana?
2. Comunica Extensamente: Informa a todos los interesados, incluidos los equipos de soporte, y asegúrate de que el personal de guardia esté al tanto y preparado.
3. Pruebas Exhaustivas: No escatimes en pruebas. Asegúrate de que todas las pruebas automatizadas estén en verde y realiza cualquier QA manual necesaria.
4. Ten un Plan de Rollback (¡Y Pruébalo!): Debes saber exactamente cómo revertir los cambios si las cosas salen mal. Idealmente, lo has practicado.
5. Despliega Temprano en el Día: Evita los despliegues a última hora de la tarde. Cuanto antes despliegues, más horas hábiles tendrás para monitorear y reaccionar.
6. Monitorea Como un Halcón: Ten dashboards listos y personal clave monitoreando activamente la salud del sistema después del despliegue.
7. Considera un Lanzamiento por Fases: Si es posible, usa canary releases o feature flags para limitar el radio de impacto de cualquier problema potencial.
8. Verificaciones de Sanidad Post-Despliegue: Realiza un conjunto predefinido de verificaciones para confirmar que la funcionalidad crítica funciona como se espera.
9. Prepárate para un Posible Fin de Semana: Asegúrate de que los involucrados sepan que podrían necesitar estar disponibles si surgen problemas más tarde.

Conclusión: Se Trata de Madurez, No Solo del Calendario

Entonces, ¿deberías desplegar un viernes? La respuesta, insatisfactoriamente, es: depende.

No hay una regla universal. Prohibir los despliegues en viernes por completo podría ser una corrección excesiva en una organización madura con prácticas de DevOps sólidas. Por el contrario, permitirlos sin las salvaguardas adecuadas en un entorno menos maduro es buscar el desastre.

La decisión debe basarse en la tolerancia al riesgo de tu organización, la madurez de tus prácticas de desarrollo y operativas, la naturaleza del cambio y la preparación de tu equipo. En lugar de un “no” generalizado, apunta a una cultura de evaluación de riesgos, preparación y mejora continua que haga que cualquier despliegue, en cualquier día, sea lo más seguro y predecible posible.

¿Cuál es tu opinión? ¿Los despliegues en viernes son un no rotundo o simplemente otro día en la oficina? ¡Comparte tus pensamientos abajo!