Configuración por entornos: LOCAL, DEV y PROD
Un despliegue predecible empieza con una separación sencilla: el software define qué ejecutamos; el entorno decide dónde, con qué datos, credenciales, red y reglas lo hacemos.
En IXATU Operations esa frontera permite usar un único artefacto desde el desarrollo local hasta producción. No fabricamos una aplicación distinta para cada destino. Cambiamos su configuración.
La idea puede resumirse así:
MISMO SOFTWARE
│
artefacto
│
┌───────────┼───────────┐
▼ ▼ ▼
LOCAL DEV PROD
│ │ │
config local config DEV config PRODLa regla operacional es concreta: LOCAL valida el workspace, DEV valida el artefacto oficial y PROD ejecuta ese mismo artefacto.
Software y configuración responden preguntas distintas
La imagen contiene código compilado o empaquetado, runtime, dependencias y archivos estáticos. En una web React puede incluir el resultado del build servido por Nginx. En una API, Python, FastAPI y sus dependencias.
El entorno aporta valores que cambian sin alterar el software: URLs, credenciales, secretos, conexiones, nombres de servicios, límites, observabilidad y políticas de red.
Una variable como API_UPSTREAM ilustra la frontera. La web sabe que debe llamar a una API, pero no necesita conocer durante el build si esa API vive en Docker Compose, DEV o PROD.
software: cómo consumir API_UPSTREAM
entorno: valor concreto de API_UPSTREAMLa base de datos sigue el mismo principio. El código conserva el contrato de conexión; cada entorno proporciona host, base, identidad y secreto adecuados a su propio aislamiento.
LOCAL valida el workspace
LOCAL optimiza el ciclo de desarrollo. Docker Compose puede levantar web, API y dependencias auxiliares, conectar servicios por nombre y montar código cuando la recarga rápida aporta valor.
Su misión no es imitar cada detalle de Azure. Debe responder con rapidez si el workspace arranca, si los contratos encajan y si una vertical slice funciona de extremo a extremo.
La configuración local puede usar datos sintéticos y secretos de desarrollo. Nunca debe requerir credenciales de PROD ni convertir una copia privada de datos reales en una dependencia cotidiana.
Compose describe la topología local, pero no cambia la identidad del software. El Dockerfile y los contratos de configuración deben seguir siendo los que producirán el artefacto oficial.
DEV valida el artefacto oficial
DEV es el primer despliegue del artefacto construido por CI. La imagen se publica en un registry y Azure Container Apps la ejecuta con configuración, identidades y red propias de integración.
Aquí comprobamos algo que LOCAL no puede demostrar: que el paquete oficial arranca en la infraestructura prevista y se integra con servicios gestionados sin depender del workspace de una persona.
commit
↓
build único
↓
imagen identificada
↓
DEVDEV debe resolver su propia URL de API, su conexión de datos y sus secretos. Si una corrección exige reconstruir la imagen sólo para cambiar uno de esos valores, la frontera está mal situada.
PROD ejecuta el artefacto promovido
Promover significa autorizar en PROD la imagen que ya fue validada en DEV. La identidad debe conservarse mediante un digest o una referencia inmutable, no mediante una etiqueta ambigua que pueda moverse.
imagen validada en DEV
↓ aprobación
mismo digest en PRODNo hacemos rebuild en PROD. Reconstruir puede resolver dependencias distintas, introducir otra hora de compilación o producir bytes nuevos. Aunque parta del mismo commit, ya no sería el artefacto validado.
PROD añade su propia configuración: endpoints, escala, secretos, identidad y reglas de red. Por eso promoción no es reconfiguración: promovemos bytes; configuramos su ejecución.
ACR DEV y PROD son decisiones de aislamiento
Una organización puede usar un ACR compartido con repositorios y permisos separados, o registries distintos. Lo importante es que la promoción preserve identidad y que cada runtime sólo pueda obtener lo autorizado.
La aplicación no debería transportar credenciales de registry. Managed Identity y el rol AcrPull permiten que la infraestructura recupere la imagen sin incrustar secretos en código o variables ordinarias.
Separar entornos tampoco exige que todo tenga una réplica idéntica. Exige fronteras explícitas para que una configuración de DEV no pueda apuntar accidentalmente a datos o servicios de PROD.
Secrets, variables y configuración observable
Las variables de entorno son apropiadas para valores no sensibles y referencias. Los secretos deben vivir en el mecanismo seguro de la plataforma y llegar a la aplicación mediante referencias, no mediante el repositorio.
Registrar la configuración ayuda a diagnosticar, pero nunca se deben volcar connection strings, tokens o secretos. Es mejor registrar nombres de entorno, versiones y destinos anonimizados.
Una validación de arranque puede comprobar que faltan cero variables obligatorias, que una URL tiene el esquema esperado y que una opción pertenece al conjunto permitido. Debe fallar antes de servir tráfico.
Tres artículos propietarios para tres fronteras
El empaquetado y la ejecución pertenecen al recorrido Docker, ACR y Azure Container Apps. Allí importa distinguir imagen, registry, runtime, ingress e identidad.
La conexión al origen legacy pertenece al modelo read-only. Allí importan el adapter, los contratos Pydantic, los SELECT explícitos y el mínimo privilegio SQL.
La protección pertenece a la seguridad por capas. Allí se combinan Entra, red, identidad, permisos, secretos y aprobación humana sin atribuir a una sola capa más garantías de las que ofrece.
Un artefacto, tres pruebas diferentes
LOCAL, DEV y PROD no son tres versiones del producto. Son tres contextos que ofrecen evidencias distintas sobre el mismo software.
LOCAL reduce el tiempo de feedback del workspace. DEV demuestra que el artefacto oficial funciona en Azure. PROD ejecuta exactamente lo aprobado bajo la configuración y las restricciones de producción.
Cuando esa secuencia se respeta, una incidencia puede clasificarse mejor: código, artefacto o configuración. Esa precisión reduce deriva y convierte el despliegue en una promoción verificable.