
Wir haben derzeit eine Entwicklungs-, Staging- und Produktionsumgebung auf AWS eingerichtet. Wir haben Schwierigkeiten, die Qualitätssicherung richtig durchzuführen, da oft viele Commits in kurzer Zeit erfolgen und alle in einem Codepipeline-Build enthalten sind, was es schwierig macht, Fehler einem bestimmten Commit zuzuordnen.
Wir wollten eine Umgebung pro Feature-Branch aufsetzen, ähnlich wie dies hierAWS-Quickstart-Beispielmacht gerade:
Ich finde es jedoch schwer zu rechtfertigen, unser gesamtes Backend (das riesig ist) hochzufahren, um in manchen Fällen eine einzige apigateway->lambda->dynamodb-Route zu testen. Darüber hinaus kann dies für serverlose Dienste funktionieren, aber wir verwenden auch den Elasticsearch-Server. In einem solchen Fall scheint es nicht einmal möglich zu sein, einen ES-Server nur zum Testen eines neuen Feature-Zweiges hochzufahren. Aber wenn wir unseren Feature-Zweig beispielsweise auf den ES-Server des Stagings verweisen, wie stellen wir dann sicher, dass wir ihn im Falle von Fehlern nicht verunreinigen?
Wie gehen die Leute normalerweise vor, um dieses Problem zu lösen?