Modernización de runtime con CodeDeploy

Migré el runtime de una API en producción sin romper el despliegue ni la operativa, y dejé el cambio repetible en staging y producción con AMI y Terraform.

El punto de partida

Una API en producción daba servicio a una plataforma con varios entornos, y cada uno partía de una versión distinta del lenguaje. La actualización mayor del framework y del runtime no tocaba solo el código. También afectaba a la instancia (runtime y servicios) y al mecanismo de despliegue con CodeDeploy.

Un cambio así, hecho a ciegas en producción, puede tumbar un servicio entero.

Qué hice

Diseñé y conduje la migración. El objetivo real no era subir versiones, sino hacerlo sin romper CodeDeploy ni la operativa: colas, scheduler, caché y permisos.

Para eso separé dos fases. Primero validé el cambio en una instancia viva de desarrollo. Después industrialicé lo aprendido para promoverlo con el mínimo de decisiones en caliente.

Cómo lo hice

Runbook manual

Ejecuté el cambio sobre una instancia de desarrollo desechable. Seguí un runbook con baseline, checkpoints, validaciones intermedias y un rollback definido.

Dos puertas

Estructuré la validación en dos bloques, y no avanzaba si fallaba el primero:

• Bloque A, plataforma: runtime activo, intérprete de línea de comandos y del servidor web alineados, extensiones presentes y servicios arrancando sin referencias a la versión anterior.
• Bloque B, aplicación: CodeDeploy despliega el artefacto con sus hooks, y tareas, cachés, colas, scheduler y logs funcionan con el nuevo runtime.

Riesgos vigilados

Partí de los puntos donde suele romperse un upgrade así. Por ejemplo, hooks de CodeDeploy con rutas o binarios fijados a la versión antigua, sockets no reflejados en el servidor web o permisos sobre los directorios de caché.

Industrialización

Clasifiqué cada ajuste según su destino: AMI, Terraform, hooks y bootstrap de CodeDeploy, o parámetro. Ese documento une la fase manual con la declarativa.

Resultado

La migración se ejecutó de forma controlada y trazable, con CodeDeploy compatible con el nuevo runtime.

• Staging sirve para validar la repetibilidad, y producción ejecuta un procedimiento ya depurado.
• Las diferencias entre entornos quedan documentadas antes de promover.
• Cada ítem del checklist post-upgrade tiene resultado pass/fail y evidencia, para no dar el cambio por bueno por percepción.
• La AMI y el código de Terraform se apoyan en hechos verificados, no en supuestos.

Qué me llevo

Descarté industrializar directamente en Terraform, porque habría mezclado la validación funcional con la estandarización de plataforma. Separar aprender de estandarizar redujo las variables que cambiaban a la vez.

Arquitectura

baseline → upgrade en instancia de desarrollo → Bloque A (plataforma) → despliegue con CodeDeploy → Bloque B (aplicación) → AMI + Terraform → staging → producción