Wie passt DevOps zur Standard-Software

Wenn wir über DevOps sprechen und Projekte mit der zugrunde liegenden Philosophie angehen, denken wir typischerweise an Projekte der Individual-Software. Rufen wir uns in Erinnerung, worum es bei DevOps geht, wird ziemlich schnell klar, dass es zu eng gedacht ist, DevOps nur hiermit zu verknüpfen. Die Grundideen funktionieren ganz hervorragend mit Standard-Software-Komponenten, die zur Entwicklung von Lösungen bei unseren Kunden oftmals Verwendung finden oder auch in der Kombination von Standard- und Individual-Komponenten.

Mehrwerte schaffen

Der Grundgedanke ist zunächst, dass wir unser Projekt agil managen und die Entwicklung, die Bereitstellung und den Betrieb unserer Lösungen ganzheitlich betrachten möchten. Im Sinne dieser Vorgehensweise spielen bestimmte Punkte eine besonders wichtige Rolle und der Trick ist, genau das bei der Verwendung von Standard-Entwicklungswerkzeugen so gut wie möglich zu berücksichtigen und umzusetzen.

In diesem Beitrag möchte ich Ihnen als Quick Win zwei zentrale Themen vorstellen, die hohe Mehrwerte schaffen können:

  • Das Testen und die Automation des Testens
  • Den kontinuierlichen, möglichst automatisierten Bereitstellungsprozess neuer Releases in den Echtbetrieb einer Gesamtlösung    

 

Betrachten wir das Thema Testen und die gewünschte Automation, stellen wir fest, dass in Standard-Entwicklungswerkzeugen die Möglichkeiten oft ziemlich limitiert sind. Oft ist Trial-and-Error mit mehr oder weniger rudimentären Debugging die Realität. Dies führt zu einer hohen Fehleranfälligkeit und einem sehr manuell iterativen Vorgehen bei der Qualitäts-Sicherung. Dabei muss man berücksichtigen, dass durch die Verwendung einer Standard-Entwicklungsumgebung bereits eine große Anzahl Fehler, welche bei individueller Implementierung passieren können, ausgeschlossen sind.

Die angebotenen Tool-Komponenten sind durch einen sauberen Test- und Release-Prozess entstanden und das höchstwahrscheinlich genauso in einem agilen Ansatz, wie wir ihn in der modernen Entwicklungstätigkeit anstreben. Das heißt, wir können uns beim Testen auf die zu implementierende Fachlichkeit konzentrieren.  

Hier ein Beispiel dazu.

Verwenden wir ein Standard-ETL-Tool, um einen Datenintegrations-Job zu erstellen, können wir sicher sein, dass ein im Tool enthaltener Aggregator Daten korrekt aggregiert. Diese Funktionalität müssen wir nicht testen. Allerdings müssen wir sehr wohl testen, ob wir genau jene Aggregation erzeugen, die von unserem Kunden gewünscht wird.

  • Wollen wir einen solchen Test automatisieren, können wir uns eine kleine Test-Datensenke erstellen, das kann z. B. auch ein Container sein, der nur zur Laufzeit des Tests gebraucht wird.
  • Dann geben wir dem Test die Inputs und erwarteten Outputs mit und lassen den Test immer automatisch laufen, bevor wir den Flow für den Betrieb bereitstellen und nur wenn der Test fehlerfrei ist, erfolgt das Deployment.
  • Um den Prozess wiederum durchzuführen, implementieren wir eine kleine Test-Software, welche die typischerweise vorhandenen Schnittstellen der Standard-Software zum Parametrisieren und Starten etc. der Flows anspricht.
  • Das Ganze wird sauber in einem Repository gehalten, mit den Prinzipien des automatisierten Testens (für den Test an sich) und der kontinuierlichen Bereitstellung etc.
  • Einen solchen Ansatz können wir dann wunderbar in unser Framework zur Deployment-Automation einbinden und schon haben wir die Standard-Software mit ein wenig individueller Entwicklung um die Elemente erweitert, die uns fehlen.

Umsetzung in der Praxis

Im Rahmen dieses Beitrags möchte ich Ihnen kurz aufzeigen, dass solche Ergänzungen und Erweiterungen möglich und auch sinnvoll sein können. Wie die konkrete Umsetzung aussieht, ist immer abhängig von der im Projekt eingesetzten Umgebung.

Für einen unserer Kunden haben wir Informatica Powercenter mit einem kleinen Java-Programm und einer nur zur Laufzeit mit den Testdaten befüllten Datenbank gebaut. Der gesamte Prozess wird über das Jenkins Framework gesteuert, wie andere Individual-Komponenten auch. Die korrespondierenden Artefakte werden in einem GitHub gehalten. Genauso kann es in einer anderen Projektsituation mit anderen Frameworks gelöst werden. Arbeiten wir zusätzlich mit Containern, wird das Konstrukt immer agiler. Wichtig dabei ist, immer den Aufwand- und Nutzen-Aspekt im Auge zu behalten. Bei größeren Projekten mit einem laufenden Betrieb wird sich eine solche Investition typischerweise lohnen.

Wir haben Ansätze dieser Art immer im Hinterkopf, wenn wir bei unseren Kunden Projekte umsetzen und erweitern die Funktionalität von Standard-Software gerne um diese Aspekte, da sie echte Mehrwerte erzeugen.

DevOps und Standard-Software – eine gelungene Kombination

Noch ein Tipp zum Schluss. Es gibt immer mehr Standard-Tools, die genutzt werden können, um sich Implementierungs-Aufwand zu sparen. Ist dies der Fall, lohnt es sich zu prüfen, ob die Nutzung am Ende kostengünstiger ist als eine eigene Implementierung.

Wenn Sie Interesse an einem persönlichen Austausch zu den verschiedenen Vorgehensweisen in der SW-Entwicklung haben, stehen mein Team und ich gerne zum Gespräch zur Verfügung. Schicken mir dazu eine kurze Mail an kontakt@mip.de und ich melde mich zeitnah bei Ihnen.

Joerg Kremer, Leiter Consulting der mip Gmbh

Ich freue mich auf Ihre Anfrage!

Ihr Jörg Kremer

Head of Consulting

Das könnte Sie auch noch interessieren

Aktuelles & Soziales

Making-of mip Fotoshooting

Heute habe ich ein Foto für Dich! Das ist nicht nur ein allbekannter Ausspruch von

Eine Starke Marke

mip-indoor
Die Marke mip steht für über 35 Jahre Erfahrung als Komplettanbieter für Analyselösungen zur optimalen Nutzung Ihres Datenpotentials.
mip-indoor