Estrategia de entorno de AWS cdk: ¿una por sucursal, una por desarrollador o solo desarrollo/ensayo/producción?

Estrategia de entorno de AWS cdk: ¿una por sucursal, una por desarrollador o solo desarrollo/ensayo/producción?

Actualmente estamos configurados con entornos de desarrollo, preparación y producción en AWS. Nos resulta difícil realizar el control de calidad correctamente, ya que a menudo muchas confirmaciones ocurren en un corto período de tiempo y todas están incluidas en una compilación de codepipeline, lo que dificulta asociar fallas a una confirmación específica.

Estábamos investigando la posibilidad de crear un entorno por rama de funciones, de una manera similar a lo que hace esto.ejemplo de inicio rápido de AWSestá haciendo:

ingrese la descripción de la imagen aquí

Sin embargo, me resulta difícil justificar la puesta en marcha de todo nuestro backend (que es enorme) para probar, en algunos casos, una única ruta apigateway->lambda->dynamodb. Además, esto puede funcionar para servicios sin servidor, pero también utilizamos el servidor elasticsearch. En tal caso, ni siquiera parece posible activar un servidor ES solo para probar una nueva rama de funciones. Pero si apuntamos nuestra rama de funciones a, por ejemplo, el servidor ES de prueba, ¿cómo nos aseguramos de no contaminarlo en caso de errores?

¿Cómo suele resolver la gente este problema?

información relacionada