Hay historias que empiezan bien y terminan mal… y luego están las que empiezan mal y terminan en un correo a todo el equipo con el asunto
“URGENTE: rollback inmediato”.
Sí, hablo de esa decisión cuestionable: hacer un deploy un viernes a las 5 de la tarde.
Todo comenzó con “es un cambio pequeño”
Era viernes, el reloj marcaba las 16:58.
Un compañero, con la confianza de un Jedi, dice:
“Es solo un cambio pequeño, lo subo y me voy.”
Yo, ingenuo, pensé: “Bah, no puede pasar nada… ¿verdad?”
Spoiler: podía pasar mucho.
El despliegue maldito
Se hace el deploy.
Dos minutos después:
- Los logs empiezan a llenarse de errores que nunca habíamos visto.
- El login deja de funcionar para algunos usuarios.
- El servidor, que había sido nuestro amigo toda la semana, empieza a comportarse como si tuviera vida propia.
La cadena de pánico
17:10 → Mensajes urgentes en Slack: “¿Quién tocó producción?”
17:15 → Todos los que ya estaban en la micro, el metro o en un bar, vuelven corriendo (o se conectan desde el celular).
17:20 → El jefe entra en modo supervivencia, pidiendo que “arreglemos lo más rápido posible”.
17:40 → Rollback exitoso, pero no sin sudar más que en una entrevista técnica de Google.
La lección grabada a fuego
Nunca, repito, NUNCA hagas un deploy el viernes a última hora.
No importa si es “solo una línea de código” o “un pequeño fix”.
Si algo sale mal, tu fin de semana quedará oficialmente destruido.
Protocolo anti-desastres
Planifica los deploys temprano en la semana (ideal martes o miércoles).
Ten un rollback claro y probado antes de subir cualquier cambio.
No cedas a la presión del “es rápido”.
Documenta lo que subiste, así no queda todo en el aire.
*💡 Conclusión: *
El deploy del viernes a las 5 pm no es una historia de valentía, es una leyenda de advertencia.
Quien la vive, aprende… o repite y se convierte en el protagonista de la próxima.
Top comments (0)