Interview mit Stephan Kaps

Continuous Delivery – mit welchen Maßnahmen es steht und fällt

Redaktion JAXenter

Stephan Kaps

Umfangreiche Qualitätssicherungsmaßnahmen und die Definition von Quality-Gates im Rahmen von Continuous Integration sind der eigentliche Enabler für Continous Delivery. Doch welche Tests sollte man eigentlich auf welcher Umgebung vorsehen und welche Werkzeuge bieten die entsprechende Unterstützung? Diese und weitere Fragen wird Stephan Kaps in seiner Session auf der W-JAX 2015 beantworten. Wir haben im Vorfeld um ein Interview gebeten.

JAXenter: Continuous Delivery steht und fällt mit Qualitätssicherungsmaßnahmen – das ist eine deiner Kernaussagen in deinem W-JAX Talk. Wie können diese QS-Maßnahmen aussehen?

Stephan Kaps: Wenn wir nicht wollen, dass der Endbenutzer in der Produktion die neue Version testet, nur weil jetzt schnell und häufig ausgeliefert werden kann, dann müssen wir jeden Release-Kandidaten so vielen Tests wie möglich aussetzen. Dazu gehören statische Analysen wie

  • Werden Kodierrichtlinien eingehalten?
  • Sind mögliche Schwachstellen und Fehler im Code enthalten?
  • Wurden Verwundbarkeiten entdeckt?

und dynamische Tests wie

  • Sind die richtigen Funktionen korrekt umgesetzt?
  • Wird die erwartete Antwortzeit erfüllt?
  • Kann mit der erwarteten Last umgegangen werden?
  • Uvm.

In meinem Talk geht es vor allem darum, ein Set an Open Source Tools vorzustellen, die sich in den Build-Prozess mit Jenkins einbinden und somit automatisieren lassen. Des Weiteren bieten die meisten Tools die Möglichkeit, Quality-Gates zu definieren, wodurch ein gesicherter Übergang von einer Phase bzw. Stage zur nächsten realisierbar wird.

JAXenter: Kannst du einmal ein Beispiel nennen? Welche Tests machen auf welcher Umgebung Sinn?

Stephan Kaps: Nehmen wir als Beispiel Security-Tests, die bei der Entwicklung einer Webanwendung äußert wichtig sind. Auf einer ersten Stage, der sogenannten Commit-Stage, führen wir statische Codeanalysen durch. Diese sollten Sicherheitsprüfungen enthalten, ob der entwickelte Code Schwachstellen oder Verwundbarkeiten enthält. Des Weiteren sind die verwendeten Third Party Libraries auf bekannte Verwundbarkeiten hin zu überprüfen. Daneben ist es noch notwendig, meist auf einer Pre-Production Stage, dynamische Tests mit Hilfe von Spidern oder Scannern durchzuführen. Diese können beispielsweise auf existierenden Akzeptanz- bzw. Regressionstests aufsetzen.

JAXenter: Ist das Ideal der Softwareentwicklung aus deiner Sicht Test Driven Development?

Stephan Kaps: Das ist eine verhängnisvolle Frage 😉 Ich sehe das eher pragmatisch. Wenn mir TDD hilft, eine umfangreiche Test-Suite an Akzeptanz- und Regressionstests aufzubauen, dann befürworte ich es. Wenn es nur eingesetzt wird, um die Anzahl an Unit-Tests zu erhöhen, um beispielsweise eine Abdeckung von 90% oder mehr zu erreichen, sehe ich das kritisch. Dadurch verbessert sich erstmal nicht zwingend die Qualität der Software. Inzwischen existieren gute Frameworks und Tools für Behavior Driven Development (BDD), was eine gute Alternative oder zumindest Ergänzung sein kann. In meinem Vortrag wird ein weiterer pragmatischer Ansatz kurz vorgestellt, der ohne Programmierung auskommen kann.

JAXenter: Du berichtest auch von den Aktivitäten rund um ISO 25010. Worum geht es dabei?

Stephan Kaps: Dabei geht es darum, die Test-Aktivitäten einordnen zu können. Die ISO 25010 definiert acht Qualitätsmerkmale und nennt dazu einige Submerkmale. Ich werde in meinem Vortrag kurz darauf eingehen, welche Merkmale der ISO 25010 durch die vorgestellten QS-Maßnahmen unterstützt werden.

JAXenter: Nun gibt es QS-Tools ja wie Sand am Meer. Hast du für unsere Leser einige Tipps parat: Welche Werkzeuge zur Qualitätssicherung sollte man sich einmal anschauen, und warum?

Stephan Kaps: Das könnte jetzt ein ganzer Aufsatz werden, aber ich will ja auch nicht zu viel vom Inhalt des Talks verraten. In meinem Vortrag wird es um Open Source Tools gehen und die Möglichkeiten, Quality Gates zu setzen. Um ein Beispiel zu nennen, greife ich die Sicherheitstests von eben noch mal auf. Statische Analysen des Codes können mit FindSecurityBugs sehr einfach und schnell durchgeführt werden. Die Überprüfung von Third Party Libraries hinsichtlich Verwundbarkeiten wird vom OWASP Dependency Check hervorragend unterstützt. Und für dynamische Analysen ist mein Favorit der Zed Attack Proxy (kurz ZAP), ebenfalls von OWASP. Alle Tools lassen sich per Jenkins-Plug-in in den Build-Prozess integrieren und somit automatisieren. Des Weiteren können Grenzwerte definiert werden, wann ein Build abbrechen soll.

 

Stephan Kaps arbeitet als technischer Projektleiter und Softwarearchitekt, zuletzt überwiegend im SOA-Umfeld. Weitere Schwerpunkte liegen in der Konzipierung und Optimierung von Softwareentwicklungsprozessen (Continuous Delivery) und dem Application Lifecycle Management. Zudem hat er langjährige Erfahrung als Java- und Host-Entwickler. Seine Leidenschaft sind neue Technologien und Methoden.

Verwandte Themen:

Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.