Checklist mínimo antes de cerrar un despliegue interno

Introducción breve

Uso esta lista al cerrar cambios en la remasterización de alejandroperellon.es y en despliegues internos donde participo: separar “he subido ficheros” de “el entorno queda usable y reversible”.

Problema o decisión

Un despliegue interno tiene menos ceremonia que uno comercial, pero el fallo silencioso cuesta igual: alguien descubre horas después que un servicio no arranca o que los datos no cuadran. La decisión fue fijar un umbral mínimo antes de dar por cerrado el cambio, sin pretender sustituir un runbook completo.

Qué hice o cómo lo planteé

Antes de cambiar de contexto repaso, en este orden práctico:

• Rollback: qué deshago si el siguiente paso falla (versión anterior, toggle, script inverso), no solo “restaurar backup” sin procedimiento.
• Humo: la pieza visible responde; reviso logs por errores repetidos, no solo el primer 200 OK.
• Alcance: quién queda afectado y cuánto dura; si hay ventana, está comunicada.
• Datos: en migraciones o esquema, comprobación mínima de integridad o conteos esperables.
• Comunicación: otra persona del equipo sabe que hubo cambio y dónde mirar si abre incidencia.

Qué aprendí

Los cierres prematuros suelen venir de “en local iba” sin reproducir el mismo flujo en destino, de tocar código, proxy y caché a la vez sin saber qué rompió, o de asumir que nadie usa el servicio un viernes tarde. Si no puedo explicar en dos frases qué cambió y cómo volver atrás, el despliegue no está cerrado para mi umbral.

Proyecto relacionado

La remasterización del portfolio es donde más a menudo aplico esta checklist al publicar cambios en el propio sitio.