Estratégia de ambiente AWS cdk: uma por filial, uma por desenvolvedor ou apenas dev/staging/prod?

Estratégia de ambiente AWS cdk: uma por filial, uma por desenvolvedor ou apenas dev/staging/prod?

atualmente estamos configurados com ambientes de desenvolvimento, teste e produção no aws. Estamos achando difícil fazer o controle de qualidade corretamente, já que muitas vezes muitos commits acontecem em um curto espaço de tempo e são todos incluídos em uma construção de codepipeline, o que torna difícil associar falhas a um commit específico.

Estávamos pensando em criar um ambiente por ramificação de recurso, de maneira semelhante ao que esteexemplo de início rápido do awsestá fazendo:

insira a descrição da imagem aqui

No entanto, estou achando difícil justificar a ativação de todo o nosso back-end (que é enorme) para testar, em alguns casos, uma única rota apigateway->lambda->dynamodb. Além disso, isso pode funcionar para serviços sem servidor, mas também usamos o servidor elasticsearch. Nesse caso, nem parece possível girar um servidor ES apenas para testar uma nova ramificação de recursos. Mas se apontarmos nossa ramificação de recursos para, digamos, o servidor ES de teste, como podemos ter certeza de não poluí-lo em caso de bugs?

Como as pessoas geralmente resolvem esse problema?

informação relacionada