AMPLIACIÓN POSTERIOR
El recorrido actual publica manualmente deploy.zip y usa el dominio predeterminado. Este tema prepara una siguiente fase; no forma parte del procedimiento habitual del equipo que estamos reproduciendo.
CAPÍTULO 9 · El mismo proyecto llega a Azure
Una puerta futura hacia entregas automatizadas
El equipo publica actualmente cuando decide preparar y enviar un ZIP. Ese control manual forma parte del recorrido que estamos reproduciendo. GitHub conserva el historial, pero no está conectado como disparador obligatorio de cada despliegue. Esta distinción permite aprender el proceso real antes de introducir otra capa de automatización.
Miramos CI y staging como una evolución posible. Un proceso automatizado tendría que conservar las mismas garantías que acabamos de construir: artefacto identificable, configuración por entorno, pruebas y una forma de recuperar una entrega. Los slots, cuando el plan los admite, también requieren pensar qué configuración permanece con cada destino.
No necesitamos activar esa ampliación para terminar nuestra primera publicación. Regresamos al servicio actual, que ya dispone de un nombre proporcionado por Azure. Antes de revisar su seguridad de transporte, examinaremos otra decisión que puede llegar después: darle un dominio propio sin perder la coherencia de DNS, certificados y callbacks.
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
Promover un artefacto comprobado
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Artefacto. Vinculado al commit
- Staging / destino. Publica según estrategia
- Validación. Salud, datos y funciones
- Promoción. Swap o deploy con reversión
01 / EL PROBLEMA
¿Para qué sirve?
Que un comando publique archivos no demuestra que migraciones, configuración y dependencias sean compatibles con producción.
02 / COMPRENDER
El concepto, explicado
Ampliación posterior del recorrido: el equipo publica actualmente por ZIP manual y usa el dominio predeterminado. Esta lección conserva la base conceptual para abordar GitHub, automatización y staging cuando se decida incorporar ese flujo.
Un slot permite validar una versión y hacer swap. Está disponible en planes compatibles como Standard, Premium e Isolated; comparte recursos del plan. Un swap de código no deshace cambios de base de datos.
Sin slots puedes usar CI, un artefacto identificado, verificación y redeploy de la versión anterior. Considera una segunda app para pruebas si necesitas aislamiento de capacidad.
ZIP Deploy sirve para entrega manual o automatizada. Empaqueta el contenido en la raíz correcta: manage.py y requirements.txt, sin venv, secretos ni una carpeta contenedora inesperada.
La estrategia de build debe ser explícita: construir en CI un artefacto compatible o activar el build soportado por App Service. Migraciones compatibles y restauración de datos son decisiones independientes del despliegue.
La ruta guiada de esta unidad desarrolla preparación del ZIP, PowerShell CLI y Kudu con URL alojada en temas independientes. El mismo artefacto debe pasar primero por un entorno de prueba.
Elegir una estrategia de publicación
| Estrategia | Validación previa | Recuperación | Condición |
|---|---|---|---|
| Slot y swap | App viva en staging | Swap de código; datos requieren otro plan | Plan compatible, capacidad compartida |
| CI sin slot | CI y entorno de pruebas propio | Redeploy de artefacto previo compatible | Plan y ventana operativa definidos |
| ZIP manual | Checks locales y verificación en destino | Publicar ZIP anterior compatible | Artefacto registrado, raíz y build correctos |
03 / CONSTRUIR
Implementación paso a paso
- Ejecuta pruebas y genera un artefacto asociado al commit.
- Comprueba runtime, comando de arranque, settings y secretos del destino.
- Planifica migraciones compatibles hacia delante y copias restaurables.
- Publica en staging si existe; valida health, páginas y operaciones clave.
- Aprueba promoción según el proceso del equipo y realiza swap o deploy.
- Si falla, vuelve al artefacto anterior cuando sea compatible y ejecuta el plan específico de datos.
04 / APLICAR
Ejemplo en SensorHub
# PowerShell: ejecutar solo sobre un recurso de laboratorio autorizado.
az login --tenant <TENANT_ID>
az webapp deploy --resource-group <RESOURCE_GROUP> --name <APP_NAME> --src-path deploy.zip --type zip
# Con un slot previamente creado:
az webapp deploy --resource-group <RESOURCE_GROUP> --name <APP_NAME> --slot staging --src-path deploy.zip --type zip
# Después de verificar staging:
az webapp deployment slot swap --resource-group <RESOURCE_GROUP> --name <APP_NAME> --slot staging --target-slot productionCómo leer el ejemplo
- Los marcadores deben sustituirse y comprobarse antes de ejecutar.
- Para esta academia sincroniza catálogo y estáticos junto con las migraciones.
- El ZIP descargable trae carpeta raíz para comodidad; el ZIP Deploy se prepara con el contenido del proyecto en su raíz.
Error habitual
Suponer que volver al slot anterior restaura la base de datos o que copiar venv de Windows funciona en Linux.
05 / PRACTICAR
Tu turno
Agregas un campo que necesita la versión nueva, pero la anterior debe seguir operando durante el swap. Diseña el cambio.
Ver solución orientativa
Usa expand/contract: agrega primero un campo compatible, despliega código que soporte ambos estados, completa datos y elimina lo antiguo en una entrega posterior.
06 / VERIFICAR
Cómo sabes que funciona
- Artefacto se vincula a un commit.
- Staging no envía correos reales por accidente.
- El plan de rollback incluye compatibilidad de datos.
Para profundizar
Documentación oficial para comprobar configuración, permisos y condiciones vigentes. Revisión del tema: 2026-10-11.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Dominios personalizados, DNS y TLS →Continuar en modo relato