Review Apps: Features live sehen

Was sind Review Apps?

Eine Review App ist eine temporäre, voll funktionsfähige Umgebung, die automatisch während der Entwicklung bereitgestellt wird, zum Beispiel beim Erstellen eines Merge Requests (auch Pull Request genannt). Sie basiert auf dem jeweiligen Entwicklungs-Branch und erhält eigene, unabhängige Infrastruktur-Komponenten, darunter:

• Eine eigene Datenbankinstanz  
• Message-Queues  
• Eigenen Speicherplatz (Storage)  

Zusätzlich gibt es unterstützende Dienste, wie einen Development-Mailserver, da Emails auf Review Apps nicht tatsächlich versendet werden sollten. 

Der gesamte Prozess des Application Reviews ‒ also der Begutachtung der neuen Anwendungsversion ‒ wird dadurch erheblich vereinfacht. Features lassen sich realitätsnah testen, ohne dass andere Entwickler:innen oder Testumgebungen beeinträchtigt werden.

Wie werden Review Apps eingesetzt?

Eine Review App kann den ganzen Entwicklungsablauf unterstützen, angefangen von der Entwicklung eines neuen Features bis hin zur Freigabe für die Produktion.

Tests von Entwicklern 

Da die Review App unabhängig von anderen Instanzen betrieben wird, können Tests neben der lokalen Entwicklungsumgebung auch auf ihr durchgeführt werden. Auftretende Probleme, wie z. B. eine korrupte Datenbank, können einfach korrigiert werden, da Review Apps mit deren dedizierten Infrastrukturkomponenten einfach wieder gelöscht und neu bereitgestellt werden können. Auch Langzeittests, die sonst nur unter zusätzlichem Aufwand durchgeführt werden können, sind einfach zu realisieren. 

Feedback 

Feedbackprozesse werden deutlich vereinfacht. Durch die Verfügbarkeit der Review App kann Feedback von der Projektleitung, vom Design oder durch andere Entwickler:innen einfach und vor allem asynchron eingeholt werden. 

Automatisierte Tests

Wir führen automatisiert eine breite Bandbreite an Tests durch. Dies ist ein zentraler Bestandteil einer Continuous Integration Strategie. Diese Tests umfassen statische Code-Checks, Unit- und Integration-Tests, verschiedene Security- und Vulnerability-Tests, aber auch Regression-Tests, mit denen z. B. ungewollte UI-Änderungen frühzeitig, also noch während der aktiven Entwicklung, entdeckt werden können. Das automatisierte Testen sichert die Code-Qualität bei jeder einzelnen Änderung. 

Review 

Das Review von neuen Features und Verbesserungen durch Tester:innen, Entwickler:innen, Projektleitung, Design usw. kann direkt auf den Review-Instanzen durchgeführt werden. Diese werden also nicht erst auf dedizierten Testinstanzen geprüft. Dies reduziert die Entwicklungs- und Feedbackzeit von Anpassungen deutlich und hilft folglich auch, die Qualität zu steigern. 

Kunde 

Bei manchen Features macht es Sinn, den Kunden frühzeitig in die Entwicklung einzubinden, um Features zu testen oder abzuklären. Dies kann z. B. insbesondere bei der Einbindung von Fremdsystemen Entwicklungszyklen deutlich reduzieren. 

Verfügbarkeit 

Eine Review App ist nicht nur für Entwicklungszweige verfügbar, sondern wird auch für die Hauptentwicklungszweige bis hin zur Pre-Production bereitgestellt. Dank Continuous Deployment werden sie vollautomatisiert mit jeder Änderung aktualisiert, was klassischen, dedizierten Test-Instanzen ähnelt, aber weitaus dynamischer ist. Es stehen also immer Instanzen mit aktuellem Stand bereit, um Features zu testen, zu prüfen oder um einfach etwas nachzusehen. 

Monitoring 

Die Review Apps können natürlich auch einem vollumfänglichen Monitoring unterzogen werden. So können Fehler im Hintergrund, Performance-, Stabilitäts- oder Hardware-Ressourcenprobleme frühzeitig entdeckt werden.

Was wird für Review Apps benötigt?  

Eine Application Review zu unterstützen, ist alles andere als ein trivialer Prozess. Eine große Schwierigkeit besteht in der Dynamik der Konfigurationen. Anstatt eine handvoll Konfigurationen für Test- und Produktionsumgebungen bereitzustellen, muss die Konfiguration der Applikation und auch deren Abhängigkeiten voll dynamisch sein. Wird eine neue Applikation entwickelt und hat sozusagen eine »Grüne Wiese« vor sich, kann die Verwendung von Review Apps gleich von Anfang an in architektonische Entscheidungen mit einfließen. Aber auch bestehende Applikationen können migriert werden. Dabei sind ähnliche Überlegungen zu treffen.  

1. Abhängigkeiten  

Applikationen haben oft Abhängigkeiten zu anderen Diensten wie Datenbanken, Email-Server, Zahlungsdienstleister oder zu externen APIs. Für jede dieser Abhängigkeiten muss entschieden werden, wie diese in Testumgebungen zu handhaben sind. In Testumgebungen, wie es die Review Apps sind, ist es beispielsweise nicht wünschenswert, dass Emails an externe Nutzer verschickt oder Zahlungen durchgeführt werden. Um dies zu verhindern, müssen die Abhängigkeiten in der Review App so konfiguriert werden, dass sie z. B. eine dedizierte Test-API ansprechen, E-Mails an einen Entwicklungs-Mailserver verschicken oder einfach gar nichts machen.  

2. Bereitstellung  

Ein zentraler Teil ist die automatisierte Bereitstellung der Review Apps. Hierzu müssen detaillierte Überlegungen getroffen werden, wie die Applikation selbst bereitgestellt wird und wie sie und deren Abhängigkeiten konfiguriert werden.  

3. Applikation  

Wie wird ein Paket für die Applikation geschnürt und konfiguriert? Wie kann darauf zugegriffen werden? Webapplikationen und andere Dienste können z. B. als Container auf einem Docker- oder Kubernetes-Server gestartet werden, der Zugriff über eine Wildcard-Domain gesteuert werden (z. B. <branch>.ops.example.com). Dabei können durchaus weitere Abhängigkeiten entstehen. Bei bestehenden Applikationen muss z. B. überhaupt die Möglichkeit geschaffen werden, diese in einem Container zu starten. Es entstehen zusätzliche Anforderungen an die Infrastruktur, die z. B. den Zugriff über dynamische Domain-Namen ermöglicht, usw.

4. Externe Abhängigkeiten  

Hat die Applikation externe Abhängigkeiten, beispielsweise an eine Datenbank, müssen auch Überlegungen getroffen werden, wie diese dynamisch für jede Applikation bereitgestellt werden können. Für Datenbanken bietet es sich an, für jede Review Applikation über ein Backup eigene Datenbanken zu erstellen. Andere Dienste können parallel mit der Applikation als Container gestartet werden oder einmalig als zentraler Entwicklungsdienst konfiguriert werden. Andere Abhängigkeiten, wie Message Queues oder Storage, können über Namenskonventionen und Pfade gesteuert werden. Dateien können beispielsweise auf der Storage unter »review/<branch>/« gespeichert und später aufgeräumt werden. Schlussendlich muss die Handhabung jeder einzelnen Abhängigkeit analysiert und definiert werden.  

5. Build-Umgebung  

Damit der ganze Prozess mit Build und Bereitstellung der Applikation überhaupt automatisiert geschehen kann, wird ein Build-Server benötigt. Solche Systeme sind die Grundlage für Continuous Integration und Continuous Deployment. Ist bereits ein System im Unternehmen etabliert, kann dieses verwendet werden. Wenn nicht, bieten sich Dienste wie GitLab, GitHub, Azure DevOps oder Jenkins an. Es sollte aber jedenfalls ein Tool gewählt werden, an das man sich auch längerfristig binden will, da damit auch ein entsprechender Know-how-Aufbau benötigt wird.

Sicherheit und Konfigurationsmanagement  

Die automatisierten Jobs, die für die Bereitstellung der Applikationen verantwortlich sind, müssen die Review Apps auch mit entsprechenden Variablen für deren Konfiguration versehen. Dabei muss sichergestellt werden, dass sensible Daten wie Passwörter, API-Keys, Deployment-Keys, Zertifikate usw. vor unerwünschten Blicken, auch von internen Entwicklern, geschützt sind. Dies kann durch Maßnahmen am Build-Server bewerkstelligt werden, aber beispielsweise auch durch den Einsatz externer Secret-Server, wie Azure Key Vault oder AWS Secrets Manager.  

Testdaten  

In vielen Applikationen macht es wenig Sinn, einfach nur die Services in ihrer Grundkonfiguration bereitzustellen. Es werden brauchbare Testdaten benötigt. Hierbei sind Überlegungen zu treffen, von wo diese kommen und wie diese den Entwicklern und für die Bereitstellung der Review Apps verfügbar gemacht werden. Je nach Projekt können das volle oder teilweise Snapshots von Produktionsdaten sein, die einmalig oder regelmäßig aktualisiert werden, ein anonymisiertes Set an Testdaten oder manuell eingetragene Daten, vielleicht unterstützt von generierten Werten. Dies kann von Projekt zu Projekt stark variieren. Entscheidend ist jedoch, dass die Testdaten von ausreichender Qualität sind, damit die Applikation auch sinnvoll betrieben und getestet werden kann, ohne auf Fehler mit »echten Daten« im Produktionsbetrieb bangen zu müssen.   

Lifecycle Management  

Die meisten Review Apps laufen nicht lange. Sobald eine Entwicklung in den Hauptentwicklungszweig eingebunden ist, der Merge-Request also geschlossen wird, wird die Review App gestoppt. Dabei soll kein Datenmüll liegen bleiben, da sich dieser schnell akkumulieren würde. Es muss also beachtet werden, dass mit dem Stopp der Review App nicht nur der Dienst selbst gelöscht wird, sondern auch alle mit ihm erstellten Abhängigkeiten, wie Datenbanken, Message-Queues, Verzeichnisse in der Storage etc. Dies kann entweder direkt beim Stoppen der Instanz passieren oder z. B. in nächtlichen Aufräumjobs. Des Weiteren kann es sinnvoll sein, dass manche, quasi statische, Review Apps mit frischen Testdaten versorgt werden, beispielsweise mit einem Job, der jede Nacht auf ausgewählten Testinstanzen einen aktuellen Datenbank-Snapshot eingespielt hat.  

Monitoring  

Nicht nur für Review Apps, sondern generell sinnvoll ist ein zentrales Monitoring, Logging und Tracing von Applikationen und Infrastruktur. Es ist ein deutlicher Gewinn für die Qualität der Applikation und für die Dauer der Problemfindung und -korrektur, wenn Probleme aktiv automatisiert gemeldet werden, Logs, Metriken und Traces zentral abgefragt werden können. Hierbei bieten sich Dienste an, die diese Logs und Metriken aus verschiedenen Quellen abfragen und akkumulieren können, wie Grafana oder AWS CloudWatch.

Wie Fusonic Review Apps bereitstellt

Für uns sind Review Apps kein Sonderfall, sondern gelebter Standard. Unser tiefes Know-how und unsere über Jahre optimierten Frameworks ermöglichen es uns, von der Code-Änderung bis zur lauffähigen Review App oft nur Minuten zu benötigen.

Für dich als Kunde bedeutet das konkret:

• Schnelleres Feedback: Änderungen sofort im realen Umfeld testen.
• Höhere Qualität: Fehler erkennen, bevor sie in die Produktion gelangen.
• Mehr Transparenz: Jederzeit den aktuellen Stand der Entwicklung sehen.

Diese Effizienz, die sich selbst in hochsicheren Umgebungen wie dem Bankensektor bewährt hat, ist die Grundlage für eine erfolgreiche Partnerschaft. Mit Fusonic wählst du einen Entwicklungspartner, der Review Apps als Kern eines agilen Prozesses versteht und deine Projekte so schneller und sicherer zum Ziel führt.