DevOps und Agilität: Continuous Delivery und Integration verbessern - So geht's!
Continuous Delivery (CD) und Continuous Integration (CI) in eine Pipeline zu bringen, erfordert zunächst einiges an Aufwand. Dies dann weiter zu pflegen, kann Expertenwissen erfordern und viel Zeit in Anspruch nehmen. Doch wie kann man CD und CI weiter automatisieren? Wie lassen sich Prozesse weiter vereinfachen und integrieren? Wir sprachen mit Matthias Zieger darüber.
Informatik Aktuell: Herr Zieger, wenn eine Fee käme und Sie hätten drei Wünsche frei, die aber alle etwas mit Softwareentwicklung zu tun haben müssten, welche wären das?
Matthias Zieger: Was, nur 3? Nein, im Ernst… Mein größter Wunsch wäre, dass die häufig geäußerten Bekundungen der großen Unternehmen zu Agilät und DevOps nicht nur gute Worte sind, sondern das da auch Taten folgen – insbesondere dass die Verschiebung der Entscheidungen und Verantwortlichkeiten hinein in die Teams auch ernst gemeint ist. Daneben wünsche ich mir mehr Qualitätsbewusstsein in den IT-Projekten - nicht nur bei den Entwicklern - und einen bessere Nutzung der technischen Möglichkeiten, im Deployment zum Beispiel mehr modellbasierte Lösungen zu nutzen statt zu skripten.
Informatik Aktuell: Und was genau ist eine modellbasierte Deployment-Lösung?
Matthias Zieger: Im Prinzip haben Sie zur Lösung eines Deployment-Problems drei Vorgehensweisen:
- Das Team arbeitet scriptbasiert, das heißt: es werden abertausende Zeilen Shell-Scripte gebaut, gewartet und gepflegt, um ein Release auf eine Infrastruktur zu bringen. Kann man machen, ist aber teuer - vor allem in der Pflege - und fehleranfällig. Häufig ist es auch ein Wissensmonopol, das nur in den Köpfen weniger steckt.
- Sie benutzen Tools, die eigentlich für einen anderen Einsatzzweck entwickelt wurden, z. B. Continuous Integration-Werkzeuge oder Provisionierungslösungen auch für das Deployment. Auch das geht, weil alles Software ist und APIs hat, ist aber nicht im Sinne des Erfinders und kommt deswegen schnell an Grenzen der Skalierbarkeit und ist wirtschaftlich meist nicht sinnvoll.
- Alle modernen Deployment-Lösungen arbeiten modellbasiert, Sie geben dazu einfach zwei Modelle als Eingabe: Das Infrastrukturmodell, das definiert Ihre Umgebung (ApplicationServer, Datenbank, Container-Orchestrator, Cloud-API usw.), und das Applikationsmodell, also die Liste aller Artefakte, die ein Release ausmachen, nicht nur Entwickler-Artefakte, sondern auch Netzwerk/Firewall, DB-Scripte, Container-Definitionen usw.). Die Tools generieren dann daraus automatisch die Scripte und beachten auch die Reihenfolge innerhalb des Deployments und kümmern sich um Parallelisierbarkeit. Neben dem Begriff Modellbasiertes Deployment kann man auch von "Descriptivem Deployment" sprechen – ich sage dem Werkzeug nur noch WAS ich erreichen will, aber nicht WIE – dieses Wissen hat das Werkzeug quasi eingebaut.
Informatik Aktuell: Wo liegen denn die Vorteile gegenüber klassischen Deployments?
Matthias Zieger: Aus den Modellen werden ständig aktuelle Deployment-Pläne generiert und damit die Korrektheit der Pläne und generierten Scripte sichergestellt. Man erreicht dadurch eine sehr hohe Skalierbarkeit über Umgebungen und Teamgrenzen hinweg. Deployment-Verfahren lassen sich damit viel schneller an Business-Anforderungen anpassen, z. B. zero-Downtime Deployments. Die Fehlerrate und das Risiko sinken beträchtlich im Vergleich zu Scripten oder Workflows. Aus den Modellen lassen sich nicht nur Rollout-Scripte sondern auch Roll-Back-Scripte generieren. Deployment-Verfahren lassen sich delegieren, man benötigt nicht mehr den "schwarzen Gürtel im Bash-Scripting" zum Deployment. Der größte Vorteil besteht darin, dass die Teams mehr Zeit haben, sich um wichtige Themen wie Sicherheit und Performance zu kümmern, da Deployments damit einfach funktionieren.
Informatik Aktuell: Wie sieht dies in der konkreten Umsetzung denn aus?
Matthias Zieger: Sie brauchen eine Lösung, die folgendes mitbringt:
- Crossplattform-Fähigkeit: Von Mainframe- über JEE Application Server-und .net/SharePoint-Umgebungen bis hin zu Docker/Cloud und Serverless-Architekturen muss das Tool das Wissen haben, wie auf die Umgebungen ein Artefakt installiert wird.
- Das Ganze muss mit einem Konfigurationsmanagement-System unterlegt ein, in dem umgebungsabhängige Werte (z. B. Ports, Passwörter usw.) sicher ablegbar sind.
- Das Tool sollte wenn möglich eine graphische Oberfläche haben (für nicht-technische Nutzer) sowie das Model auch als Code einlesen können (Stichwort "Everything as Code").
- Im Kern der Lösung stehen ein leistungsfähiger Code-Generator und eine Rule-Engine, die den Deployment-Plan generieren.
- Natürlich sollte das Tool erweiterbar sein, um zusätzliches Deployment-Wissen in die Lösung hineinzubringen, z. B. durch Plug-ins.
Informatik Aktuell: Wieviel Aufwand ist es, dies für das Deployment zu implementieren? Ist das schwierig, muss man sich da erst einarbeiten oder kann man direkt loslegen?
Matthias Zieger: Direkt loslegen kann man, wenn man bereits Erfahrungen mit anderen Deployment-Verfahren gesammelt hat und auf eine Infrastruktur deployen möchte, die direkt vom Tool untersützt wird (z. B. alle großen JEE Server, ob kommerziell oder Open Source, Microsoft-Lösungen, Kubernetes/OpenShift). Da kann man schon viel in 3-5 Tagen erreichen. Etwas länger dauert es, wenn es eher geschlossene Umgebungen sind bzw. das Werkzeug diese nicht kennt und man Erweiterungen bauen muss.
Informatik Aktuell: Ist eine solche Lösung für jedes Unternehmen nutzbar oder gibt es Einschränkungen? Sind spezielle Voraussetzungen zu erfüllen?
Matthias Zieger: Von der Prozess-Seite her hat sich der ideale Kunde schon auf den Weg Richtung DevOps gemacht und Themen wie verteilte Versionierung, Continuous Integration und Testautomatisierung bereits angegangen und zumindest teilweise eingeführt. Technisch funktioniert so eine Lösung auch in V-Modell-Projekten, macht aber weniger Spaß in der Einführung, da man dauernd auf kulturelle Hindernisse stößt. Natürlich macht so eine Lösung in offenen Umgebungen mehr Sinn als in geschlossenen wie SAP/R3 oder Mainframe, da arbeiten wir dann mit Spezialanbietern wie Compuware zusammen, die dieses Feld besser beherrschen als wir und integrieren deren Lösung.
Informatik Aktuell: Sie sprechen im Rahmen der IT-Tage, der Jahreskonferenz des Fachmagazins Informatik Aktuellüber DevOps Intelligence. Was muss ich mir darunter vorstellen?
Matthias Zieger: Eine DevOps Intelligence-Lösung liefert KPIs, um den Zustand Ihrer Continuous Delivery-Pipeline zu zeigen. Sie kombiniert DevOps Best Practices mit historischen Analysen, maschinellen Lernprozessen und Daten aus Ihrer gesamten Toolchain, um Trends zu zeigen, Ergebnisse zu prognostizieren und Aktionen zu empfehlen. Man kann damit die Lieferpipeline optimieren und Risiken minimieren. Im Prinzip liefert DevOps Intelligence Antworten auf folgende Frage: Verwenden Sie zielgerichtete DevOps-KPIs und treffen Sie die besten Entscheidungen basierend auf Fakten?
Informatik Aktuell: Kann man so etwas wie DevOps Intelligence auch implementieren?
Matthias Zieger: Ja, viele unserer Kunden sind große Unternehmen mit oft hunderten von Applikationen und tausenden von IT-Mitarbeitern, die XebiaLabs für das Management ihrer DevOps-Prozesse benutzen. Unsere Lösungen beinhalten schon heute wichtige Reports und Dashboards, welche Auskunft über Releasestatus, Trends und Risiken geben und IT-Teams helfen, Engpässe rechtzeitig zu identifizieren und zu beheben. Wir sind gerade dabei, eine wesentlich erweiterte Lösung auf den Markt zu bringen – mehr dazu live auf den IT-Tagen in Frankfurt.
Informatik Aktuell: Wie kann man XL Deploy und XL Release testen? Gibt es zum Beispiel Trials oder andere Möglichkeiten, wie man hier tiefer einsteigen kann?
Matthias Zieger: Ja, man kann sich sehr einfach eine Trial-Version herunterladen oder auch schon als Docker-Container.
Informatik Aktuell: Worauf sollten denn Nutzer Ihrer Erfahrung nach achten?
Matthias Zieger: Wichtig ist, einen Plan zu haben, welche Verbesserungen mit den Lösungen erreicht werden sollen. Es bringt ja nichts, nur um der Lösung willen eine Evaluierung zu starten. Wir können dabei durch unser Know-how unterstützen.
Informatik Aktuell: Zum Schluss noch eine Prognose: Wie wird ein Deployment in den kommenden Jahren aussehen?
Mathias Zieger: Der Trend zu kleinteiligeren und dafür häufigeren Deployments wird anhalten. Das führt automatisch zu einem höheren Automatisierungsgrad. Es wird neue Deployment-Ziele geben, die wir heute noch nicht kennen, aber die "alten" Umgebungen werden auch noch mehrere Jahre weiterleben.
Informatik Aktuell: Herr Zieger, ganz herzlichen Dank für das Gespräch!
XebiaLabs bietet spezialisierte Lösungen zur Implementierung von Continuous Delivery- und Release-Automation. Die Werkzeuge XL Deploy und XL Release integrieren sich nahtlos in die vorhandenen Build-, CI- und Test-Werkzeuge wie CloudBees und Atlassian.
So können mit XL Deploy Deploymentprozesse automatisiert werden. Gerade in agilen Projekten kann XL Deploy – übrigens weitestgehend ohne Scripting – ein automatisertes Deployment für die großen Middlewaretechnologien wie IBM WebSphe re, Oracle WebLogic, JBoss, Tomcat und Microsoft .NET sowie Cloud-Umgebungen wie VMware und Amazon EC2 bereitstellen. XL Deploy kann nahtlos in Build-, Continuous Integration- und Provisioning-Tools wie Maven, Jenkins/Hudson, Bamboo, Puppet und Chef integriert werden.
Für erste Tests der Werkzeuge XL Deploy und XL Release, die Continuous Delivery (CD) und Continuous Integration (CI) unterstützen, können Sie eine Trial-Version oder den Docker-Container herunterladen.
Bei Fragen unterstützt Sie gerne:
Thomas Lux
Sales Director
xebialabs
com
