Test-Chaos vermeiden mit der Deploy-and-Destroy-Strategie

Seite: 2/2

Firma zum Thema

Technische Umsetzung einer Deploy-and-Destroy-Strategie

Der erste Schritt einer Deploy and Destroy Umgebung ist das Erstellen einer Bibliothek an Service Virtualisierungs Assets. Üblicherweise erfolgt dies durch die Aufnahme des Zusammenspiels einer tatsächlichen Anwendungen, aber auch andere Methoden können zum Einsatz kommen (z.B. durch das Kreieren von Swagger oder anderer Definitionen, durch Traffic Dateien). Falls gewünscht, können diese Assets mit weiteren Daten, Leistungsprofilen oder Response Logik erweitert und verbessert werden.

Ist ein Fundament an virtuellen Assets erstellt, lassen sich diese in einer ‚Umgebung‘ zusammenfassen. Ausgehend von einem Kernsystemplan definiert eine Umgebung, welche Zustände die Abhängigkeiten der Anwendung unter Test (AUT) einnehmen dürfen. Ein Beispiel dafür: Ein 3rd Party Dienst der Umgebung könnte durch 10 verschiedene virtuelle Versionen dieses Assets dargestellt werden, jede mit verschiedenen Kombinationen aus Leistungs- und Datenprofilen, als auch der realen Version dieses Services. Umgebungen mit den verschieden Kombinationen aus Abhängigkeitskonfigurationen lassen sich dann auf Abruf bereitstellen (z.B. eine virtuelle API, die eine Netzwerküberlastung simuliert, mit Fehlerrückmeldungen und einer realen Datenbank und einem virtuellen Mainframe, der positive Rückmeldung liefert).

Um den Bereitstellungsprozess zu verfeinern und zu beschleunigen, ist die Verknüpfung der bereitgestellten Umgebungen mit einer Containertechnologie wie. z.B. Docker sinnvoll. Das ermöglicht das Verpacken der Umgebungen und deren Bereitstellung auf laufende Container, wodurch komplette Testumgebungen in Sekundenschnelle zur Verfügung stehen.

Die Wertschöpfung von „Deploy and Destroy“

Eine Deploy and Destroy Strategie bietet Entwicklern und Testteams viele Vorteile:

Frühes und kontinuierliches Testen – Dank unmittelbarem Zugriff und der simultanen Verfügbarkeit von realistischen und flexiblen Testumgebungen können Teams eine ganze Reihe von End-to End Tests ausführen. Sobald ein Anwendungsfall (User Story) vollständig ist, kann mit dem Testen begonnen und eine Vielzahl von User Stories gleichzeitig während des Continuous Testing Prozesses validiert werden, jede in der für die jeweiligen Tests benötigten spezifischen Testumgebung.

Größere Flexibilität - Im Vergleich zu einer realen, physischen Testumgebung erlaubt die Simulation die flexiblere Bereitstellung von Testumgebungen. Mit realen, physischen Testumgebungen ist es schwierig, das Verhalten oder die Leistung von abhängigen Anwendungen zu beeinflussen, beispielsweise von Mainframes oder ERPs. Denn dies erfordert üblicherweise eine zeitintensive Konfiguration der Hardware, die Verteilung von Speicherkapazitäten, das Einrichten von VMs, usw., um nur einige Beispiele zu nennen. Beim Einsatz von Simulationstechnologien, wie der Service Virtualisierung, kann dieser Aufwand eingespart werden. Ganz einfach lassen sich Bedingungen herstellen, die in einer Produktions- oder physischen Testumgebung unmöglich zu konfigurieren wären. Das erweitert den Testhorizont enorm und ermöglicht auch das Testen von extremen Fällen wie z.B. Concurrency, Ausfälle, Resiliency, Failover oder Load Balancer Probleme.

Realistischer als die tatsächliche Testumgebung - In vielen Fällen ist eine Deploy and Destroy Umgebung realistischer als reale, physisch eingerichtete Umgebungen, die in der Regel von Hardware-Restriktionen geprägt sind und deren Leistung beschränkt ist. Service Virtualisierung verleiht Testern bessere Kontrolle darüber, wie die abhängigen Systeme und Anwendungen reagieren. Rückmeldezeiten wie in einer Produktionsumgebung sind erzielbar, was die Wiedergabetreue der Testumgebungen erhöht.

Mithilfe der Service Virtualisierung lassen sich Fehler und Ausfälle in realen Testumgebung kompensieren, beispielsweise wenn Tests ausgeführt werden müssen, aber die abhängigen Systeme gerade dann nicht verfügbar sind. Eine Deploy and Destroy Umgebung kompensiert dies automatisch, in dem es den Verkehr auf simulierte Endpunkte umleitet und dadurch die Durchführung oder Fortführung der Tests ermöglicht, so als wären die realen Systeme oder Anwendungen verfügbar.

Datensicherheit und Privatsphäre - Durch die simulierte Umgebung wird der Zugriff auf Datensätze gewährt, die bereits gesäubert, bzw. verdeckt sind, daher spielen Sicherheitsbedenken keine Rolle. Selbst wenn sich jemand unbefugt Zugang verschafft, oder ein Asset angreift, gibt es keine Grund zur Befürchtung, da es nicht real ist und unmittelbar nach dem Test wieder zerstört wird.

Konsistenz und Genauigkeit - Deploy and Destroy stellt sicher, daß alle Beteiligten übereinstimmend ihre Aktivitäten durch Zugriff auf die neuesten Testobjekte / Daten und virtuellen Artefakte koordinieren können. Jedes Mal bei der Bereitstellung einer neuen Testumgebung wird diese über den Zugriff auf den Masterdatensatz, die virtuellen Assets und Testobjekte in der Repository von grundauf neu kreiert. So lässt sich verhindern, dass Tests in „verunreinigten“ Umgebungen ausgeführt werden, und veraltete Daten oder nicht autorisierte Versionen von virtuellen Assets zum Einsatz kommen.

Die Implementierung einer Deploy and Destroy-Strategie wirkt sich schnell auf die Geschäfte von Entwicklungs- und Testunternehmen aus. Kosten und Wartezeiten durch den Zugriff auf abhängige Systeme oder Datenbanken können reduziert bzw. eliminiert werden. Das Risiko für Release-Kandidaten wird minimiert, agile und iterative Entwicklungsmethoden werden effizient unterstützt, und Entwicklungs- bzw. Testzyklen erheblich verkürzt. In einer Zeit, in der Entwickler Anwendungen immer schneller und fehlerfrei abliefern sollen, spielt die Service-Virtualisierung eine zunehmend wichtige Rolle, um Engpässe während der Testphase zu verringern. Das beschleunigt letztlich die Time to Market und bringt Wettbewerbsvorteile. Somit kann Deploy and Destroy für Unternehmen und Anwendungsanbieter eine Strategie sein, sich von Mitbewerbern zu unterscheiden und dazu beitragen, den eigenen finanziellen Erfolg abzusichern.

Quellenverweise:

[1] voke Research, Market Snapshot Report: Virtual and Cloud-Based Labs

[2] Skytap, Transform Your SDLC with Parallel Development and Testing in Cloud Environment

[3] voke Research, Market Snapshot Report: Service Virtualization

* Arthur Hicken ist Chief Software Evangelist bei Parasoft

(ID:44950738)

Über den Autor

 Arthur Hicken

Arthur Hicken

Parasoft® Deutschland GmbH