CI/CD y Deploy en AWS

Un pipeline de CI/CD (Continuous Integration / Continuous Delivery) automatiza el camino de un commit al código productivo. Para proyectos de IA esto incluye tests del código, validación del modelo (métricas mínimas aceptables), empaquetado del artefacto y despliegue en el entorno objetivo. Sin un pipeline, cada despliegue es manual, inconsistente y propenso a errores humanos. Con él, el mismo proceso es reproducible en cada merge.

Infrastructure as Code (IaC) es el principio de definir la infraestructura en archivos de configuración versionables en lugar de configurarla manualmente en la consola de AWS. AWS CloudFormation y AWS SAM (para serverless) son las opciones nativas; Terraform es agnóstica al cloud y muy popular en equipos multi-cloud. El beneficio clave es que puedes replicar exactamente el mismo stack en dev, staging y prod, y reconstruir todo desde cero si algo falla.

La separación de entornos (dev, staging, prod) es fundamental para proyectos de IA porque los errores en producción tienen impacto real. Dev es donde experimentas libremente; staging replica exactamente las condiciones de producción y es donde validas el modelo antes de exponerlo a usuarios reales; prod sirve tráfico real. Cada entorno debe tener sus propias credenciales, buckets S3, endpoints de SageMaker y bases de datos separados.

Las estrategias de rollback determinan qué pasa cuando un despliegue falla o un modelo nuevo degrada métricas de negocio. Blue/Green deployment mantiene dos versiones activas del endpoint (la vieja y la nueva) y cambia el tráfico gradualmente; si algo falla, el rollback es instantáneo volviendo al endpoint anterior. Canary release envía un porcentaje pequeño del tráfico a la nueva versión antes de hacer el cutover completo. SageMaker Endpoint Update soporta ambas estrategias nativamente.

Las variables de entorno y secretos en un pipeline de CI/CD nunca deben hardcodearse en el código o en los archivos de configuración del pipeline. GitHub Actions usa Secrets y Variables (cifrados en reposo). AWS CodePipeline usa Parameter Store y Secrets Manager. El patrón correcto es que el pipeline lea los secretos del vault en tiempo de ejecución y los inyecte como variables de entorno en el paso de despliegue.

El modelo de despliegue para IA tiene un paso adicional respecto al software tradicional: la validación del modelo. Antes de desplegar un modelo reentrenado, el pipeline debe comparar sus métricas (accuracy, F1, AUC) contra el modelo en producción actual. Si el nuevo modelo es peor, el pipeline debe fallar y nunca llegar a producción. Este 'model gate' es la diferencia entre un pipeline de ML maduro y uno que puede degradar silenciosamente la calidad del producto.