Lo Que Reviso Antes de Cada Deploy

Rompí producción un viernes por la tarde. Subí un cambio de configuración que se veía bien en staging pero hacía referencia a una URL de base de datos de desarrollo en una variable de entorno.

Tiré todo el sitio por 40 minutos. Un viernes. A las 4 PM. Mi teléfono no paró de sonar.

Desde entonces tengo una checklist. No es larga. Pero la sigo cada vez. Sin excepciones. Ni siquiera para "es solo un arreglito de CSS."

La Checklist

1. Haz Diff de los Cambios

Antes de hacer deploy, miro exactamente qué va a salir. No lo que creo que cambié — lo que realmente cambió.

git diff main...HEAD

Comparo el diff contra lo que tenía la intención de cambiar. Si hay algo en el diff que no esperaba, me detengo y averiguo por qué.

Esto me ha salvado de logs de debug accidentales, datos de prueba olvidados y cambios de configuración de entorno que no me di cuenta que estaban en staging.

2. Valida los Archivos de Configuración

Los archivos de configuración JSON son frágiles. Una coma faltante rompe todo, y el mensaje de error usualmente dice algo inútil como "Unexpected token."

Pego cada archivo de configuración modificado en un validador de JSON antes de hacer deploy. Detecta errores de sintaxis que tus ojos van a pasar por alto a las 4 PM de un viernes.

3. Revisa las Variables de Entorno

Esta fue la que me atrapó. Staging y producción se ven igual, pero las variables de entorno son diferentes. URLs de base de datos, API keys, feature flags — cualquiera de estos mal puede causar fallos silenciosos difíciles de rastrear.

Tengo una lista de variables de entorno que difieren entre ambientes y verifico cada una. ¿Tedioso? Sí. ¿Mejor que tirar producción? También sí.

4. Prueba la Ruta Crítica

No corro toda la suite de tests antes de cada deploy (para eso está el CI). Pero sí pruebo manualmente la ruta crítica del usuario:

• ¿Puede un usuario registrarse?
• ¿Puede iniciar sesión?
• ¿Puede hacer la cosa principal que hace nuestro producto?
• ¿Puede pagarnos?

Si cualquiera de esas falla, todo lo demás es irrelevante.

5. Revisa el Tamaño de los Assets

Antes de hacer deploy de cambios de frontend, verifico si algún asset nuevo es irrazonablemente grande. Una imagen sin comprimir o un bundle de JavaScript sin minificar pueden destrozar tu tiempo de carga de la noche a la mañana.

Revisiones rápidas:

• Ninguna imagen mayor a 200KB (a menos que haya una buena razón)
• CSS y JS están minificados
• No se agregaron fuentes nuevas accidentalmente

6. Verifica el Plan de Rollback

¿Puedo deshacer este deploy rápidamente si algo sale mal?

Para la mayoría de proyectos, eso es git revert y redesplegar. Pero si el deploy incluye migraciones de base de datos, el rollback es más complejo. Saberlo antes de hacer deploy, no durante el incidente.

Lo Que No Está en Mi Lista

Fíjate qué falta:

• Correr todos los tests — el CI se encarga de esto. Si los tests pasan en CI, confío en ellos.
• Code review — ya pasó antes del merge. No es una actividad del momento del deploy.
• Actualizar documentación — importante, pero no un bloqueante para el deploy.

La checklist de deploy es específicamente sobre "¿esto va a romper producción?" No sobre calidad de código, documentación o proceso. Esas son importantes también, pero pasan antes.

La Regla del Viernes

Ya no hago deploys los viernes por la tarde. Si algo se rompe, quiero un día laboral completo para arreglarlo, no un fin de semana de ansiedad.

De lunes a jueves, en horario laboral. Esa es mi ventana de deploy. Hay excepciones, pero son raras y deliberadas.

---

Una checklist no es emocionante. Nadie escribe posts de blog sobre su checklist de deploy y se hace famoso. Pero el propósito de una checklist no es ser interesante — es detectar esa cosa que se te olvidó. Y solo tiene que salvarte una vez para que valga los dos minutos que toma.