Open Source im professionellen Einsatz
Linux-Magazin 09/2014
© reddz, 123RF

© reddz, 123RF

Testen im Devops-Umfeld

No risk, lots of fun

Führt ein Unternehmen eine Devops-Kultur ein, baut es meist kurzentschlossen Teams um, verschiebt Verantwortlichkeiten und vergibt Adminrechte neu. Doch kalkuliert es auch die Risiken und Nebenwirkungen mit ein? Ein Bericht aus der Praxis.

755

Ein typischer Effekt beim Wechsel hin zur Devops-Kultur: Auf den Servern im Rechenzentrum wächst der Nutzerkreis mit administrativen Berechtigungen. Nach der anfänglichen Euphorie stellen sich bei Ausfällen im Alltag jedoch wieder die altbekannten Fragen: Wer war es, wie konnte das passieren und warum haben wir es nicht bemerkt?

Zwar ändert sich der Weg zum Ziel in einer agilen Welt dramatisch, doch kann auch diese kaum auf einen stabilen Betrieb und Nachhaltigkeit verzichten. War es früher nur wenigen Admins erlaubt, Änderungen auf Servern auszurollen, darf nun dank Devops fast jeder Kollege ran. Die IT soll nicht mehr von Spezialwissen und einem jahrelang antrainierten Bauchgefühl abhängen, an ihre Stelle tritt mehr und mehr die Testautomation. Von Spezialisten entwickelt, setzt sie dann jedermann ein.

Testautomation ist nicht neu und kommt in der Software-Entwicklung schon lange zum Einsatz. Dass Admins dieses Vorgehen auf den Betrieb von Servern und Rechenzentren übertragen, ist allerdings eine recht junge Entwicklung.

Die im Artikel vorgestellten Methoden eignen sich womöglich weniger für kleinere IT-Umgebung. Doch Firmen mit vielen Mitarbeitern sowie solche, die Nachhaltigkeit anstreben, dürften davon profitieren. Sie zielen vor allem darauf ab, die Kosten für das Beseitigen von Fehlern zu senken. Im Entwicklungsprozess, der aus Planen, Entwickeln, Testen und Betreiben besteht, wird die Lösung meist umso teurer, je später der Fehler auffällt (Abbildung 1). In der Planungsphase kann ein Entwickler einen Designfehler günstig und einfach beseitigen. Geht ein Softwareprodukt erst in Produktion, lässt sich der gleiche Fehler nur mit größtem Aufwand entfernen.

Abbildung 1: Fehlerfolgekosten während des Produkt-Lebenszyklus.

An genau diesem Punkt gehen Entwickler und Admins sehr unterschiedlich vor. Die Software-Entwickler investieren typischerweise viel mehr Zeit in die Planung, um dann relativ zügig zu entwickeln, zu testen und die Software in Betrieb zu nehmen. Im Operations-Bereich (auf Deutsch "Betrieb") entstehen dagegen viele Ideen spontan oder werden in kurzen Workshops erarbeitet.

Eine entwickelte Software schicken die Admins vor dem Produktiveinsatz in eine längere Testphase. Das fertige Programm testen sie dann meist nur über Ausprobieren und stellen so fest, ob "etwas Schlimmes passiert". Abbildung 2 vergleicht symbolhaft die beiden Welten, die Devops vereinen möchte.

Abbildung 2: Die Testphase verläuft bei Entwicklern (Devs) und Admins (Ops) nicht selten unterschiedlich.

Planen Betriebler umfangreiche Änderungen, treffen sie im Operations-Bereich nicht selten auf großen Widerstand. Dahinter steht meist die Angst, eine funktionierende Infrastruktur zu zerstören. In der Entwicklung passiert es hingegen häufiger, dass eine gut getestete Software auch größere Umbauten mit überschaubarem Risiko übersteht.

Aus Fehlern lernen

In der Praxis braucht Devops vor allem zwei Dinge: gegenseitigen Respekt und die Bereitschaft, voneinander zu lernen. Viele Devops-Projekte beginnen damit, dass die Entwickler das Rechenzentrum und den Serverbetrieb besser kennenlernen und die Herausforderungen im Operations-Bereich in ihrer Planung berücksichtigen. Entwickler lernen nervige Probleme zu vermeiden, indem sie dafür sorgen, dass Logfiles nicht die Festplatten überschwemmen, keine störrischen und trägen Dienste laufen, Monitoring und Alarming funktionieren und sie keine Systeme mit völlig überzogenen Ressourcen-Anforderungen bestellen.

Der Betrieb lernt von den Entwicklern meist noch mehr:

  • Kleine Schritte gehen (Incremental Improvement).
  • Infrastruktur in Code umsetzen.
  • Konsequent Versionskontrollsysteme benutzen.
  • Denken wie ein Entwickler: Funktionen in Bibliotheken auslagern, richtige Abstraktion und so weiter.
  • Anstelle von Spaghetticode mit langen Kommentaren lesbaren und wartbaren Code produzieren.
  • Schnittstellen definieren.
  • Unittests und Integrationstest umsetzen.
  • Testautomation.

Dabei zeigt sich: Viele praktische Aspekte in der modernen Software-Entwicklung ergeben auch im administrativen Bereich Sinn. So teilen Entwicklung und Betrieb eines der wichtigsten Prinzipien: die testgetriebene Entwicklung [1].

Untested = broken

Die Grundidee besagt, dass alle nicht getesteten Funktionen entweder kaputt oder nicht implementiert sind. Während Entwickler viele verschiedene Arten von Tests kennen, reichen im Operations-Bereich meist zwei Testtypen aus: Unittests und Systemtests. Unittests überprüfen eine kleine Komponente, die Unit, in einer künstlichen Umgebung. Systemtests bringen die gesamte Anwendung in einer möglichst praxisnahen Form mit anderen Anwendungen oder deren Abhängigkeiten zusammen. Unittests durchleuchten also eher einzelne Codeteile, während Systemtests überprüfen, wie sich die Anwendung als Ganzes verhält.

Die beiden gegensätzlichen Testverfahren ergeben in ihrer Kombination eine gesunde Mischung aus Detailansicht und einem Blick aufs Ganze. Je nach Testsubjekt wählt der entwickelnde Admin den einen oder anderen Weg: Für Funktionen und Bibliotheken sowie Syntaxchecks greift er zu Unittests, die er auch problemlos auf dem Entwicklerdesktop ausführt.

Wenn möglich kann der Tester das Programm oder Tool in einem Unittest bereits mit Testdaten füttern, hier würde ein Entwickler schon von einem Integrationstest sprechen.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 5 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Aufmerksamer Beobachter

    Will ein Entwickler seine Software mit automatisierten Tests prüfen, muss er komplexe Randbedingungen wiederholbar machen. Dabei helfen ihm Mock-Objekte, die das Verhalten von Produktionscode simulieren, ob es sich nun um ein Netzwerk oder eine Datenbankanbindung handelt.

  • TDD

    Das Credo des Test Driven Development (TDD): Wer zuerst Tests schreibt und dann erst programmiert, erzeugt sauberen Code und geprüfte Programme. Wie das in Java und weiteren Sprachen geht, zeigt dieser Artikel, der auch die Vor- und Nachteile der Methode abwägt.

  • Python 3.3.0 veröffentlicht

    Python ist in Version 3.3.0 erhältlich, die ein rundes Dutzend Python Enhancement Proposals (PEP) umsetzt.

  • PHPUnit 3.7 mit umgestaltetem Coverage-Report

    PHPUnit, ein Tool zum Testen von PHP-Skripten, ist in Version 3.7 verfügbar.

  • PHP Unit

    Unit-Tests sorgen für funktionierende und wartbare Software. Dieser Artikel zeigt PHP-Entwicklern, wie sie mit dem Tool PHP Unit den Einstieg in die testgetriebene Entwicklung finden.

comments powered by Disqus

Ausgabe 07/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.