Development Java

Plattformen für DevOps-Entwickler: Leistungen und Limits

Die Entwicklung von Software ist komplex. In einer Welt, in der gefühlt jedes Gerät ein Computer ist, ist Software anspruchsvoller als je zuvor. Immer neue Meisterleistungen sollen erzielt werden – und dafür ist ein Tooling erforderlich, das Entwickler bei der Bewältigung dieser Komplexität unterstützt.

Petteri Ahonen

Author

29.11.2019
Lesezeit: 11 Minuten
86 Views

Die Idealsituation: Jede neue Version von Jenkins oder Jira ist sofort verfügbar und ermöglicht es Entwicklern, unkomplizierter zu arbeiten, um einen ultimativen Kundennutzen zu erzielen.
Allerdings ist die Realität weit entfernt davon: Will ein Entwickler ein neues Tool oder eine neue Version nutzen, scheitert er oft an der IT-Abteilung seines Unternehmens: Entweder dauert das Update endlos oder die Tools sind aktuell, aber die Entwickler – je nachdem, woran sie gerade arbeiten – müssen erst Berechtigungen für einzelne Tools anfordern, statt auf den ganze Tool-Stack zugreifen zu können. Viele In-House-IT-Abteilungen hinken hinterher, wenn es darum geht, das Potenzial von Tools auszuschöpfen.
Die Folge: Statt mit automatisierten Updates und bereitgestellten Tools arbeiten zu können, bauen Teams ihre eigenen Tools und umgehen die IT-Abteilung. Diese Schatten-IT stellt ein Risiko für Sicherheit und Compliance dar, erschwert aber auch das On-Boarding neuer Mitarbeiter. Auch bedeutet das Arbeiten an eigenen Tools neben der alltäglichen Arbeit, dass weniger Zeit für die Entwicklung an sich bleibt – und genau das wäre ja der Differenzierungsfaktor zum Wettbewerb. Kurz: Aktuelle Tools sind heute Commodity und Voraussetzung für agiles Arbeiten.

Umfang einer DevOps-Plattform

Eine DevOps-Plattform ist vergleichbar mit einer integrierten Software-Produktionslinie. Das Leistungsspektrum der Plattform reicht von Anforderungsmanagement bis hin zur automatisierten Umsetzung und allem, was dazwischen liegt. Dies bezieht sich sowohl auf Tools, die von Softwareentwicklern verwendet werden, als auch auf solche, die von diesen zwar nicht direkt verwendet werden, die ihnen aber trotzdem das Leben deutlich leichter machen. Diese von uns sogenannten „DevOps“-Tools umfassen beispielsweise Dashboards für Transparenz (und Sichtbarkeit) insbesondere für die Geschäftsführung, sodass sich der Bedarf an Meetings reduzieren lässt. Ohne ausreichende Sichtbarkeit kann man zudem die Bereiche nicht identifizieren, die weiterer Verbesserungen und einer Feinabstimmung bedürfen (und kontinuierliche Verbesserungen sind ein Eckpfeiler von DevOps).
Die DevOps-Plattformen decken optimalerweise den geläufigsten Tech-Stack ab, den man für Softwareentwicklung und -betrieb (Development/Operations) braucht. Klassischerweise sind das Projektmanagement, Entwicklung, Qualitätssicherung, Releasemanagement, aber auch Tools, unter anderem für die Benutzerverwaltung, Ticket-Management, Continuous Integration (CI), Binärspeicher, internes Messaging und Testdatenmanagement. Die Integration zwischen den (automatisierten) Tools ermöglicht eine reibungslose Zusammenarbeit von Teams selbst in großen Unternehmen. Die Teams arbeiten selbstständig daran, Software nach den Wünschen eines Produktverantwortlichen zur Verfügung zu stellen, wobei für die Geschäftsführung die erforderliche Transparenz sichergestellt wird, um sich vergewissern zu können, dass alle auf dem richtigen Weg sind und aufeinander abgestimmt arbeiten.
Im Idealfall nutzen alle Teams innerhalb des Unternehmens eine zentrale Produktionsgrundlage für effiziente Zusammenarbeit und Informationsaustausch. Die Auswahl der Tools ist dabei entscheidend: Die Tools, aus denen sich die Plattform zusammensetzt, müssen sowohl erweiterbar als auch in aktiver Entwicklung sein, damit man den vollen Funktionsumfang über mehrere Jahre hinweg nutzen kann.
Die Plattform (s. Abb. 1) kann je nach Bedarf gleich als komplette Tool-Kette oder in Phasen mit Teilmengen der Plattformarchitektur implementiert werden. Diese kann später zu einer vollständigeren integrierten Prozesskette ausgebaut werden.

Abb. 1: Es gibt einige Standard-Tools für eine DevOps-Plattform (Quelle: eficode)

Die Integration von Tools

Normalerweise werden für eine umfassende Integration Projektmanagement-Tools mit dem Tool für Softwareversionskontrolle integriert, von welchem aus die automatisierten Build-, Deployment- und Testprozesse ausgelöst werden. Es gibt CI-Tools, um die Build-Pipeline zu erleichtern. Sämtliche Tools werden über einen LDAP-Server oder SSO-Dienste in eine zentrale Zugriffskontrolle integriert. Dies macht die Anforderung von Berechtigungen für einzelne Tools überflüssig. Dashboards bieten einen Überblick über die gesamte Tool-Kette. Integrationen werden mit tool- und technikspezifischen Plug-ins und Erweiterungen durchgeführt.
Zu den derzeit beliebtesten Tools in einer DevOps-Plattform zählen beispielsweise Atlassian Jira für das Management der Workflows, Confluence für Workspace-Management, Bitbucket und JFrog für Repository-Management, Jenkins, Grafana oder Sonar-Qube für Project- und Folder-Management sowie Zabbix für Dashboards und Alarms.
Ein gut integrierter Software-Produktionsprozess ermöglicht nicht nur einen reibungslosen Fluss von Features durch die Pipeline. Er lässt auch Feedback in die entgegengesetzte Richtung zu, um die Softwareproduktion mehr als nur vom Namen her agil zu machen.

Tool-Integration testen

Um die Integration zwischen Tools zum Beispiel für ein Markup-Plug-in für Jira zu testen, sollte man einen intensiven Blick auf Machbarkeit und Wartbarkeit werfen. Folgende Kriterien (s. [Ker19]) sind dabei nützlich:

Die Geschichte des Plug-ins: Wurde es gut gepflegt?
Wurde auf Fehler angemessen reagiert?
Wie oft werden Plug-in-Features nicht mehr genutzt? (Absprungrate)
Stehen bessere Alternativen zur Verfügung?
Testen Sie die Datensicherheit für Plug-ins mit hoher Da-tenintegration.

„Hausgemachte“ Lösungen

Es gibt zwei Möglichkeiten: Sie erstellen und betreiben eine Dev-Ops-Plattform selbst oder Sie überlassen beides einem externen Anbieter. Egal, welchen Weg Sie wählen – eine DevOps-Plattform wird zur unternehmenskritischen Infrastruktur, zur Produktionsumgebung, deren Entwicklung, Wartung und Betrieb für das Unternehmen erfolgskritisch ist.

Sobald der Tool-Stack an Komplexität und kritischer Bedeutung zunimmt, wird ein dediziertes Plattform-Team notwendig. Diese laufenden Kosten werden oft vergessen, wenn es um die Kalkulation der Kapitalrentabilität bezüglich Kaufen oder Selbermachen geht. Auch sind Tool-Experten für viele Technologien am Arbeitsmarkt sehr begehrt. Leichter berechnen lässt sich der TCO (Total Cost of Qwnership, Betriebskosten) beim Outsourcing.

Outsourcing – aber wohin?

Wenn Sie sich für eine DevOps-Plattform als Managed Service entscheiden, sollten Sie auf folgende Aspekte achten:

Eine Plattform muss mit dem Unternehmen wachsen können und auf einem modularen System und Service basieren. Damit wird es möglich, bei Bedarf neue Funktionen oder neue Tools zu ergänzen. Das allerdings erfordert einige Erfahrung, denn es kommen immer wieder neue Tools auf den Markt, die bewertet und ggf. integriert werden müssen.
Eine Plattform muss schnell bereitstehen, um die Vorlaufzeiten und damit auch die Kosten zu senken.
Die Tools sollten von zukunftsfähigen Unternehmen kommen, damit sie längerfristig ein Bestandteil Ihres Tool-Stacks sein können.
Tools müssen flexibel gegen praktikablere Alternativen ge-tauscht werden können, sobald diese verfügbar sind. Um diese Flexibilität zu erlangen, müssen Sie die Abhängigkeiten zwischen den Tools verstehen. Wo wurde was integriert und warum? Die Flexibilität hängt auch davon ab, welche Plattform-Architektur Sie ausgewählt haben, wie sie installiert wurde und welche Art von Integrationen zwischen den Tools stattgefunden hat.
Eine bereits vorgegebene Integration sorgt dafür, dass die an-gebundenen Tools problemlos interagieren.
Wenn Sie sich für eine DevOps-Plattform entscheiden, müssen Sie natürlich auch sicherstellen, dass sie sämtliche Tools umfasst, die Sie benötigen, und dass diese Tools ständig gewartet und aktualisiert werden.
Und natürlich müssen die Support-Optionen Ihren Erwartungen entsprechen.

Ein weiterer Vorteil einer Outsourcing-Lösung: Eine Referenz-Plattform kann zum Ausgangspunkt für ein kundenspezifisches Plattform-Design werden – auch um die Einstiegskosten zu senken. Das Tooling der Referenzarchitektur ist vorintegriert. Optimalerweise unterstützt diese Referenz-Plattform bereits eine große Auswahl an Softwareentwicklungs-Technologien und bietet eine flexible und erweiterbare Tool-Architektur mit Tools, die vom Hersteller oder einer Open-Source-Community weiterentwickelt und unterstützt werden. Damit ist auch Tool-to-Tool-Integration mit nahtlosem Informationsfluss zwischen den Tools garantiert. Ein automatisierter Installationsprozess sorgt für schnelle Bereitstellung.

Checkliste zur Berechnung der Betriebskosten von Softwaretools

Die Kosten für die Wartung von Softwaretools variieren je nach Unternehmen. Folgende Faktoren sind bei der Berechnung der Kosten zu berücksichtigen:

Direktkosten (Stunden, die von internen Mitarbeitern aufgewendet werden)

Tool-Installation
Kontinuierliche Wartung (Verfolgung der Updates, Update-Installation, System-Feinabstimmung, Kapazitätsplanung usw.)
Bereitstellen von toolbezogener Benutzerunterstützung und Helpdesk-Diensten
Tool-Integration und Pflege der bestehenden Integratio-nen
Aufbau und Aufrechterhaltung der Support-/Wartungskom-petenz
Entwicklung des Tool-Sets (Planung, Design, Installation neuer Funktionalitäten)
Wartung der grundlegenden Plattform
Aufbau und Aufrechterhaltung der Plattform-Wartungs-kompetenz
Eventmanagement und Wiederherstellung
Tool-Lizenzmanagement und -optimierung

Indirekte Kosten (ausgefallene Stunden wegen)

Probleme bei der Tool-Verfügbarkeit
Probleme bei der Integration zwischen Tools
Unzureichende Tool-Updatevorgänge (z. B. Effizienzverlus-te durch Verwendung der alten Tool-Version)
Unzureichende oder langsame Benutzerunterstützung

Opportunitätskosten

Stunden, die für die grundlegende Wartung/Unterstützung von Tools aufgewendet werden und dadurch verloren gehen (d. h. Konzentration auf die Tool-Wartung, statt Fokussierung auf eine effizientere Tool-Nutzung)

Architektonische Entscheidungen: Build-Umgebungen mit Containerisierung

Die Integration von Tools muss nicht schwierig sein: Die Tools sind so konzipiert, dass sie miteinander kommunizieren können. Es kann allerdings schwierig werden, wenn Sie mehrere Projekte mit unterschiedlichen Anforderungen haben – etwa, wenn Sie drei verschiedene Versionen eines Tools für drei verschiedene Projekte benötigen.
Eine Möglichkeit, diese Komplexität zu bewältigen, ist Contai nerisierung. Statt alle Tools auf demselben Build-Agent zu nutzen, nutzen Sie Build-Agenten in verschiedenen Docker-Containern. So verhindern Sie, dass Änderungen, die für ein Projekt vorgenommen werden, ein anderes Projekt beeinträchtigen, da jedes Projekt ein eigenes Container-Image aufweist. Darüber hinaus wird der Container nach jedem Build „vernichtet“. Dies bedeutet, dass der nächste Build komplett neu erstellt wird – mit seinem eigenen Container. Für diese Containerisierung können Sie ein CI-Plug-in verwenden. Die Einrichtung dieses Systems ist ein Beispiel dafür, wie eine Plattform-Architektur Sie entweder unterstützen oder behindern kann.

Wie eine DevOps-Plattform in der Praxis aussieht: Szenario einer nordischen Bank

Die finnische OP-Bank (s. [Efi18]) nutzt eine DevOps-Plattform, um sich mit externen Softwareentwicklern abzustimmen. „Die gesamte Java-Softwareentwicklung von OP, von der Speicherung von Code und Objekten bis hin zur Qualitätssicherung und Dokumentation erfolgt in einer zentralen, gemeinsamen Software Development Umgebung.“ Der Service muss zuverlässig sein: 99,5 Prozent Verfügbarkeit, Tag und Nacht – und genau dies ermöglicht die DevOps-Plattform.

Überlegungen zu Tooling und Zufriedenheit

In dem Buch „Accelerate: The Science of DevOps“ von Nicole Forsgren, Jez Humble und Gene Kim ist die Frage, ob die Mitarbeiter über die notwendigen Tools und Ressourcen verfügen, um ihre Arbeit zu erledigen, eines der von den Forschern verwendeten Messkriterien für Arbeitszufriedenheit. Die Förderung der eigenen Fähigkeiten bei der Arbeit stellt einen der weiteren Faktoren dar.
Moderne Software und DevOps-Tooling, das einen noch größeren Abschnitt des Software-Lebenszyklus berücksichtigt, können diese Zufriedenheit weiter anheben, indem sie wiederkehrende und fehleranfällige Prozesse automatisieren. Gut umgesetztes Tooling kann engagierte Teams entlasten – die dann ihre Ressourcen für kreativere Arbeit einsetzen. So werden neue Welten zur Realität, während die Geschäftsführung geleichzeitig die erforderliche Transparenz hat.
Eine DevOps-Plattform macht dieses Ziel greifbar, denn sie bietet eine nahtlose, integrierte Tool-Kette für die Bereitstellung qualitativ hochwertiger Software mit kurzen, planbaren Produktionszyklen.