CAPÍTULO 10 · Operar también es desarrollar
Una versión nueva puede convivir con restos de otra
Después de diagnosticar el espacio, observamos que no todos los archivos siguen el mismo ciclo que nuestro ZIP. Algunos pertenecen al código publicado, otros a una construcción y otros a cachés que pueden persistir aparte. Si ignoramos esa diferencia, podemos interpretar una publicación exitosa como prueba de que el entorno quedó completamente renovado.
Definimos qué debe reemplazarse con cada entrega y qué puede regenerarse bajo condiciones controladas. La limpieza acompaña al inventario: no sustituye la comprensión de las rutas ni autoriza a eliminar datos persistentes. Una nueva versión debe poder ejecutarse con sus propios componentes, sin depender accidentalmente de un archivo olvidado.
Esta revisión ayuda a resolver un incidente concreto, pero el almacenamiento volverá a crecer. Para no repetir el diagnóstico solo cuando aparece un fallo, necesitamos convertir las decisiones de retención y mantenimiento en una práctica con responsables, condiciones y posibilidades de recuperación.
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
Código y caché viven en sitios distintos
Cada carril muestra un ámbito distinto. Compara sus responsabilidades antes de unir sus configuraciones.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Deploy. Reemplaza artefacto destino
- wwwroot. Contenido publicado según método
- Build. Descarga herramientas y dependencias
- Caché. Puede persistir fuera del destino
01 / EL PROBLEMA
¿Para qué sirve?
Quitar una librería de requirements.txt no necesariamente elimina herramientas descargadas ni residuos de builds previos en el entorno remoto.
02 / COMPRENDER
El concepto, explicado
--clean true en az webapp deploy limpia el directorio destino antes de publicar según el método y tipo de artefacto. No es un borrado general de /home; confirma target-path y mecanismo de despliegue.
Si Oryx construye remotamente, paquetes y herramientas pueden dejar caché fuera del contenido de la app. Si construyes en CI, el cache del runner y el de Azure son recursos distintos.
Copiar un venv de Windows a Linux no produce un build reproducible compatible. Decide artefacto, runtime, dependencias y build de destino; instala solo lo necesario y registra versiones.
/home/.cache no es el mismo concepto que Django cache/Redis ni la función Local Cache de App Service. Esta última tiene soporte condicionado y no debe recomendarse automáticamente a Linux.
Cuatro conceptos distintos
| Contenido | Propósito | Operación |
|---|---|---|
| Destino de deploy | Código y artefacto actual | Reemplazo controlado |
| Caché de herramientas | Acelerar builds | Limpieza selectiva si es regenerable |
| Django cache/Redis | Datos de caché de aplicación | Política propia de TTL e invalidación |
| Local Cache de App Service | Función de plataforma específica | Comprobar soporte y condiciones |
03 / CONSTRUIR
Implementación paso a paso
- Identifica si el build corre en CI o App Service mirando logs y settings.
- Revisa raíz del paquete, runtime y dependencias, excluyendo venv, secretos y datos persistentes.
- Confirma qué ruta y contenido se limpiará con la operación elegida.
- Conserva rollback y comprueba que bases SQLite, media o archivos de usuarios no vivan en el destino limpiado.
- Publica en un entorno de pruebas y valida arranque, estáticos y catálogo.
- Mide por separado crecimiento de caché tras el build.
04 / APLICAR
Ejemplo en SensorHub
# Azure CLI, recurso de laboratorio; el directorio destino debe estar revisado.
az webapp deploy --resource-group <RG> --name <APP> --src-path deploy.zip --type zip --clean true --restart true
# Diagnóstico Bash aparte, en Kudu/SSH:
du -sh /home/site/wwwroot
du -sh /home/.cache
# --clean no equivale a limpiar manualmente /home/.cache.
# Si el ZIP no está construido, verifica estrategia de build remoto
# y SCM_DO_BUILD_DURING_DEPLOYMENT según el método oficial.Cómo leer el ejemplo
- El comando se muestra para CLI; no implica que cualquier action de GitHub acepte un input clean.
- Los comandos remotos no se ejecutan en PowerShell local como si /home fuera Azure.
- Datos persistentes necesitan una ubicación fuera del contenido que se reemplaza.
Error habitual
Agregar clean: true a una action sin verificar su contrato, o confiar en que limpiar destino preserva SQLite guardado allí.
05 / PRACTICAR
Tu turno
Una app usa db.sqlite3 en wwwroot y quieres clean deploy. ¿Qué debe cambiar primero?
Ver solución orientativa
Migra o reubica la base en almacenamiento persistente adecuado y verifica backup/restauración. Define DATABASES, pruebas y acceso; solo luego usa un destino reemplazable para código.
06 / VERIFICAR
Cómo sabes que funciona
- Se conoce el lugar real del build.
- El artefacto no incluye entornos locales.
- Los datos sobreviven al reemplazo de código.
- La caché de herramientas se mide aparte.
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:
Mantenimiento con retención y recuperación →Continuar en modo relato