Im Zuge der Migration von einer monolithischen zu einer Microservices-Architektur haben wir erhebliche Änderungen an den Tools und Prozessen vorgenommen, um mehrere hochwertige Softwareversionen pro Tag zu unterstützen
Das Problem
Bei FloQast begannen wir mit einem monolithische Softwarearchitektur, aber als die Anzahl der Produkte und Scrum-Teams zunahm, begannen wir mit der Umstellung auf ein Architektur, die auf Microservices basiert. Anfänglich, während dieser Umstellung, nutzten wir weiterhin die gemeinsame QA-Umgebung (ein Überbleibsel aus der Monolith-Bereitstellungsphase) für umfassende Tests vor der Bereitstellung in die Produktion. Als die Anzahl der Microservices zunahm, stießen wir auf Engpässe in unserer QA-Umgebung. In der QA-Umgebung gefundene Fehler führten aufgrund des Fix-Deploy-Verificy-Zyklus zu einer Verzögerung von einigen Stunden und verzögerten bevorstehende Releases für dieselben oder abhängige Dienste. Dies lag in erster Linie daran, dass die Dienste zum ersten Mal in einer Produktionsumgebung bereitgestellt wurden, die andere Dienste enthielt und realistischeren Testdaten ausgesetzt war.
Die Lösung

Um diesen Engpass zu beheben, haben wir den gesamten Release-Prozess, die Infrastruktur und die Tools noch einmal unter die Lupe genommen und einige Verbesserungen vorgenommen, die in der Abbildung oben dargestellt und unten beschrieben werden:
Lokale Entwicklungsumgebungen eingeführt
Wie die meisten unserer Microservices Dockerisiert und in einem Docker-Container ausführen, den unser Entwicklerteam genutzt hat Docker Compose um lokale Entwicklungsumgebungen zu erstellen, die einen Großteil unserer Microservices enthalten. Für Services, die AWS-Services nutzen (Lambda usw.), verwendeten wir lokale Testtools, die von AWS bereitgestellt wurden, wie SAM lokal. Dies ermöglichte es Entwicklern, ihre Codeänderungen lokal auf integrierte Weise zu testen, bevor sie Pull-Requests erstellten.
Erstellung von AWS-Testumgebungen pro Scrum-Team
Bei FloQast sind wir voll und ganz auf AWS und das DevOps-Team von FloQast hatte bereits angefangen Terraforming die gesamte AWS-Infrastruktur als Code. Für Teams, die in der gemeinsamen QA-Umgebung auf Engpässe stießen, schuf DevOps mithilfe von Terraform produktionsähnliche Umgebungen. Um die Kosten unter Kontrolle zu halten, haben wir diese Umgebungen mit nur der Teilmenge der Dienste erstellt, die für jedes Team benötigt werden, und im Vergleich zur Produktion wurden geringere Instanzgrößen verwendet. Dann richten wir nach Jenkins geplante Jobs ein, um die Dienste täglich auf dem neuesten Stand zu halten, während die Niederlassung in der Produktion eingesetzt wird.
UI/API-Tests für die Ausführung in mehreren Umgebungen konfigurieren
Nachdem wir diese Testumgebungen pro Team erstellt hatten, haben wir unsere UI/API-Testkonfigurationen so geändert, dass sie erfolgreich in Umgebungen mit mehreren Teams ausgeführt werden konnten. Dies beinhaltete die Suche nach einer zuverlässigen Methode zum Füllen und Verwalten von Testdaten in mehreren Umgebungen.
Optimierung der Testphase der CI/CD-Pipeline jedes Microservices
Microservices sollen unabhängig einsetzbar und testbar sein. Deshalb haben wir uns die Funktionen der einzelnen Microservices angesehen und Tests aus unserer wichtigsten UI/API-Testautomatisierungssuite ausgewählt, die für den jeweiligen zu testenden Microservice gelten. Dadurch wurde der Feedback-Zyklus für die Fehlererkennung in Testumgebungen weiter reduziert. In den letzten zwei Jahren, als wir diese Änderungen eingeführt haben, beobachteten wir einen deutlichen Rückgang der Engpässe in der gemeinsamen QA-Umgebung und gingen schrittweise von einem wöchentlichen Veröffentlichungszyklus vor Mai 2018 zur Bereitstellung von Code über fünfmal täglich im März 2020 über (siehe Abbildung unten).

Fazit
Um den vollen geschäftlichen Nutzen aus einer Microservices-Migration zu ziehen, sollten Sie sich alle Phasen Ihres Softwareveröffentlichungsprozesses genau ansehen. Zu den Bereichen, die es zu erkunden gilt, gehören die Einführung lokaler Entwicklungsumgebungen, der Aufbau von teamspezifischen, cloudbasierten Testumgebungen und die Anpassung der UI/API-Testautomatisierung. Diese Änderungen brauchen Zeit, aber sobald Sie fertig sind, ernten Sie die Früchte mehrerer qualitativ hochwertiger Veröffentlichungen pro Tag!