Checklist de despliegue: cómo actualizar una web y volver atrás si falla
Publicado el 2026-10-26 por frfrand
Plan práctico de despliegue, pruebas de humo, migraciones y reversión
El típico deploy de viernes: el build termina bien, pero el login deja de funcionar y recién entonces alguien pregunta si había backup. Una checklist simple evita errores repetidos, especialmente cuando el proyecto tiene una base con clientes reales.
Vamos a bajarlo a tierra: qué significa, cómo se prueba y qué pasa cuando lo usás con clientes o información real. La mayoría de los problemas no se arregla con un botón mágico, sino con pasos que podés repetir y medir.
Qué es Checklist antes de un despliegue y por qué importa
Publicar código es una secuencia de comprobaciones: versión controlada, tests, migraciones, variables, servicios, monitoreo y un plan de vuelta atrás. No hace falta un proceso corporativo enorme; bastan pasos que tu equipo realmente pueda ejecutar y verificar.
Una cosa es que una demo funcione cinco minutos y otra es sostener un servicio todos los días. Para eso necesitás límites, permisos, registros de actividad y procedimientos para resolver fallos sin improvisar.
Ejemplo de implementación o diagnóstico
# Verificaciones orientativas
git rev-parse --short HEAD
python manage.py check
python manage.py test
sudo nginx -t
sudo systemctl status miapp
curl -fsS https://api.ejemplo.com/health
# Confirmar antes compatibilidad de migraciones y datosEs una referencia didáctica, no una plantilla que debas ejecutar a ciegas en producción. Sustituí los valores de ejemplo, elegí identidades con permisos mínimos y asegurate de que ninguna clave sensible termine en un log o repositorio.
Cómo lo pondría a funcionar
- Identifica el commit y el responsable del despliegue.
- Ejecuta pruebas y prepara migraciones compatibles con la versión anterior y la nueva.
- Comprueba que exista una copia de seguridad restaurable y un plan de reversión de código y esquema.
- Publica primero en entorno de pruebas o controlado y ejecuta pruebas de humo.
- Después del despliegue, verifica el inicio de sesión, la operación con la base de datos, el webhook y la tasa de error antes de cerrar la incidencia.
Después de cada paso, verifica un resultado concreto: una acción autorizada, un estado HTTP, una tarea procesada, un costo registrado o una métrica estable. Si algo no funciona, comprueba cuál fue el primer fallo antes de reintentar en bucle.
Un ejemplo que puede aparecer en un proyecto real
Una plataforma de reservas publica una nueva forma de cobro. El backend cambia el esquema de pagos, el frontend muestra un botón nuevo y un webhook confirma. La lista de verificación obliga a probar una reserva de punta a punta antes de anunciar que terminó.
Si esa aplicación tiene varios clientes, separa contextos y recursos. Es especialmente importante cuando un chatbot o un agente puede consultar datos: la facilidad de conectar herramientas no debe saltarse los límites de privacidad y autorización.
El error más común
No confundas revertir un commit con restaurar datos: si una migración eliminó una columna, volver al código anterior puede fallar igual. Usa cambios de esquema compatibles y un procedimiento seguro.
Una configuración con buenos valores predeterminados ayuda, pero no elimina la necesidad de pruebas. Para servicios que escriben datos o disparan acciones, contempla reintentos, duplicados y fallos a mitad de camino.
¿Dónde entra ArduMaker?
Con ArduMaker puedes relacionar el repositorio Git, VPS, servicio y dominio. Documenta el commit publicado y un smoke test, incluso si el panel dice «despliegue exitoso».
Con ArduMaker puedes alojar el backend en un VPS, desplegar desde Git, configurar dominio HTTPS y utilizar herramientas de bases, servicios y MCP según el proyecto. Eso facilita reunir operaciones en un entorno, aunque las reglas de negocio y de seguridad siguen siendo responsabilidad del software.
Qué mediría para saber si mejoró
No mediría solo «funciona/no funciona». También revisaría consumo de recursos, errores, tiempos de respuesta o gasto de API, según la funcionalidad. Define una medida de éxito antes del cambio y compárala con el mismo escenario después.
Si un dato parece extraño, comprueba la muestra y la ventana temporal. Un promedio puede ocultar casos extremos, y una única ejecución exitosa no demuestra que una automatización soporte miles de solicitudes.
Preguntas frecuentes
¿Necesito una infraestructura grande para empezar? No necesariamente. Primero resuelve el problema con una arquitectura simple y mide el punto donde empieza a quedarse corta.
¿Qué pasa si falla el proveedor externo? Necesitas timeouts, política de reintentos y una respuesta útil para el usuario. No asumas que las APIs externas están siempre disponibles.
¿Cómo mantengo el control? Registra eventos importantes, separa permisos y conserva un procedimiento probado para deshacer cambios o recuperar información.
Referencias para seguir
La idea final: automatizar y medir vale la pena cuando también sabes detectar un error, limitar sus efectos y recuperarte.