Dev, staging y production: qué es cada entorno y cómo separarlos en AWS

1. Qué es cada entorno#

Un entorno es una copia de tu aplicación con su propia configuración, datos y accesos. Casi todos los equipos usan tres: development (dev), staging y production. Los nombres importan menos que la pregunta que responde cada uno.

Development es donde pruebas tu cambio; staging es el ensayo general con una configuración lo más parecida posible a la de producción; production es lo que usan los clientes. Si dos entornos responden la misma pregunta, sobra uno.

2. En qué se diferencian de verdad#

Más allá del nombre, cuatro cosas separan un entorno de otro.

• Datos: dev usa datos sintéticos; staging, una copia reducida y anonimizada; production, datos reales. Nunca copies datos personales reales a staging sin anonimizarlos.
• Acceso: cuantos más usuarios reales, menos acceso humano. En production se entra por el proceso de despliegue, no por la consola.
• Tamaño y costo: staging suele ser una versión más pequeña de producción con el mismo código de infraestructura y otras variables.
• Alertas: un fallo en dev no despierta a nadie; uno en production sí. Configura las alertas según el entorno.

La regla útil es que staging debe fallar por las mismas razones que producción: si su configuración es distinta, lo que ves allí no predice lo que pasará.

3. Cómo separarlos en AWS#

Según la guía oficial de AWS sobre organización con varias cuentas, una cuenta de AWS actúa como límite de aislamiento para la gestión de identidad y acceso, y por defecto no hay acceso entre cuentas: si usas cuentas separadas para producción y no producción, permanecen aisladas salvo que habilites la comunicación. AWS cobra por el uso de recursos, no por el número de cuentas, así que separar no añade una tarifa.

Eso hace que una cuenta por entorno sea la opción más sólida. La tabla compara las alternativas habituales. Si ya tienes una sola cuenta, la guía de Codifly sobre cómo separar ambientes en AWS explica el paso a cuentas con unidades organizativas.

Para profundizarSeparar ambientes (dev, staging, producción) en AWS

Documentación: AWS: organizar tu entorno con varias cuentas ↗ · AWS Organizations: introducción ↗ · AWS: Well-Architected Framework ↗

4. Una regla para no tocar producción por error#

Los errores más caros ocurren al ejecutar el comando correcto en el entorno equivocado. Una comprobación pequeña antes de cada acción lo evita: verifica que la cuenta actual es la del entorno y exige confirmación para acciones destructivas en production.

CUENTAS = {"dev": "111111111111", "staging": "222222222222", "production": "333333333333"}  # IDs de ejemplo

def validar(entorno: str, cuenta_actual: str, destructiva: bool, confirmado: bool) -> str:
    esperada = CUENTAS.get(entorno)
    if esperada is None:
        return f"BLOQUEADO: entorno desconocido ({entorno})"
    if cuenta_actual != esperada:
        return f"BLOQUEADO: la cuenta {cuenta_actual} no es la de {entorno}"
    if entorno == "production" and destructiva and not confirmado:
        return "BLOQUEADO: en production las acciones destructivas exigen confirmación"
    return "OK"

print("1:", validar("staging", "222222222222", True, False))
print("2:", validar("production", "222222222222", False, False))
print("3:", validar("production", "333333333333", True, False))
print("4:", validar("production", "333333333333", True, True))

Llama a una función así desde tus scripts de despliegue y desde tu pipeline. No sustituye a los permisos de IAM, que son la defensa real, pero atrapa el error humano antes de que llegue a la API.

5. Cómo promover cambios entre entornos#

Un cambio debería viajar de dev a staging y a production sin reconstruirse.

• Construye el artefacto una sola vez y promuévelo: lo que probaste en staging es lo mismo que llega a production.
• Usa el mismo código de infraestructura en todos los entornos y cambia solo las variables.
• Prueba las migraciones de base de datos en staging con un volumen parecido al real.
• Exige aprobación antes de production y deja listo un plan de reversión.
• Guarda los secretos por entorno en un gestor, nunca en el repositorio.

Para profundizarVariables de entorno y DATABASE_URL en producción: guía completa

6. Checklist#

Antes de dar por separados tus entornos, comprueba lo siguiente.

• Cada entorno tiene su propia cuenta o, como mínimo, su propia VPC y sus propios roles.
• Staging usa datos anonimizados y producción es el único con datos reales.
• El despliegue a production exige aprobación y deja registro.
• Las alertas y los presupuestos están configurados por entorno.
• Nadie usa credenciales de production desde su máquina para trabajo diario.

Para profundizar¿Cuál es la mejor estructura organizacional para tu cuenta de AWS?