CAPÍTULO 9 · El mismo proyecto llega a Azure
La primera publicación se convierte en un procedimiento
Ahora podemos recorrer la entrega completa: seleccionar una versión, preparar estáticos, construir el ZIP, configurar el destino, publicar y comprobar. El valor no está solo en haber llegado una vez a una página funcionando. Está en poder explicar el mismo recorrido a otro integrante y reconocer qué evidencia demuestra cada paso.
Registramos lo publicado y revisamos los resultados antes de dar la entrega por aceptada. Si algo falla, necesitamos distinguir un problema de código, configuración o infraestructura y utilizar la recuperación preparada. Volver atrás tampoco debe depender de recordar qué carpeta local contenía la versión anterior.
La base replicable empieza a cumplir su propósito: facilita la siguiente entrega. Sin embargo, publicar no suspende la responsabilidad del equipo hasta el próximo cambio. El servicio queda atendiendo usuarios y dispositivos. A partir de aquí tendremos que observar su comportamiento y asumir que mantenerlo también forma parte del desarrollo.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
El ciclo de una entrega
Las flechas muestran transiciones del modelo. Los eventos y guardas determinan cuáles están permitidas.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Desarrollar. Cambia y prueba localmente
- Publicar. Entrega artefacto identificado
- Observar. Comprueba salud y negocio
- Aprender. Ajusta o recupera y repite
01 / EL PROBLEMA
¿Para qué sirve?
Publicar archivos es solo una parte. Una entrega también puede cambiar el esquema o el contrato de configuración y necesita una forma de detectar fallos y recuperarse.
02 / COMPRENDER
El concepto, explicado
Repite el ciclo con una mejora pequeña: desarrolla, verifica, empaqueta, publica en DEV, observa y decide la promoción. Conserva evidencia del commit, artefacto y configuración no secreta.
Migraciones se crean en desarrollo, se revisan y se versionan. En la liberación se aplican con una identidad de migración y acceso controlado, no con todos los permisos en el usuario runtime.
Separa salud del proceso, disponibilidad de dependencias y prueba funcional. Un sitio vivo puede tener su base desconectada. No expongas excepciones ni cadenas de conexión en un endpoint público.
El rollback de código no deshace una migración incompatible ni restaura datos. Prefiere cambios expandir/contraer, conserva backup probado y define cuándo revertir código o ejecutar recuperación de datos. Slots requieren un plan que los admita; el laboratorio no asume que F1 los tenga.
03 / CONSTRUIR
Implementación paso a paso
- Ejecuta pruebas y revisa cambios de esquema/configuración.
- Construye un ZIP de un commit identificado.
- Publica en DEV y aplica la migración revisada una vez en la fase prevista.
- Comprueba salud, estáticos y el caso de uso principal.
- Promueve con un plan de recuperación y observa errores, latencia y consumo.
- Si falla, clasifica el problema antes de revertir o restaurar datos.
04 / APLICAR
Ejemplo en SensorHub
# En desarrollo / CI
python manage.py check
python manage.py test
python manage.py makemigrations --check --dry-run
# En el entorno de liberación, con variables PROD y conectividad preparada
python manage.py check --deploy --settings=config.settings.production
python manage.py showmigrations --plan --settings=config.settings.production
# Tras revisar backup, compatibilidad y destino; identidad de migración:
python manage.py migrate --settings=config.settings.production
# Para actualizar solo el catálogo de esta academia:
python manage.py sync_catalog --settings=config.settings.production
# Verifica después /health/, /ready/ y un flujo funcional.Cómo leer el ejemplo
- No ejecutes makemigrations improvisadamente en Azure.
- check --deploy detecta ciertos ajustes, pero no prueba la aplicación completa ni autoriza una liberación.
- El catálogo de la academia es un paso particular; otros proyectos tienen su propio proceso de datos iniciales.
Error habitual
Borrar migraciones para arreglar un error de tablas rompe la historia compartida. Diagnostica conexión, historial y esquema antes de modificar nada.
05 / PRACTICAR
Tu turno
La versión nueva necesita una columna y quieres poder volver a la anterior. Diseña la secuencia.
Ver solución orientativa
Añade la columna de manera compatible, despliega código que soporte ambos estados, completa datos y elimina lo antiguo en otra entrega tras validar. El código anterior debe tolerar el esquema intermedio.
06 / VERIFICAR
Cómo sabes que funciona
- Puedes relacionar cada versión con un commit y artefacto.
- Existe una recuperación practicada y una prueba funcional después de publicar.
Para profundizar
Documentación oficial para comprobar configuración, permisos y condiciones vigentes. Revisión del tema: 11 de octubre de 2026.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Application Insights: observar y controlar consumo →Continuar en modo relato