Das Hosten von CI/CD in der Cloud kann sowohl die Interaktion zwischen Entwicklungspipelines und Quellcode-Repositories beschleunigen als auch das Leben für Entwickler einfacher machen. [...]
Wenn Ihr Ziel eine schnelle Software-Entwicklung und die häufige Bereitstellung von funktionierenden Builds für die Produktion ist, müssen Sie zumindest einen Teil des Test- und Bereitstellungsprozesses automatisieren. Im Idealfall bedeutet das, dass Sie CI/CD-Pipelines für Ihre Projekte implementieren, zusammen mit Testsuiten, um Fehler abzufangen, bevor die Kunden die Software zu Gesicht bekommen, und Skripten, die die Schritte der Pipelines implementieren.
Continuous Integration (CI) ist eine Methodik zur Automatisierung von Software-Builds, Paketierung und Tests auf konsistente Weise. CI hilft einem Team, sich darauf zu verlassen, dass Änderungen, die sie in die Versionskontrolle des Quellcodes einchecken, den Build nicht zerstören oder Fehler in die Software einbringen. Der Endpunkt von CI ist typischerweise ein abgeschlossener Check-In in den Hauptzweig eines Software-Repositorys.
Continuous Delivery (CD) automatisiert die Auslieferung von getesteter Software an Infrastrukturumgebungen. Das bedeutet normalerweise nicht, dass man sie direkt in die Produktion wirft, um zu sehen, ob sich die Kunden beschweren. Typischerweise beginnen Unternehmen damit, den Build in eine Entwicklungsumgebung zu schieben. Nachdem die Entwickler selbst auf den neuen Build einschlagen und ihn freigeben, geht er normalerweise in eine Testumgebung, in der er von einer breiteren Gruppe von Nutzern verwendet wird (manchmal nur von dedizierten internen Testern, manchmal von einem größeren Kader von Nutzern, die sich für Beta-Tests oder „dog-fooding“ angemeldet haben) und genau überwacht wird. Schließlich, wenn alles gut läuft, melden die Tester die neue Version ab und schieben sie in eine Produktionsumgebung.
In jeder Phase der CD gibt es Optionen, um schnell zu einem älteren Build zurückzukehren und Bug-Report-Tickets für die Entwickler zu generieren, die in dem neuen Build behoben werden. Das Ziel ist es nicht, viele Builds in die Produktion zu schieben, sondern die Software kontinuierlich zu verbessern und zu erweitern, ohne Regressionen einzuführen. Ein anderer Begriff für diese Praktiken ist „Devops“.
Warum sollte man CI/CD in der Cloud hosten?
Das Hosten einer CI/CD-Plattform im eigenen Rechenzentrum ist eine praktikable Option, insbesondere für Unternehmen, die ihre Anwendungen und Daten innerhalb der Firewall hosten müssen. Der Nachteil dabei ist, dass Sie ein dediziertes Team für die Wartung der Infrastruktur benötigen und einige Investitionskosten für Server anfallen.
Wenn Sie die Möglichkeit haben, in der Cloud zu hosten, ist dies in der Regel die bessere Option. Die Kosten für das Hosting in der Cloud sind bescheiden, und diese Betriebskosten werden durch die bereitgestellten Services ausgeglichen: Onboarding, Wartung der Infrastruktur, Sicherheitswartung, Support und Wartung der CI/CD-Software. Wenn Sie Ihre CI/CD-Software in der Cloud hosten, ist es für die Pipelines oft einfacher und schneller, mit Ihren Quellcode-Repositories zu interagieren, wenn diese sich ebenfalls in der Cloud befinden. Wenn Ihre Entwickler und Tester geografisch verteilt sind, bietet das Hosten Ihrer Repositories in der Cloud den Entwicklern häufig eine bessere Erfahrung als das Hosten in entfernten Servern hinter Firewalls.
Es ist auch möglich, CI/CD auf einem Hybrid aus On-Premises– und Cloud-Servern zu implementieren. Einige der neuesten CI/CD-Angebote werden in Containern auf Kubernetes-Clustern ausgeführt, die sowohl vor Ort als auch in der Cloud eingesetzt werden können. In einem hybriden Bereitstellungsszenario können Sie jede Komponente dort platzieren, wo sie angesichts des physischen Standorts der Entwickler selbst und der Netzwerkstandorte der anderen Server in der Entwicklungsinfrastruktur am sinnvollsten ist.
CI/CD muss mit Ihren Repositories integriert werden
Wie Sie vielleicht gemerkt haben, wenn Sie lesen „der Endpunkt von CI ist typischerweise ein abgeschlossener Check-In in den Hauptzweig eines Software-Repositorys„, sind Repos für CI und CD essentiell. Abgesehen davon, dass sie der Endpunkt des Check-In- und Test-Prozesses sind, sind Software-Repositories der bevorzugte Ort, um Ihre CI- und CD-Skripte und Konfigurationsdateien zu speichern. Ja, viele der CI/CD-Plattformen können Skripte und andere Dateien intern speichern, aber Sie sind in der Regel besser dran, wenn Sie sie in der Versionskontrolle außerhalb des Tools haben.
Fast alle CI/CD-Tools können mit Git interagieren. Einige integrieren sich auch direkt mit GitHub, GitHub Enterprise, GitLab und/oder Bitbucket. Einige wenige unterstützen auch Subversion und/oder Mercurial.
Ihre CI/CD-Tools müssen Ihre Programmiersprachen und Tools unterstützen
Jede Programmiersprache oder Sprachgruppe (JVM-Sprachen, LLVM-kompilierte Sprachen, .NET-Sprachen usw.) hat in der Regel ihre eigenen Build-Tools und Test-Tools. Um für Sie nützlich zu sein, muss ein CI/CD-Tool alle Sprachen unterstützen, die Teil eines bestimmten Projekts sind. Andernfalls müssen Sie möglicherweise ein oder mehrere Plug-ins für das Tool schreiben.
Docker-Images werden für verteilte, modulare und Microservice-Softwarebereitstellungen immer wichtiger. Es ist sehr hilfreich, wenn Ihr CI/CD-Tool weiß, wie man mit Docker-Images umgeht, einschließlich der Erstellung eines Images aus Ihrem Quellcode, den Binärdateien und den Voraussetzungen sowie der Bereitstellung eines Images in einer bestimmten Umgebung. Wenn dies nicht der Fall ist, müssen Sie möglicherweise Plug-ins oder Skripte schreiben, um die benötigten Docker-Funktionen zu implementieren. In ähnlicher Weise möchten Sie, dass Ihr CI/CD-Tool Kubernetes und andere Container-Orchestrierungssysteme unterstützt, die Sie in Ihren Umgebungen verwenden.
Verstehen Ihre Entwickler CI/CD und die Tools, die Sie in Betracht ziehen?
Die Prinzipien von CI und CD mögen offensichtlich erscheinen, aber die Details sind es nicht. Die verschiedenen CI/CD-Tools haben einen unterschiedlichen Grad an Unterstützung und Dokumentation. Es gibt mehrere Bücher über Jenkins, was nicht verwunderlich ist, da es das älteste Produkt der Reihe ist. Für andere Produkte müssen Sie möglicherweise die Dokumentation, die Support-Foren und die kostenpflichtigen Support-Optionen als Teil Ihrer Due Diligence bei der Auswahl eines Tools untersuchen.
Für allgemeines Hintergrundwissen über CI empfehlen wir das Addison-Wesley Buch Continuous Integration von Duvall et al. Für allgemeines Hintergrundwissen über CD empfehlen wir Continuous Delivery von Humble und Farley. Beide Bücher wurden bei ihrer Veröffentlichung mit dem Jolt Award ausgezeichnet.
Sie können verschiedene CI/CD-Tools für verschiedene Projekte wählen
Obwohl es in diesem Leitfaden um die Auswahl einer CI/CD-Plattform geht, sollten Sie nicht davon ausgehen, dass eine Plattform für alle Ihre Softwareentwicklungsprojekte optimal ist. Die meisten Unternehmen verwenden mehrere Programmiersprachen und Umgebungen, und nicht jede CI/CD-Plattform wird alle davon gut unterstützen.
Fühlen Sie sich frei, die CI/CD-Plattformen auszuwählen, die für jedes Ihrer Projekte am besten funktionieren, anstatt eine einzige Kompromissplattform zu finden. Die allgemeinen Prinzipien von CI und CD lassen sich von einer Plattform zur anderen übertragen, auch wenn die Skripte, die Sie dafür schreiben, nicht immer portabel sind. Die zusätzliche Onboarding-Zeit für jede neue Plattform kann Ihr Devops-Team zwar etwas Zeit kosten, aber das ist höchstwahrscheinlich weniger kostspielig, als wenn Sie ein CI/CD-Tool umfassend anpassen müssten.
Planen Sie für zukünftige CI/CD-Migrationen
Gehen Sie auch nicht davon aus, dass eine bestimmte CI/CD-Plattform die Anforderungen Ihrer Projekte für immer erfüllen wird. Sichern Sie sich immer ab, indem Sie zum Beispiel Skripte in Repositories statt im CI/CD-Tool speichern.
Bevorzugen Sie serverloses CI/CD, wo es angebracht ist
Im Allgemeinen sind Cloud–Container-Implementierungen kostengünstiger als Cloud-Server-Instanz-Implementierungen, und serverlose Cloud-Implementierungen sind kostengünstiger als Container-Implementierungen. Leider können zum jetzigen Zeitpunkt nur wenige CI/CD-Plattformen Serverless ausführen.
Serverless bedeutet, dass der Container, in dem der gewünschte Prozess ausgeführt wird, nach Bedarf instanziiert wird, in der Regel als Reaktion auf ein Ereignis. Bei CI/CD ist das auslösende Ereignis in der Regel ein Code-Check-in in einen bestimmten Repository-Zweig; der Repository-Webhook startet dann den Serverless-Prozess. Wenn der Prozess abgeschlossen ist, werden die Ressourcen freigegeben.
Eine der wenigen CI/CD-Plattformen, die Serverless ausführen können, ist Serverless CI/CD, Teil von Serverless Framework Pro, einer erweiterten Version des Open Source Serverless Framework. Serverless CI/CD ist für die Bereitstellung von Serverless-Apps optimiert und läuft derzeit nur auf AWS. Sie müssen feststellen, ob es Ihre Anwendung gut genug unterstützt, um es zu verwenden.
Wo befinden sich Ihre aktuellen Cloud-Assets?
Um eine Cloud-basierte CI/CD-Konfiguration (oder jede andere Cloud-Anwendung) zu optimieren, ist es hilfreich, wenn sich alle Ihre Assets „in der Nähe“ befinden. „In der Nähe“ bezieht sich in diesem Zusammenhang teilweise auf den geografischen Standort und teilweise auf den Netzwerkstandort.
Wenn sich zum Beispiel Ihre Datenbank in Australien und Ihre Anwendung in Nordamerika befindet, werden Sie jedes Mal, wenn die Anwendung Daten lesen oder schreiben muss, eine große Verzögerung haben. Wenn sich Ihre Anwendung und Ihre Datenbank in der gleichen Availability Zone (AZ) befinden, wird die Latenz zwischen ihnen minimiert. Wenn sie sich in verschiedenen Zonen in derselben Region befinden, wird die Latenz höher sein, aber nicht so hoch, wie wenn sie sich in verschiedenen Regionen befinden.
Ähnlich verhält es sich, wenn sich Ihre Datenbank auf Google Cloud Platform in Virginia und Ihre Anwendung auf Microsoft Azure in Virginia befindet, wird die Latenz höher sein, als wenn sich beide auf demselben Cloud-Anbieter in derselben AZ befinden. All dies gilt auch für Ihr Repository (das im Wesentlichen eine Datenbank ist), Ihre CI/CD-Software, Ihre eigentliche Anwendung und Ihre Entwickler und Tester. Es hilft, wenn alle „in der Nähe“ sind, obwohl die Auswirkungen der Verzögerung in dieser Situation nicht so eklatant sind, wie sie es beispielsweise bei einem interaktiven Echtzeitspiel wären.
Wenn die Entwickler Code-Commits zuverlässig und ohne merkliche Wartezeiten in das Master-Repository schieben können, werden sie in der Regel zufrieden sein. Ähnlich verhält es sich, wenn die Benutzer und Tester „nah“ genug an der Anwendung sind, um Antwortzeiten von weniger als einer Sekunde zu erhalten. Für die CI/CD-Software ist der Schlüssel eine zuverlässige Verbindung zu den Bereitstellungspunkten. Eine kleine Verzögerung kann toleriert werden, solange sie nicht zu Timeouts oder verlorenen Paketen führt.
Führen Sie einen Proof of Concept durch, bevor Sie sich festlegen
CI/CD wird ein wichtiger Teil Ihrer Infrastruktur sein, sobald Sie es vollständig implementiert haben. Denken Sie daran, wenn Sie sich auf den Weg machen.
Es ist wichtig, einen rigorosen Proof of Concept durchzuführen, bevor Sie mit dem Rollout der CI/CD-Pipelines beginnen. Testen Sie den CI-Teil, bevor Sie mit der CD-Phase beginnen. Stellen Sie sicher, dass Sie Ihre Testsuiten und Rollback-Funktionen trainieren, bevor Sie die CI/CD-Pipelines mit den Produktionsinstanzen verbinden, und halten Sie die Menschen auf dem Laufenden, bis Sie sich sicher sind, dass die Automatisierung stabil ist.
*Martin Heller ist ein mitwirkender Redakteur und Rezensent für InfoWorld. Früher war er als Berater für Web- und Windows-Programmierung tätig und entwickelte von 1986 bis 2010 Datenbanken, Software und Websites. In jüngerer Zeit war er als VP für Technologie und Bildung bei Alpha Software sowie als Vorsitzender und CEO bei Tubifi tätig.
Be the first to comment