Gestión de entornos y versiones aprobadas

Automatización de despliegues en AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Mismo código, tres entornos

• Promociona una versión de Lambda de staging a prod
• Mismo artefacto, sin recompilar
• Una llamada a la API actualiza el alias de prod; el código no cambia
• Es «build once, deploy many»

Versiones aprobadas por servicio

• Lambda: los alias apuntan a versiones de la función
• ECR + ECS: etiquetas de imagen + revisiones de task definition
• API Gateway: stages con deployments
• S3: versiones de objetos en buckets con versioning

Cómo funcionan los alias de Lambda

• Una versión es una instantánea inmutable de la función
• Un alias es un puntero con nombre a una versión
• Actualiza el alias para promocionar una versión
• Los alias permiten weighted routing para canary releases

Etiquetas de ECR y task definitions de ECS

• Las imágenes de ECR son inmutables por digest
• Una etiqueta es una marca móvil sobre un digest
• Las task definitions de ECS referencian una image:tag o @digest
• En producción, ancla por digest para fijar los bits exactos

API Gateway stages, en breve

• Un stage es un deployment de la API
• Cada stage tiene su URL y historial de deployments
• Promociona desplegando la API al siguiente stage
• Las variables de stage guardan valores de ejecución por entorno

Promocionar una versión

• Construye el artefacto una vez
• Valídalo en dev y luego en staging
• Actualiza el alias o la etiqueta de prod, sin recompilar
• El mismo artefacto se ejecuta en todos los entornos

Mantener la configuración aparte

• El código no cambia entre entornos
• La configuración recoge las diferencias dev vs prod
• Stage variables, env vars, Parameter Store, Secrets Manager
• Nunca hardcodes valores de entorno en el artefacto

¡Vamos a practicar!

Automatización de despliegues en AWS