“No se despliega en viernes”.

La frase suena en muchos (de verdad, muchos) departamentos de IT como si fuera una ley escrita en piedra. Como si el viernes por la tarde el código se volviera maligno, los tests se rebelaran y los servidores decidieran que ya han currado bastante por esta semana.

Pero seamos sinceros: si evitas desplegar los viernes por miedo, el problema no es el día… es tu proceso.

“No deploy on Friday” tiene sentido si lo que tienes montado es un castillo de naipes que se cae cada vez que tocas algo. Pero si ese es el caso, igual hay que mirar por qué da tanto miedo tocar producción, en vez de culpar al calendario.

Lo que de verdad deberíamos evitar no es desplegar en viernes, sino trabajar en entornos tan frágiles que haya que hacerlo con los dedos cruzados y el Slack abierto por si explota algo.

Deploy sin ansiedad. Ese es el objetivo. Y si no se puede, al menos no usemos frases como excusa para seguir igual.

😱 ¿Por qué deberías dejar de usar esta frase como dogma?

🚧 Refuerza la cultura del miedo

Decir “no deploy los viernes” es como poner una alarma de incendio porque sabes que algo va a arder.

Si tu equipo no se atreve a subir cambios un viernes, igual es que no confía en lo que hace.

Y eso no es sano. Ni para el código, ni para el equipo, ni para el que se va de finde con el móvil en modo “por si acaso”.

🧪 Bloquea la mejora continua

Si esperas a que se alineen los planetas para desplegar, lo único que vas a conseguir es juntar un montón de cambios en cada subida.

Y eso es justo lo contrario a lo que debería ser el despliegue continuo: pequeño, frecuente y sin sustos.

Subir una cosa y que rompa producción duele. Subir 20 cosas y no saber cuál lo ha roto… eso ya es trauma…

🕳️ Es una excusa para no arreglar lo importante

“No deploy on Friday” suena responsable, pero muchas veces es solo una forma educada de decir:

“Tenemos el control de versiones manga por hombro, cero monitorización, código sin testear, y el último que tocó producción ahora trabaja en otro país.”

El problema no es el viernes. Es que sabes que si algo peta, no lo vas a detectar a tiempo. Y si lo detectas… tampoco vas a saber arreglarlo sin rezar.

✅ ¿Quieres olvidarte de la frasecita? Esto es lo que necesitas (de verdad)

Porque claro, no se trata de ser valientes… se trata de estar preparados. Si quieres desplegar un viernes (o un domingo a las 3 AM si eres un alma libre), más te vale tener esto en orden:

🧪 Tests que te den confianza

Automáticos si puede ser, claro. Pero tampoco hay que obsesionarse desde el minuto uno.

Cuando el equipo es pequeño, ponerse a montar una batería de tests puede sonar a montaña imposible.

Pero al menos, monta un protocolo de pruebas básico para cubrir las rutas críticas: lo que más vende, lo que más se usa, lo que más duele si falla.

A eso le sumas tests (manuales o automáticos) de lo que acabas de tocar… y ya tienes algo bastante decente.

🚀 Un pipeline de CI/CD fiable (y aburrido)

El mejor despliegue es el que ni te enteras de que ha pasado: cero rituales, cero SSH, cero “ahora entra y cruza los dedos”.

¿Que de vez en cuando se atasca? Arregla eso antes de pensar en qué día de la semana vas a desplegar.

📦 Deploys pequeños, frecuentes y controlados

Si llevas 3 semanas sin desplegar y vas a subir 87 commits, 5 migraciones de base de datos y una refactorización “que no cambia nada”… no es que no debas desplegar en viernes. No deberías desplegar. Punto.

Haz despliegues frecuentes. Una cosa cada vez, no un buffet libre de cambios.

¿Tienes una mega funcionalidad? Pártela. Sube partes que aún no estén activas para el cliente. Valida poco a poco.

Recuerda la regla de oro: si se rompe algo y solo has subido una cosa, lo tienes claro. Si has subido cincuenta… buena suerte…

🤔 Cuándo sí puede tener sentido no desplegar un viernes

Que no se malinterprete: no somos kamikazes. Hay momentos en los que decir “mejor el lunes” es de sabios, no de cobardes.

🧩 Cambios grandes, complejos o críticos

Por ejemplo, ¿vas a cambiar de sistema de pagos?, ¿meter una migración gorda en base de datos?

Asegúrate de que, si algo falla, puedes contactar con quien haga falta (interno o externo). Porque muchas veces el problema no es tu código… sino que el soporte del proveedor cierra a las 14:00.

Esto vale para viernes. Y para cualquier día.

📅 Contextos donde el lunes es más seguro por razones de negocio

¿Tienes una campaña bestial que empieza el sábado? ¿Tu tráfico fuerte es el finde?

Entonces sí: esperar puede tener sentido. Pero que sea por una decisión estratégica y razonada.
No porque “es viernes y nos da yuyu”…

🎬 Conclusión: el problema no es el viernes

No deploy on Friday” no debería ser una norma grabada a fuego. Debería ser una señal de que algo falla en tu proceso.

Si te da miedo desplegar en viernes, no mires el calendario: mira tu pipeline, tus tests, tus backups, tu rollback.

Porque el objetivo no es evitar los problemas los viernes. Es no tener miedo a tocar producción.

Y sí, habrá excepciones. Pero lo importante es que la decisión venga de criterio, no superstición.

Así que ya sabes:

Despliega cuando quieras. Pero que no te tiemble el pulso.

Y si tiembla… mejor arregla eso. Que el viernes volverá. Cada semana. 🫠