In der heutigen schnelllebigen Welt der Softwareentwicklung sind die Konzepte von Infrastructure as Code (IaC) und Continuous Delivery (CD) von größter Bedeutung. IaC steht für die Praxis der Verwaltung der Infrastruktur durch Source-Code, während CD der Ansatz für schnelle und automatisierte Bereitstellung von Software ist. Zusammen bilden sie die Grundlage für eine moderne, agile Entwicklungspipeline. Trotz ihrer offensichtlichen Vorteile zögern viele Teams, beides zu kombinieren. Sie verwenden CD für ihre Anwendungssoftware und IaC für die Verwaltung ihrer Infrastruktur, aber sie verwenden CD nicht für ihre Infrastruktur. Seltsam, oder? In diesem Blog-Beitrag werden wir beschreiben, was IaC und CD sind, untersuchen die Gründe für das Zögern und empfehlen Gegenmaßnahmen, um die Bedenken auszuräumen.
Was sind Infrastructure as Code und Continuous Delivery ?
Infrastructure as Code ist eine Methode, bei der die Bereitstellung, Verwaltung und Konfiguration der Infrastruktur durch Source-Code realisiert wird. Anstatt Server, Netzwerke und andere Infrastrukturkomponenten manuell einzurichten, verwenden Entwickler deklarativen oder imperativen Code, um den gewünschten Zustand ihrer Infrastruktur zu definieren. Beliebte Tools wie Terraform, AWS CloudFormation und Ansible ermöglichen es Teams, die Bereitstellung der Infrastruktur zu automatisieren, was sie vorhersehbarer, skalierbarer und effizienter macht.
Continuous Delivery bedeutet die Automatisierung des gesamten Softwarebereitstellungsprozesses, vom Kompilieren des Codes bis zur Auslieferung an den Kunden. Dies kann die Bereitstellung eines SaaS-Dienstes in der Produktionsumgebung oder die Veröffentlichung einer App in den offiziellen App-Stores bedeuten. CD zielt darauf ab, manuelle Eingriffe zu reduzieren und die Geschwindigkeit und Zuverlässigkeit von Software-Releases zu erhöhen, um sicherzustellen, dass neue Funktionen, Fehlerbehebungen und Verbesserungen so schnell wie möglich an die Endbenutzer geliefert werden. Ein wichtiger Bestandteil von CD ist das sogenannte Trunk-based Development, was bedeutet, dass keine oder nur kurzlebige Feature Branches genutzt werden. Commits werden häufig auf dem Hauptzweig (main oder master) vorgenommen, und dies löst eine Bereitstellung in der Produktionsumgebung aus. Jeder Commit wird in der Pipeline gründlich getestet, man muss sich nicht auf manuelle Tests verlassen.
Warum so zögerlich?
Viele Teams zögern, Änderungen an ihrer Infrastruktur automatisch in ihre Pipelines durchführen zu lassen. Sie befürchten, “die Produktionsumgebung kaputt zu machen”, was zu Ausfallzeiten für die Kunden führt und sofortige Abhilfe erfordert. Schauen wir uns das genauer an.
Hier sind einige gängige Probleme und mögliche Gegenmaßnahmen:
1. Mangelndes Wissen über Infrastruktur
In vielen Fällen haben Teams lange Zeit Anwendungen programmiert und sich dann in “DevOps”-Teams verwandelt, die für die Infrastruktur inklusive Bereitstellung verantwortlich sind. Das ist zwar richtig, aber es fühlt sich nicht so vertraut an, und vielleicht gibt es auch eine Wissenslücke im Vergleich zur Programmierung in einer vertrauten Sprache. Dies führt zu einer größeren Angst, die Produktionsumgebung durch Infrastrukturänderungen zu stören. Infolgedessen werden manuelle Verfahren anstelle eines vollautomatischen Prozesses genutzt.
Gegenmaßnahme 1.1: Schulungen und Coaching
Es klingt trivial, wird aber manchmal vergessen: Für erfahrene Entwickler ist es vielleicht nicht einfach, in den “Anfängermodus” zurückzukehren und sich auf etwas Neues einzulassen. Sie könnten sogar die Tatsache verbergen, dass eine Wissenslücke besteht. Aus meiner Sicht ist eine Kombination aus Schulung und Coaching erforderlich, um sie auf den neuesten Stand zu bringen und sie mit dieser neuen Technologie vertraut zu machen: Bei einer Schulung wird das notwendige Allgemeinwissen durch Präsentationen, Workshops und andere Demos vermittelt. Coaching bedeutet, dass eine außenstehende Person, der Coach, dem Team hilft, das Wissen in der Praxis anzuwenden. Er vermittelt bewährte Praktiken und Tipps.
Gegenmaßnahme 1.2: Änderungen so kleinteilig wie möglich durchführen
Eine größere Änderung in mehrere kleinere aufzuteilen (auch bekannt als “Verkleinerung der Batchgröße”) hat positive Auswirkungen – Die wichtigste ist, dass das Risiko jeder einzelnen Änderung verringert wird und es einfacher ist, zu verstehen, was schiefgelaufen ist, falls etwas Unerwartetes passiert. Außerdem wird der CD-Prozess abgehärtet wenn er häufiger durchlaufen wird – und das Team gewinnt immer mehr Vertrauen in ihn.
2. Zu wenige Tests
Sicherzustellen, dass Infrastrukturänderungen keine negativen Auswirkungen auf bestehende Systeme haben, ist eine komplexe Herausforderung. Viele Teams tun sich schwer mit umfassenden Teststrategien für ihre Infrastruktur, um die durch IaC vorgenommenen Änderungen zu validieren, und zögern daher, die Automatisierung vollständig zu übernehmen. Sie verlassen sich lieber auf manuelle Tests in einer Staging-Umgebung – dieser manuelle Schritt verlängert die Zeit bis zur Bereitstellung in Produktion drastisch.
Gegenmaßnahme 2.1: Eine Staging-Umgebung mit automatisierten End-to-End Tests
Implementiere eine Staging-Umgebung, die der Produktionsinfrastruktur gleicht. So können Änderungen in einer kontrollierten Umgebung getestet werden, bevor sie in Produktion eingesetzt werden. Automatisiere außerdem End-to-End-Tests, um die Funktionalität der Infrastruktur zu überprüfen. Eine Staging-Umgebung verstößt nur dann gegen die CD-Prinzipien, wenn es einen manuellen Testschritt gibt, was nicht der Fall sein sollte. In einer einzigen Pipeline kann man problemlos in die Staging-Umgebung deployen, Tests durchführen und dann die Änderung in die Produktionsumgebung überführen. Eine Variante davon ist die Verwendung eines kontinuierlichen anstelle eines einmaligen Tests. Tools wie Pingdom ermöglichen es Dir, den Zustand Deines Systems regelmäßig von außen zu überprüfen, und dies ist sowohl für Staging als auch für Produktion sinnvoller .
Gegenmaßnahme 2.2: Tools zum automatischen Erstellen und Löschen der Infrastruktur
Alternativ kann ein Tool wie Terratest verwendet werden. Terratest erstellt die Infrastruktur, führt Tests mit ihr durch und entfernt sie dann wieder. Es ist auf Automatisierung ausgelegt und kann daher sehr einfach in die CD-Pipeline integriert werden. Allerdings wird in der Regel in Produktion kein System von Grund auf neu erstellt, sondern aktualisiert. Das kann einen Unterschied machen, muss es aber nicht.
3. Löschung kritischer Daten
Cloud-Ressourcen können kritische Daten enthalten, z.B. in Datenbanken. Wenn diese versehentlich gelöscht werden, reicht es nicht aus, den Datenbank-Server neu aufzusetzen. Es muss sichergestellt werden, dass auch die eigentlichen Daten wiederhergestellt werden, z.B. mit Hilfe von Backups oder ähnlichem. Ein möglicher Datenverlust ist immer ein heißes Thema.
Gegenmaßnahme 3.1: Kenne die Richtlinien des Cloud-Anbieters zum Löschen von Ressourcen
Informiere dich über die Richtlinien deines Cloud-Anbieters zum Löschen von Ressourcen. Cloud-Plattformen verfügen in der Regel über Mechanismen, die das versehentliche Löschen von nicht-leeren Ressourcen verhindern. Bei AWS zum Beispiel können S3-Buckets nur gelöscht werden, wenn sie leer sind. Man muss einen speziellen Befehl “Bucket leeren” (“Empty bucket”) ausführen, oder alle Objekte manuell löschen, bevor der eigentlichen Bucket gelöscht werden kann. Bei RDS-Datenbanken ist der Löschschutz standardmäßig aktiviert. Er muss manuell ausgeschaltet werden, bevor die Datenbank gelöscht werden kann.
Gegenmaßnahme 3.2: Die Option prevent_destroy von Terraform**
Wenn du Terraform verwendest, kannst du die Option prevent_destroy nutzen, um kritische Ressourcen zu schützen. Wenn sie aktiviert ist, führt Terraform keine Befehle aus, die zur Löschung der angegebenen Ressourcen führen würden. Dazu gehört natürlich der Befehl “destroy”, aber auch jede Änderung an der Infrastruktur, die eine Neuerstellung der Ressource erfordern würde.
Fazit – Bewusst Entscheidungen treffen
Wenn du kein CD einsetzt, wirst du immer mit unnötigen Prozessaufwänden leben müssen – dies könnte die Verwendung eines Staging-Branches (einschließlich mehrfacher Zusammenführungen, Pipeline-Läufe usw.), manueller Tests und ähnlichem sein. All dies ist Aufwand, und zwar immer wieder.
Wenn du stattdessen in die Implementierung einer einfachen, aber robusten CD-Pipeline mit den oben genannten Sicherheitsmaßnahmen investierst, kannst du deinen Infrastrukturcode genauso behandeln wie deinen Anwendungscode und Änderungen viel schneller in Produktion bringen.