Aislamiento de entornos: ¿cómo gestionas dev, staging y prod con Azure CLI y suscripciones?

Seis archivos .env.example casi idénticos parecen algo concienzudo. Garantizan la deriva. Alguien actualiza tres. Prod sigue leyendo el cuarto. Los agentes y las personas resuelven rutas distintas. El repo parece configurado. El entorno real es la nube, y nadie se pone de acuerdo sobre qué suscripción está activa.

Trata el contexto de Azure CLI (suscripción, grupo de recursos, identidad) como la frontera de aislamiento. Mantén un conjunto pequeño de archivos env activos más plantillas por etapa que documenten nombres, no secretos. POC y MVP pueden compartir el código de producto y mantener etapas de despliegue separadas.

Figura 1. Los archivos describen la forma de la configuración. El contexto de Azure CLI selecciona el entorno real. El archivo correcto con la suscripción equivocada sigue siendo un éxito en el mundo equivocado.

Contexto y restricción

Un fallo habitual: la arqueología de dotenv acaba ocupando más que el trabajo en funcionalidades. Las ejecuciones locales funcionan. Los intercambios de slots fallan. El bug no está en Node. Está en cuatro plantillas que cuentan cuatro verdades ligeramente distintas sobre el mismo nombre de Key Vault.

Los secretos de la aplicación van en Key Vault y en App Settings. Las plantillas solo documentan nombres y valores por defecto que no son secretos. Unificar los ejemplos redundantes reduce los sitios donde se puede esconder la deriva. Las personas y los agentes de código deberían resolver las rutas desde una única fuente de verdad documentada, no desde la carpeta que abrieron primero.

La figura 2 es la página de Learn sobre la postura de aislamiento en la nube. La suscripción, el grupo de recursos, la identidad y los límites de red son los muros reales. Los archivos env solo nombran lo que deberían contener esos muros.

Figura 2. El aislamiento en la nube es la suscripción, el grupo de recursos, la identidad y la red. Los archivos env solo describen nombres. Fuente: Microsoft Learn: private endpoint overview.

La figura 3 explica por qué el aislamiento por etapas es una cuestión de despliegue. POC y MVP pueden compartir el código de producto y mantener etapas de despliegue y contextos de Azure CLI separados.

Figura 3. POC y MVP pueden compartir el código de producto y mantener etapas de despliegue y contextos de Azure CLI separados. Fuente: Microsoft Learn: App Service deploy best practices.

Diseño

1. Dos archivos activos y plantillas por etapa, no seis clones

Mantén un patrón mínimo de override local y plantillas explícitas por etapa (por ejemplo POC y MVP, o Test y Prod). Borra los ejemplos casi duplicados que solo cambian en un nombre de host. Si un valor es propio de una etapa, va en una plantilla de esa etapa o en Azure, no en un sexto archivo "example-final-final". La figura 4 muestra la maraña que borras frente al conjunto que conservas.

Figura 4. Un conjunto de plantillas, no seis clones. Cuando alguien proponga un séptimo ejemplo, pregunta cuál de los seis ya mintió.

2. Nombres en Git, secretos en Azure

Las plantillas enumeran los nombres de las configuraciones y apuntan a referencias de Key Vault o a App Settings. No incluyen cadenas de conexión. Los revisores deberían rechazar material secreto en los ejemplos env igual que rechazan credenciales en un commit. Para la incorporación basta con documentar los nombres.

3. El contexto de Azure CLI es el interruptor de entorno

La suscripción, el grupo de recursos y la identidad con la que despliegas definen dónde caen los cambios. Un .env correcto contra la suscripción equivocada es un despliegue con éxito en el mundo equivocado. Los scripts deberían mostrar y verificar az account show y el RG de destino antes de aplicar. Haz visible el contexto en los logs de CI. La figura 5 es la puerta antes de modificar.

Figura 5. Verifica la suscripción y el grupo de recursos antes de modificar. Que se vea en el log gana a la memoria tribal después de una tarde movida.

4. Código de producto compartido, etapas de despliegue separadas

POC y MVP pueden compartir la aplicación. No deberían compartir grupos de recursos, registros de aplicaciones sin una intención clara ni configuraciones "temporales" que se volvieron permanentes. El aislamiento por etapas es una cuestión de despliegue. Bifurcar el código para aislar entornos suele ser un error.

5. Una sola forma de resolver rutas para personas y agentes

Documenta las rutas canónicas de las plantillas, los overrides locales y los archivos de parámetros de despliegue. Los agentes de código que se inventan una tercera ubicación para los env recrean la deriva a velocidad de máquina. Pon el mapa en el README o en un documento breve de operaciones junto a las plantillas.

6. Falla en cerrado cuando faltan nombres obligatorios

Las comprobaciones de arranque o de despliegue deberían fallar cuando faltan App Settings obligatorias, en lugar de recurrir en silencio a los valores de una etapa vecina. Los valores por defecto amables que acaban en el almacén equivocado son hostiles en producción.

Los agentes hacen más ruidosa la deriva

Los agentes de código crearán encantados un .env.local2 y fijarán en el código un grupo de recursos que vieron en una transcripción antigua. Limítalos con el mismo mapa de rutas que usan las personas. Prefiere scripts que acepten --stage y resuelvan todo lo demás a partir de las plantillas documentadas y el contexto de Azure CLI. Si un agente puede inventarse un nuevo dialecto de env en una sesión, tu modelo de aislamiento ya era demasiado difuso para las personas.

Una estructura mínima de plantillas que aguanta la realidad

Una sección del README nombra el archivo de override activo, las plantillas por etapa y los destinos de Azure que describen esas plantillas. Los scripts de despliegue reciben la etapa como argumento, fijan explícitamente la suscripción y el grupo de recursos, y después aplican. Los desarrolladores locales copian una plantilla una vez y dejan los secretos fuera de Git. Cuando alguien proponga un séptimo archivo de ejemplo, pregunta cuál de los seis ya mintió. Normalmente la respuesta es "más de uno".

Muestra el id de suscripción y el grupo de recursos resueltos al principio de cada línea del log de despliegue que leen las personas. Que se vea gana a la memoria tribal cuando alguien pregunta "¿qué entorno acabamos de tocar?" después de una tarde movida.

Los nombres de etapa en los scripts deberían parecerse lo bastante a los de los grupos de recursos de Azure como para que alguien de fuera pueda relacionarlos sin un descodificador.

Errores comunes

Maraña de plantillas. Seis ejemplos, cuatro desfasados, dos incorrectos.

Secretos en Git "solo para local". Se filtran. A rotar para siempre.

Archivo correcto, suscripción equivocada. Despliegue en verde, blast radius equivocado.

Configuración del POC copiada al MVP por costumbre. Los supuestos de red e identidad viajan sin que nadie los pague.

Rutas env inventadas por agentes. La automatización amplifica el folclore.

Fallbacks silenciosos entre etapas. Key Vault equivocado, HTTP 200 correcto.

Úsalo tal cual o adáptalo

Úsalo tal cual

• Un conjunto canónico de plantillas env (número y nombres) en Git.
• Secretos solo en Key Vault / App Settings; las plantillas documentan nombres.
• Los scripts de despliegue verifican la suscripción y el RG de Azure CLI antes de modificar.
• POC y MVP (o Test/Prod) usan grupos de recursos y configuraciones de etapa separados.
• Un único mapa de rutas documentado para personas y agentes.
• El arranque o el despliegue fallan si faltan configuraciones obligatorias.

Adáptalo antes de usarlo

Menos plantillas significa menos incorporación a base de copiar y pegar y más dependencia de saber manejarse en el portal de Azure o en la CLI. Esa es la habilidad correcta para aplicaciones en la nube. Las comprobaciones estrictas de contexto añaden unos segundos a los scripts y evitan historias de despliegues erróneos que duran semanas. Compartir código entre etapas exige disciplina con los feature flags y los nombres de configuración; la alternativa son bifurcaciones divergentes que nunca se fusionan. Las referencias a Key Vault añaden piezas móviles. Ganan a los archivos env en texto plano dentro del repo.

Referencias principales: Microsoft Learn sobre Azure CLI configuration, App Service app settings y Key Vault references.

Aísla con disciplina en Azure CLI, reduce el conjunto de plantillas, mantén los secretos en Azure y haz que el contexto sea imposible de ignorar. La deriva se reduce cuando la frontera de la nube es la frontera que de verdad usas.

Relacionado

• Puertas de CI: ¿qué bloqueas de verdad en los pipelines de Azure DevSecOps? (lo que un pipeline de CI debería bloquear antes de una release)