© Liashko/Shutterstock.com
Entwickler Magazin
Continuous Delivery in der Praxis

Entwicklung mit Tempocheck

Als logische Weiterentwicklung agiler Vorgehensmodelle in der Softwareentwicklung haben sich in den letzten Jahren unter dem Begriff Continuous Delivery zahlreiche Möglichkeiten zur automatisierten Auslieferung von Software in Test- und Produktionsumgebungen etabliert. Es gibt jedoch einige Herausforderungen: Üblicherweise werden Last- und Performancetests unmittelbar vor der Auslieferung der Software durchgeführt, bei Continuous Delivery werden die Zyklen dazwischen aber immer kürzer. Wie lässt sich also kontinuierlich die Performance sichern? Und auf welcher Basis trifft das Unternehmen die Entscheidung, ob der Stand der Software releasefähig ist oder nicht? Dieser Artikel beschreibt die Vorteile einer kontinuierlichen Überwachung von Skalierbarkeit und Performance.

Eric Nordmann, Wolfgang Gottesheim


Obwohl die meisten Unternehmen heute wissen, wie wichtig eine hohe Performance ihrer Website oder Anwendung ist, erstaunt es, wie lange die Nutzer trotzdem meist auf eine angeforderte Seite oder das Öffnen der App warten müssen. Fehler sollten so früh wie möglich entdeckt und behoben werden, damit sie keinesfalls in die Produktivphase mitgeschleppt werden. Doch Negativbeispiele wie die Website zu Obamacare schaffen es immer wieder in die Schlagzeilen. Funktionalitätstests bilden aber nur einen Teil der Anforderungen ab. Wichtig sind heutzutage auch die Performance der Funktion sowie ihre Konformität mit Architekturregeln. Dies erfordert die Kenntnis, wie sich die Anwendung intern verhält, um abzuschätzen, ob der Code die Performance-, Skalierungs- und Architekturanforderungen erfüllt.

Tests bei einer Shoppingseite

Zum Beispiel prüft ein Integrationstest bei einer Onlineshoppingseite, ob der Backend-Service den Kaufprozess für die Warenkorbinhalte korrekt ausführt. Dies umfasst die Verifizierung und Belastung der Kreditkarte, die Erzeugung des Bestellvorgangs und eventuell die Aktualisierung des Inventurstatus. Im ersten Schritt werden hier die Daten vom CI-Server betrachtet, die das einfache Testen der Funktionalität in verschiedenen Builds erzeugt. So lässt sich zum Beispiel erkennen, dass in Build 18 eine Kauffunktion ausfiel, die in der nächsten Version wieder funktionierte (Abb. 1).

Abb. 1: Beispiel für einfache Funktionalitätstests, in denen bei Build 18 die Kauffunktion ausfiel

Hier hat offensichtlich ein Entwickler das Problem gelöst. In einer Continuous-Delivery-Pipeline könnte dieses Testergebnis als Indikator für einen Produktionseinsatz ausreichen, doch der Blick auf die Architekturdaten zeigt hier mögliche Skalierbarkeitsprobleme (Abb. 2).

Abb. 2: Die Lösung eines Problems kann zu Problemen an anderen Stellen führen

Während die fünf Exceptions in Build 18 wohl die Ursache für den Ausfall der Kauffunktion waren, erzeugte die Lösung zur erfolgreichen Wiederherstellung in der Folgeversion nicht weniger als 75 auszuführende Datenbankabfragen und damit sechsmal mehr als vorher. Dies schränkt die Skalierbarkeit ein und führt zu einer deutlichen Beeinträchtigung der Performance. In der Continuous-Delivery-Pipeline würde dieses Problem erst kurz vor dem Produktionseinsatz erkannt werden: Die reinen Funktionalitätstests helfen an dieser Stelle nicht weiter, da die grundlegende Funktion ja erhalten blieb. Erst ein Lasttest im Capacity Stage mit einem reali...

Entwickler Magazin
Continuous Delivery in der Praxis

Entwicklung mit Tempocheck

Als logische Weiterentwicklung agiler Vorgehensmodelle in der Softwareentwicklung haben sich in den letzten Jahren unter dem Begriff Continuous Delivery zahlreiche Möglichkeiten zur automatisierten Auslieferung von Software in Test- und Produktionsumgebungen etabliert. Es gibt jedoch einige Herausforderungen: Üblicherweise werden Last- und Performancetests unmittelbar vor der Auslieferung der Software durchgeführt, bei Continuous Delivery werden die Zyklen dazwischen aber immer kürzer. Wie lässt sich also kontinuierlich die Performance sichern? Und auf welcher Basis trifft das Unternehmen die Entscheidung, ob der Stand der Software releasefähig ist oder nicht? Dieser Artikel beschreibt die Vorteile einer kontinuierlichen Überwachung von Skalierbarkeit und Performance.

Eric Nordmann, Wolfgang Gottesheim


Obwohl die meisten Unternehmen heute wissen, wie wichtig eine hohe Performance ihrer Website oder Anwendung ist, erstaunt es, wie lange die Nutzer trotzdem meist auf eine angeforderte Seite oder das Öffnen der App warten müssen. Fehler sollten so früh wie möglich entdeckt und behoben werden, damit sie keinesfalls in die Produktivphase mitgeschleppt werden. Doch Negativbeispiele wie die Website zu Obamacare schaffen es immer wieder in die Schlagzeilen. Funktionalitätstests bilden aber nur einen Teil der Anforderungen ab. Wichtig sind heutzutage auch die Performance der Funktion sowie ihre Konformität mit Architekturregeln. Dies erfordert die Kenntnis, wie sich die Anwendung intern verhält, um abzuschätzen, ob der Code die Performance-, Skalierungs- und Architekturanforderungen erfüllt.

Tests bei einer Shoppingseite

Zum Beispiel prüft ein Integrationstest bei einer Onlineshoppingseite, ob der Backend-Service den Kaufprozess für die Warenkorbinhalte korrekt ausführt. Dies umfasst die Verifizierung und Belastung der Kreditkarte, die Erzeugung des Bestellvorgangs und eventuell die Aktualisierung des Inventurstatus. Im ersten Schritt werden hier die Daten vom CI-Server betrachtet, die das einfache Testen der Funktionalität in verschiedenen Builds erzeugt. So lässt sich zum Beispiel erkennen, dass in Build 18 eine Kauffunktion ausfiel, die in der nächsten Version wieder funktionierte (Abb. 1).

Abb. 1: Beispiel für einfache Funktionalitätstests, in denen bei Build 18 die Kauffunktion ausfiel

Hier hat offensichtlich ein Entwickler das Problem gelöst. In einer Continuous-Delivery-Pipeline könnte dieses Testergebnis als Indikator für einen Produktionseinsatz ausreichen, doch der Blick auf die Architekturdaten zeigt hier mögliche Skalierbarkeitsprobleme (Abb. 2).

Abb. 2: Die Lösung eines Problems kann zu Problemen an anderen Stellen führen

Während die fünf Exceptions in Build 18 wohl die Ursache für den Ausfall der Kauffunktion waren, erzeugte die Lösung zur erfolgreichen Wiederherstellung in der Folgeversion nicht weniger als 75 auszuführende Datenbankabfragen und damit sechsmal mehr als vorher. Dies schränkt die Skalierbarkeit ein und führt zu einer deutlichen Beeinträchtigung der Performance. In der Continuous-Delivery-Pipeline würde dieses Problem erst kurz vor dem Produktionseinsatz erkannt werden: Die reinen Funktionalitätstests helfen an dieser Stelle nicht weiter, da die grundlegende Funktion ja erhalten blieb. Erst ein Lasttest im Capacity Stage mit einem reali...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang