Cloud Computing / DevOps / Software-Entwicklung / Software-Test / Test Center / Testmanagement

Testumgebungsmanagement mit der Cloud

Dieser Artikel widmet sich dem Hosting von Testumgebungen und ist die Fortsetzung von Testumgebungen auf einen Klick. Für das Hosting von Testumgebungen existieren einige Möglichkeiten – die wohl spannendste ist die Cloud. Vor einigen Jahren noch wenigen Leuten ein Begriff, ist die Cloud heute vor allem im privaten Bereich, wie zum Beispiel vom Smartphone (Dropbox, Evernote) oder TV (Netflix, Amazon Prime), nicht mehr wegzudenken. Im Businessbereich stoßen große Anbieter mit Endanwender-Lösungen in neue Marktbereiche vor, wie beispielsweise Microsoft mit Office365. Abseits von diesen offensichtlichen Einsatzmöglichkeiten, bietet die Cloud aber auch Lösungen für alltägliche Probleme in den Bereichen Softwaretest- und Entwicklung – hier sind mit Hilfe der Cloud neue Wege zu beschreiten.

Testumgebungsmanagement mit der Cloud

Ist in diesem Beitrag von „Cloud“ die Rede, verstehen wir darunter die Services zur Anmietung von Hardware von großen Anbietern, wie Amazon oder Microsoft. Besonders bei Microsofts Azure Cloud, wird darauf Wert gelegt, gängige Microsofttools (z.B. Visual Studio, Sharepoint oder Team Foundation Server) zu integrieren. Hier liegt der Nutzen für IT-Organisationen ohnehin auf der Hand: versionierte Quellcodeablage, automatisierte Build- und Deploymentprozesse, nahtlose Einbindung des Fehlermanagementsystems, Monitoring der eingesetzten Hardware und transparente Darstellung der anfallenden Kosten.

Amazon Web Services (AWS) wiederum bietet einen großen Marketplace, in dem kostenlos oder für geringe Cent-Beträge, Templates für Maschinenkonfigurationen bezogen werden können. Hier können mit wenigen Mausklicks virtuelle Server mit einer Reihe von vorinstallierten Tools (wie z.B Apacheserver) hochgezogen werden.

 

Testumgebungshosting heute und morgen

Im Vergleich zu Cloud-only-Lösungen wird heute oftmals ein „On Premise“ Ansatz gelebt, bei dem die Hardware für Test- und Entwicklung von und im eigenen Unternehmen gehostet wird. Der große Vorteil: Die Organisation hat alles selbst in der Hand. Dies ist aber auch zugleich der größte Nachteil: Es entsteht viel Aufwand für Wartung und Betrieb. Mag diese Lösung also für kleine oder mittelgroße Organisationen bzw. Projekte ein gangbarer Weg sein, stößt man bei größeren Unterfangen recht schnell an Grenzen.

Eine andere Möglichkeit sind externe Rechenzentren oder Neudeutsch „private Cloud“, bei denen ein Drittanbieter die Betreuung der Infrastruktur übernimmt. Der Unterschied zu „echten“ Cloud-Lösungen ist, dass in diesem Fall normalerweise nicht nur der Betrieb, sondern auch die Steuerung und der Aufbau vom Drittanbieter übernommen wird. Es muss also für jeden neuen Server oder Cluster ein Antrag beim Drittanbieter gestellt werden, dessen Bearbeitung je nach Verfügbarkeit einige Zeit beanspruchen kann.

Bei der Nutzung von Cloud-Lösungen liegt aber genau hier der Unterschied: Über die einfach zu bedienenden und übersichtlichen Web-Interfaces von Amazon und Microsoft, wird die Steuerung und der Aufbau von der Wartung und Pflege der Hardware entkoppelt.

Die Vorteile liegen auf der Hand – der Anbieter garantiert mehr oder weniger eine 24/7-Verfügbarkeit und Wartung, während der Nutzer es selbst in der Hand hat, wie die Hardware genutzt und kombiniert wird. Natürlich sind auch Hybrid-Ansätze möglich, bei denen in-house gehostete Testumgebungen um zusätzliche Instanzen aus der Cloud erweitert werden. Die Möglichkeiten sind hier sehr vielfältig und benötigen in der Planungsphase besondere Aufmerksamkeit, damit für die Umsetzung in der Cloud der richtige Ansatz gewählt wird und die Testumgebung am Ende dem gelebten Alltag entspricht.

 

So wird es gemacht: Ein Beispielprozess

Ein beispielhafter Ablauf zur Erstellung von Testumgebungen mittels AWS und Docker bzw. Puppet, kann im Groben etwa so aussehen (siehe Abb. 1)

Abb. 1.: Beispielhafter Ablauf zum Setup einer Testumgebung in AWS

Abb. 1.: Beispielhafter Ablauf zum Setup einer Testumgebung in AWS

 

Zur Bedienung der AWS-Services können, neben der Weboberfläche, auch Commandline Befehle verwendet werden. Somit kann auch das AWS Setup per Script automatisiert werden. Obwohl die von Amazon gewartete AWS Dokumentation ausgesprochen gut ausfällt, ist für Nicht-Techniker die Weboberfläche das geeignete Mittel.

Konfiguration

Im ersten Schritt werden die gewünschten Hardware- und Systemparameter festgelegt (z.B. CPU, RAM, Betriebssystem, IP-Adresse), mit denen eine bestimmte Instanz (sprich Server) ausgestattet sein soll.

Initiale Instanzierung

Mittels dem „run-instances“ Befehl entsteht aus der Konfiguration der neue Server. Auf diesen verbindet man sich per Remote-Desktop Connection, um das Setup durchzuführen.

Setup

In diesem Schritt können nun Docker und Puppet aufgespielt werden, damit dieser Server in weiterer Folge als Zielmaschine dieser beiden Tools verwendet werden kann. Eine AWS-Maschine kann aber auch für anderes zum Einsatz kommen, z.B. als:

  • Lizenzserver
  • Repository
  • Server für ein Drittsystem, welches in der Testumgebung benötigt wird
  • Monitoring Instanz

Templates und Template basiertes Rollout

Aus einer AWS-Maschine kann ein Template erstellt werden – es gibt aber auch von der Community vorgefertigte Templates im Marketplace.

Templates können in weiterer Folge wieder mit unterschiedlicher Hardware-Konfiguration als neue Instanz gestartet werden kann. So kann z. B. das Systemverhalten bei Last- und Performancetests auf verschieden dimensionierter Hardware sehr einfach getestet werden. Das Starten der Instanzen – basierend auf den Templates – passiert mit dem Rollout.

Aktuelle Testumgebung

Am Ende des Prozesses hat man nun eine oder mehrere aktuelle Testumgebungen. Ändern sich nun einzelne Systeme, die auf diesen Umgebungen laufen, steht einem flexiblen Neu-Deployment mittels Puppet oder Docker nichts im Weg. Alternativ dazu, muss das zugrunde liegende AWS-Template verändert und der Rollout neu gestartet werden. Bei dieser Variante ergibt sich allerdings der Nachteil, dass der Rollout von vielen Instanzen länger dauern kann, als das Verändern einzelner Systeme mit Puppet oder Docker. Zusätzlich wird bei ständigem neu erzeugen von Instanzen das IP-Adressen Management schnell unübersichtlich.

 

Sicherheit und Service-Level Agreements

Spricht man in IT-Organisationen die Cloud und deren Verwendung an, werden oft Bedenken bezüglich der Sicherheit geäußert – besonders in Bezug auf Daten. Hier gilt es, sich zu allererst als Organisation bewusst zu machen, welche Daten wirklich sicherheitskritisch sind. Nur so lässt sich ein Cloud-Konzept entwickeln und aufbauen, welches den eigenen Datenschutzanforderungen entspricht.

Kann ein Cloud-Provider möglicherweise mehr Know-how und Ressourcen für Sicherheitsmaßnahmen (z.B. Abwehr von Denial-of-Service- oder Man-in-the-Middle-Attacken) aufbieten als die eigene Organisation? Oft können mit dieser Frage Bedenken, welche die Sicherheit betreffen, zumindest hinterfragt werden.

Eine genaue Studie der Nutzungsbedingungen und SLAs, die man mit der Verwendung von Cloud-Services  akzeptiert, ist unverzichtbar. Punkte auf die man dabei achten sollte sind z.B.

  • Verfügbare Hosting-Regionen (z.B. Nordamerika, EU-West, Asien)
  • Welches Rechtssystem kommt im Problemfall zur Anwendung?
  • Wie hoch sind die garantierten Betriebszeiten?
  • Wie lange sind geplante Ausfallzeiten?
  • Wie schnell wird auf Supportanfragen reagiert?

SLAs sind aber nicht nur gegenüber dem Cloud-Provider von Bedeutung, sondern können auch innerhalb der Organisation eine Rolle spielen. Besonders in großen Unternehmen kann es vorteilhaft sein, als Verantwortlicher für den Betrieb von Testumgebungen, SLAs mit seinen internen Konsumenten (z.B. Projekte) zu vereinbaren.

 

Organisatorischer Wandel – der Weg zu modernem Testumgebungsmanagement

Von einem organisatorischen Standpunkt betrachtet, verschwimmen bei den bisher vorgestellten Ansätzen und Möglichkeiten die Grenzen zwischen Entwicklung, Test und Betrieb extrem stark. Für die Konfiguration und das zur Verfügung stellen der Infrastructure as Code Komponenten, das Wissen über die Systeme und die Beherrschbarkeit der Abhängigkeiten im Test, werden Kompetenzen aus verschiedenen Bereichen benötigt.
Als Schlagwort für das Zusammenspiel dieser Bereiche hat sich im IT-Jargon in der Zwischenzeit der Begriff „DevOps“ etabliert. Damit sich der DevOps-Ansatz auch tatsächlich in IT-Organisationen etablieren kann, sind einige Maßnahmen unabdingbar:

  • Aufbrechen von Team- und Abteilungsgrenzen
  • Austausch von Wissen und Information zwischen Development (Entwicklung), Test und Operations (Betrieb)
  • Gemeinsame Workshops zur Anforderungserhebung, Umsetzung und Betrieb der Testumgebungen
  • Commitment des Management einschließlich Bereitstellung von genügend Raum und Zeit zur Umsetzung
  • Aufgeschlossene und technologiebegeisterte Projektmitarbeiter

Natürlich erhebt diese Liste keinen Anspruch auf Vollständigkeit. Im Gegenteil: Sie ist nur die Spitze des organisatorischen Eisbergs, der noch dazu in jedem Unternehmen seine eigene Form hat. Wie bei der Planung der technischen Umsetzung, ist eine umfassende Analyse der Organisation ein essentieller Punkt. Nur so gelingt die Ausarbeitung und Umsetzung der Schritte für den Wandel, um modernes Testumgebungsmanagement erfolgreich zu betreiben.

Passende Artikel

Antwort schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*