Große Unternehmen wie z.B. ISPs (Internet-Access-Provider) oder Finanzinstitute bieten viele Dienste an, die auf klassisch entwickelter Software basieren, welche ursprünglich zum Beispiel für Mainframes entwickelt wurde und kürzlich auf virtualisierte Systeme wie vSphere portiert wurde, die auf x86-basierten Plattformen laufen. Diese oft angewandte Methodik ermöglicht eine kosteneffiziente Erneuerung und höhere Skalierbarkeit von Legacy-Software-Systemen. Ein Nachteil ist natürlich die immer noch recht langsame Fähigkeit, neue Funktionen und Dienste hinzuzufügen, nicht zuletzt wegen vergleichsweise komplexer und schwerfälliger Entwicklungs-, Test- und Rollout-Prozesse im Vergleich zu modernen, schlanken Serviceangeboten die mittels kosteneffizienten CI/CD-basierten Methoden erstellt wurden.
Was ist CI/CD?
Es handelt sich um eine Methode, mit der Anwendungen und Dienste kontinuierlich an Kunden geliefert werden und dabei alle Phasen der Anwendungsentwicklung automatisiert sind. Die wichtigsten Konzepte von CI/CD sind Continuous Integration, Continuous Delivery und Continuous Deployment. Diese vereinfachen die Codebereitstellung und Codeintegration für DevOps-Teams grundlegend.
CI/CD gewährleistet insbesondere eine kontinuierliche Automatisierung und Überwachung über den gesamten Software Lifecycle, von der Integration und Testphase bis hin zur Bereitstellung und Implementierung. Diese miteinander verwobenen Verfahren werden häufig als "CI/CD-Pipeline" bezeichnet und durch die agile Zusammenarbeit der DevOps-Teams unterstützt.
Potenzielle Gründe für das Zögern
Obwohl Internetdienstleister die Vorteile einer kontinuierlichen Integration, kontinuierlichen Bereitstellung und eines Canary Deployment nutzen möchten, scheuen sie das Risiko, sich organisch zu modernisieren und ihre Prozesse zu optimieren. Sie zögern nicht nur wegen des potenziellen finanziellen Risikos, sondern sind noch zurückhaltender hinsichtlich des dazu notwendigen Kulturwandels und noch fehlender Skills in ihren Unternehmen.
Die vorherrschende Denkweise ist nach wie vor, dass CI/CD auf einmal eingeführt werden muss, und zwar grundsätzlich disruptiv, und nicht etwa kontinuierlich in laufende Systeme integriert werden kann. Daher gehen viele Kunden davon aus, dass CI/CD nur im Greenfield Ansatz eingeführt werden kann und bestehende Systeme möglichst so lange unangetastet bleiben, bis sie aufgrund zu hoher Betriebskosten ohnehin ersetzt werden müssen.
Wir haben die Erfahrung gemacht, dass diese Annahme nicht immer richtig ist.
Eine reibungslose Migration von Legacy-Lösungen zu CI/CD basierenden Lösungen kann schrittweise erfolgen, indem man mit einer kleinen Anzahl von Anwendungen beginnt und nach und nach mehr davon anpasst. Diese Vorgehensweise bietet genügend Zeit, um die notwendigen organisatorischen Änderungen einzuleiten und Prozesse vorzubereiten, um den Migrationsprozess in kleinen Schritten von einem Proofpoint zum nächsten durchzuführen , um schließlich eine 100%ige Migration zu CI/CD zu erreichen.
Die Herausforderung, die es zu lösen gilt
Für eine erfolgreiche Einführung von CI/CD in einer Legacy-basierten Umgebung zu erreichen ist es unabdingbar, die spezifischen Projektziele (Milestones und MVPs) sowie deren Erfolgs- und Ausstiegskriterien klar zu definieren.
Was bedeutet MVP “Minimum Viable Product”?
Viele Projekte scheitern an der falschen Annahme, dass das gesamte Produkt auf einmal verstanden und entwickelt werden kann. Ein weitaus besserer Weg kann es sein, statt eines vollständigen und umfassenden Produkts Schritt für Schritt kleine, funktionsfähige Produkte zu entwickeln - so genannte Minimum Viable Products. Der Kunde kann Zug um Zug frei wählen und hat sogar die Möglichkeit, seine Meinung und seine Vorstellungen während des Prozesses zu ändern, um am Ende das Beste Ergebnis für sich herausholen zu können. Ein Beispiel ist auf dem Bild zu sehen:
with additional reference to
Posted on 2016-01-25 by Henrik Kniberg
Die Grundanforderung des Kunden könnte lauten: "Ich möchte schneller von A nach B kommen".
Das Team entwickelt ein erstes MVP (Minimum Viable Product), z. B. ein "Skateboard", das vom Kunden getestet wird.
Sein Feedback "OK, aber ich brauche vielleicht etwas zum Festhalten" formuliert genauere Anforderungen, die wiederum zum MVP des nächsten Schritts führen.
Der Prozess geht immer weiter und endet, wenn der Kunde mit dem Produkt zufrieden ist. Der Vorteil dieses Ansatzes ist, dass der Kunde mit dem Endprodukt - das er quasi mitentwickelt hat - zufrieden ist und das Entwicklungsrisiko reduziert wird, da in jedem Schritt nur ein minimaler Aufwand betrieben wird.
In dem folgenden Video (in englischer Sprache) wurde das Modell von Henrik Kniberg noch einmal schön zusammengefasst: Link
Was wird noch benötigt, um erfolgreich zu sein?
Um Missverständnisse zu vermeiden, ist eine klare Strategie erforderlich, in der beschrieben wird, was geändert werden muss, wo dies geschieht, wie es durchgeführt werden sollte und wer dafür im Einzelnen verantwortlich ist. Es ist auch wichtig, unnötige Komplexität, proprietäre Ansätze oder die Verwendung spezieller Funktionen eines bestimmten Tools zu vermeiden, die zu einer "Lock-in"-Situation für ein bestimmtes Tool führen könnten und die Offenheit und Flexibilität der Lösung nicht zu gefährden.
Einfache, allgemein eingeführte Verfahren und offene Konzepte sind der Schlüssel zum Erfolg. Entscheiden Sie sich für Elemente, die sich im Wettbewerbsumfeld bewährt haben und vermeiden Sie Nischenlösungen für Early Adopters. Für CI/CD haben sich bereits einige Tools und Frameworks in verschiedenen Anwendungsfeldern bewährt, z. B. in der Automobilindustrie und in den sozialen Medien. Diese Werkzeuge und Frameworks können gleichermaßen im ISP-Segment eingesetzt werden. Als konzeptionelle Grundlage ist es sehr sinnvoll, die CI/CD-Architektur so zu definieren, dass sie flexibel und anpassungsfähig für zukünftige Anforderungen ist.
Einige Kunden wollen ihre Artefakte und Anwendungen noch nicht als Microservices in Docker-basierten Umgebungen bereitstellen und verbleiben z.B. bei VMware. Sie entscheiden sich eher für einen schrittweisen Ansatz, bei dem Tools für die Bereitstellung oder Orchestrierung Schritt für Schritt eingesetzt werden.
Ein Beispiel für eine CI/CD-Toolchain für eine Legacy-Unternehemensumgebung.
Die Abbildung beschreibt ein typisches CI/CD-Konzept, bei dem die als RPMs entwickelten Anwendungen auf einer Linux-Umgebung auf VM-Basis laufen. Die Architektur nutzt im Wesentlichen die Tools Jfrog Artifactory, Gitlab und Ansible Tower, die installiert werden, um in mehrere unabhängigen Standorten eingesetzt zu werden, von links nach rechts beginnend mit Entwicklung, Test und Abnahme und schließlich Produktion.
Für was steht die Abkürzung RPM?
RPM Package Manager (RPM) (ursprünglich Red Hat Package Manager, jetzt ein allgemeines Akronym) ist ein kostenloses und Open Source basierendes Paketverwaltungssystem. Der Name RPM bezieht sich auf das .rpm-Dateiformat und das Paketverwaltungsprogramm selbst. RPM wurde in erster Linie für Linux-Distributionen entwickelt. Die meisten RPM-Dateien sind "binäre RPMs" (oder BRPMs), die die kompilierte Version einer Software, z. B. einer Anwendung, enthalten. Es gibt auch "Quell-RPMs" (oder SRPMs), die den Quellcode enthalten, der zur Erstellung eines Binärpakets verwendet wird.
Wofür werden die Tools eingesetzt?
Artifactory behandelt die eigentlichen Artefakte, insbesondere RPMs, die bestimmte Anwendungen bereitstellen. Es behandelt auch notwendige Betriebssystemvoraussetzungen, d. h. Patch-Sets oder Sicherheitseinstellungen, die in Golden und Base Images organisiert sind. Die spezifischen Konfigurationen der Umgebungen, die es der Anwendung ermöglichen, mit anderen zu kommunizieren, werden in Gitlab verwaltet. Beide Repositories werden zusammengefasst und als sogenannte Release-Bundles versiegelt. Sind diese Elemente am jeweiligen Ort verfügbar, kann mit dem entsprechenden Ansible Tower das Deployment der Anwendung auf der vorgesehenen VM automatisch vorgenommen werden.
Im Verlauf des CI/CD-Prozesses werden die Release-Bundles in den Repositories von Artifactory und Gitlab von links nach rechts weitergegeben oder „staged“, um schließlich in der Produktionsumgebung anzukommen.
Typischerweise befindet sich jede Umgebung an einem anderen geografischen Standort und auch in einem isolierten IP-Netzwerkabschnitt. Die IP-Verbindung wird über Sicherheits-Proxys hergestellt. Die Release-Bündel selbst sind auf ihrem Weg durch die CI/CD-Toolchain verschlüsselt und fest verbunden, nahezu versiegelt. Dadurch wird sichergestellt, dass jede potenzielle Manipulation des Release-Bündels während des CI/CD-Prozesses erkannt wird und somit keinen Schaden anrichten kann.
Während Artefakte, Base- und Golden-Images im frühen Entwicklungsprozess z. T. stark verändert werden, z.B. durch zusätzliche Securitypatches, werden sie in den folgenden Umgebungen kaum modifiziert. Einzig die Konfigurationsdaten unterscheiden sich geringfügig, da sie die unterschiedlichen Hostnamen, IP-Adressen oder Konfigurationsunterschiede in den einzelnen Umgebungen berücksichtigen müssen. In der Entwicklungs- oder Testumgebung werden oft Software-Simulatoren mit der spezifischen Anwendung verbunden sein, während in der Abnahmeumgebung und insbesondere im Produktionsbereich die Anwendung mit realen Systemen zusammenarbeitet. So steigt die Qualität der gelieferten Artefakte während des CI/CD-Prozesses von links nach rechts an. Die beschriebene Lösung ist sehr offen und flexibel und kann auch dann eingesetzt werden, wenn der Service Provider sich entscheidet Anwendungen als Microservices auf Docker-Basis zu entwickeln und über eine Orchestrierung, z.B. Kubernetes, eleganter bereitstellen möchte. In diesem Fall bleiben Artifactory und Gitlab unverändert erhalten und Ansible Tower würde eventuell durch Kubernetes und / oder Open Shift ersetzt werden.
Das skizzierte Konzept kann mit einigen anderen Tools vervollständigt werden, Keycloak für SSO und Hashicorp Vault für die Verwaltung von Anmeldeinformationen und Zertifikaten.