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.
Ich freue mich auf Ihre Anfrage!
Ihr Jörg Kremer
Head of Consulting
