Стратегия среды AWS cdk: одна на ветку, одна на разработчика или только dev/staging/prod?

Стратегия среды AWS cdk: одна на ветку, одна на разработчика или только dev/staging/prod?

в настоящее время мы настроены с dev, staging и prod средами на aws. Мы считаем, что сложно проводить QA должным образом, поскольку часто много коммитов происходят в короткий промежуток времени и все они включены в сборку codepipeline, что затрудняет привязку сбоев к конкретному коммиту.

Мы рассматривали возможность создания одной среды для каждой ветви функций, аналогично тому, как это сделано в этом случае.пример быстрого старта awsделается:

введите описание изображения здесь

Однако мне сложно оправдать развертывание всего нашего бэкенда (который огромен) для тестирования, в некоторых случаях, одного маршрута apigateway->lambda->dynamodb. Более того, это может работать для бессерверных сервисов, но мы также используем сервер elasticsearch. В таком случае даже не представляется возможным развертывать сервер ES только для тестирования новой ветви функций. Но если мы направим нашу ветвь функций, скажем, на сервер ES staging, как мы можем убедиться, что не загрязним его в случае ошибок?

Как люди обычно решают эту проблему?

Связанный контент