CAPÍTULO 9 · El mismo proyecto llega a Azure
La misma entrega puede viajar desde PowerShell
Ya tenemos un paquete conocido y entendemos qué debe pasar después de subirlo. La terminal ofrece otra forma de solicitar esa publicación, especialmente útil cuando la interfaz de herramientas avanzadas no admite la operación esperada. No cambia la aplicación ni convierte el proceso en despliegue automático desde GitHub.
En PowerShell utilizamos Azure CLI para identificar al operador, seleccionar suscripción y comprobar el recurso de destino antes de enviar deploy.zip. Distinguimos esa herramienta de AzCopy, cuyo propósito es transferir datos a almacenamiento. La publicación termina con una comprobación del resultado, no con la desaparición de la barra de progreso.
Ambas vías manuales conducen al mismo objetivo: ejecutar una versión identificada y verificarla. Con el procedimiento comprendido podemos mirar hacia una ampliación futura. Si el número de entregas o colaboradores crece, quizá convenga automatizar algunos pasos y preparar un entorno de staging; esa posibilidad merece entenderse sin confundirla con el método actual.
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
La consola de publicación
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
- Operador. Inicia sesión en Azure
- Destino. Comprueba app y suscripción
- Publicación. Envía paquete revisado
- Salud. Comprueba arranque real
01 / EL PROBLEMA
¿Para qué sirve?
Un comando válido puede apuntar a otra suscripción o a PROD. Hacer explícito el destino permite revisar qué recurso cambiará.
02 / COMPRENDER
El concepto, explicado
PowerShell es la consola; Azure CLI es el programa az. El módulo Az PowerShell es una herramienta distinta. Aquí elegimos az para que login, selección de cuenta y despliegue sigan el mismo recorrido.
az login autentica al operador de Azure. Esa identidad y sus permisos IAM de publicación son distintos del usuario que entra al sitio mediante MSAL. El flujo de dispositivo puede usarse cuando la política del tenant lo permite.
Antes de publicar configura el stack, las variables y el startup. El ZIP se envía con --src-path; después revisa el resultado de construcción y el arranque. Un HTTP 200 de una página genérica no demuestra que arrancó tu aplicación.
No guardes tokens de operador en el repositorio. Si más adelante automatizas CI, usa identidad federada y un alcance de permisos limitado en lugar de copiar credenciales personales.
AzCopy transfiere datos a servicios de almacenamiento; no es el comando de publicación de una aplicación web. Para enviar este deploy.zip usamos az webapp deploy, o Publish-AzWebApp si se eligió el módulo Az PowerShell. No es necesario conectar GitHub al App Service.
03 / CONSTRUIR
Implementación paso a paso
- Instala Azure CLI si falta y abre una terminal nueva.
- Inicia sesión en el tenant correcto.
- Selecciona y comprueba la suscripción.
- Consulta la app destino y revisa el archivo ZIP.
- Publica en DEV, inspecciona logs y valida antes de promover.
04 / APLICAR
Ejemplo en SensorHub
# PowerShell: los nombres son ejemplos, reemplázalos.
# Instalación inicial, si hace falta:
# winget install -e --id Microsoft.AzureCLI
$tenant = "ID-DEL-TENANT"
$subscription = "ID-DE-LA-SUSCRIPCION"
$rg = "rg-sensorhub-dev"
$app = "app-sensorhub-dev"
az login --tenant $tenant
# Alternativa si tu política lo permite:
# az login --tenant $tenant --use-device-code
az account set --subscription $subscription
az account show --query "{subscription:name,id:id,tenant:tenantId}" -o table
az webapp show -g $rg -n $app --query "{name:name,host:defaultHostName}" -o table
az webapp deploy -g $rg -n $app --src-path ../deploy.zip --type zip
if ($LASTEXITCODE -ne 0) { throw "El despliegue falló; revisar logs" }
$site = az webapp show -g $rg -n $app --query defaultHostName -o tsv
Invoke-RestMethod -Uri "https://$site/health/"Cómo leer el ejemplo
- No ejecutes las alternativas de login de forma acumulativa.
- El último request exige que implementes /health/; esta academia ya lo incluye.
- El comando puede reiniciar la app. Programa la entrega según tu disponibilidad requerida.
Error habitual
No ejecutes sobre PROD solo porque DEV respondió. Revisa migraciones, secretos y rollback como parte de otra promoción controlada.
05 / PRACTICAR
Tu turno
El login funcionó pero deploy devuelve 403. ¿Cambiarías el client secret de MSAL?
Ver solución orientativa
No: revisa IAM del operador, suscripción, tenant y acceso al endpoint SCM. MSAL del sitio es otro flujo.
06 / VERIFICAR
Cómo sabes que funciona
- El destino mostrado coincide con el entorno autorizado.
- El build termina, el proceso arranca y la comprobación funcional pasa.
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:
Publicar Django: slots, CI y ZIP Deploy →Continuar en modo relato