Publicar es un proceso, no un momento de suerte
En tu máquina funciona; en internet «depende». La diferencia no es magia: son nueve detalles que en local están resueltos sin que te hayas dado cuenta (la base de datos que ya estaba corriendo, las variables del .env, la ruta de los archivos). El checklist los hace explícitos uno a uno. Regla de oro: cada paso termina con una verificación que tú ves con tus ojos, no con «la IA dijo que listo».
[Las tres estaciones del despliegue]
Esta actividad interactiva ('Explicacion visual') requiere el motor completo de Lumbre. El contenido estatico se muestra arriba; para la experiencia interactiva, visita la version online de este objeto.
El checklist de nueve pasos
| # | Paso | Verificación con tus ojos |
|---|---|---|
| 1 | Pruebas verdes en la máquina local (M16) | suite completa ejecutada ahora, no «hace dos días» |
| 2 | Variables de producción en el servidor, NUNCA en el código (M11) | el .env del servidor existe y tu repo NO contiene secretos |
| 3 | Base de datos real creada con usuario de solo lo necesario | la app escribe y lee; un error intencional muestra 500 limpio |
| 4 | Migraciones aplicadas sobre la base vacía | las tablas existen con el esquema que tú revisaste (M08) |
| 5 | Backend corriendo como servicio que renace al reiniciar | reinicias el servidor y la app sigue respondiendo sola |
| 6 | Frontend servido y apuntando al backend correcto | navegas por el dominio, no por la IP local |
| 7 | Certificado https y redirección forzada (OA anterior) | abres http y te lleva solo al https con candado |
| 8 | Backup automático programado desde el día uno (M11) | script de respaldo ejecutado y copia visible fuera del servidor |
| 9 | Ruta de errores registrando (M12) | provocas un fallo y lo ves escrito en el log con fecha |
El prompt de despliegue por bloques
Vamos a desplegar mi app en mi VPS/plataforma (te paso los accesos por variables, no en este chat).\nHazlo POR BLOQUES, parada tras cada uno, con la verificacion que debe ver el humano:\n\nBLOQUE A: preparar artefacto de produccion (sin dependencias de desarrollo, .env de ejemplo).\nBLOQUE B: base de datos real + usuario con permisos minimos + migraciones.\nBLOQUE C: servir backend como systemd/PM2 con reinicio automatico.\nBLOQUE D: servir frontend + proxy al backend en el servidor web.\nBLOQUE E: https con renovacion automatica y redireccion forzada.\nBLOQUE F: backup automatico diario fuera del servidor + prueba de restauracion.\nBLOQUE G: logs de errores en archivo con rotacion.\n\nEn cada bloque: (1) que vas a hacer y porque, (2) ejecutas, (3) te detienes y me das la prueba visible\npara que yo confirme antes del siguiente bloque. Si algo no estoy seguro, lo dejamos y lo anoto.La prueba de fuego: el mundo real
Cuando el checklist termine, haz las cuatro cosas que tus usuarios harán y ninguna igual a tu entorno de desarrollo: ábrela desde tu celular con datos móviles (no tu wifi), crea un registro completo con un humano real (mándaselo a un amigo), escribe un email inválido a propósito (¿el validador vive?), y mata tu servidor (reinicio: ¿renace solo?). Si las cuatro pasan, no es que «funcionaba en local»: es que funciona.
Prueba
Terminaste el bloque C (backend como servicio) y la IA dice «todo desplegado, listo». Según la regla de oro del OA, ¿qué haces?
El backup automático (paso 8) puede posponerse «hasta que tenga usuarios reales».
Detecta el despliegue inseguro
Un alumno comparte su «checklist» de publicación. Señala el paso que pone en riesgo sus datos:
- Subió el .env de producción al repositorio privado «para tenerlo de respaldo».
- Configuró el servicio backend con reinicio automático.
- Provocó un error y revisó el log con marca de tiempo.
- Abrió la app desde su celular con datos móviles.
Identifica la linea con error.
Programa tu despliegue para esta semana con el prompt de bloques. Mándate el enlace a ti mismo por WhatsApp y abre la app desde datos móviles. Esa notificación es tu graduación práctica del módulo.