Blog

Digitale Transformation: Automatisierte Tests, Container und CI/CD – Teil 3

Dieser Artikel ist Bestandteil einer Reihe welches technische Aspekte der digitalen Transformation beleuchtet.

Automatisierte Tests

Beim Lernen geht es darum, Feedback zu erhalten und unsere Fähigkeit, ein Ziel zu erreichen zu verbessern. Automatisierte Tests ermöglichen es uns, wichtige Teile der Feedbackschleife näher an unsere Entwicklungsabteilung heranzuführen. Wenn wir Änderungen an unserem Code vornehmen, können wir Regressionstests einrichten, um Fehler oder unerwartete Abweichungen von den vorgesehenen Funktionen zu erkennen. Obwohl Komponententests kritisch sind, sollte ein starker Schwerpunkt für automatisierte Tests auf Szenario- oder Funktionstests liegen. Diese Art von Tests zwingen uns, über die API des Dienstes nachzudenken und erlauben es uns auch, einen Einblick zu bekommen, wie unser Code verwendet wird, da unsere Tests letztendlich Verbraucher unserer API sind. Ein starker Fokus auf Feature-Tests wird auch das von unseren Kunden erwartete Verhalten bestätigen, nicht nur das Innenleben des Codes. Schließlich, da sich die Details der Implementierung aufgrund von Refactoring, Rückzahlung der technischen Schulden, Wartung usw. ändern, sollten sich unsere Funktionstests selten ändern müssen.

Testing ist auch nicht auf Pre-Production mit vordefinierten Tests beschränkt. Wir sollten uns bemühen, sichere, risikoarme Wege zu finden, um Code-Änderungen in die Produktion zu bringen und die Ecken und Kanten unserer Systeme zu erforschen, die vordefinierte Tests verpassen würden. Testen in der Produktion ist eine Möglichkeit zu verstehen, ob Ihre Code-Änderungen wie erwartet ablaufen. Explorative Tests ermöglichen es Ihnen, Chaos in das System zu injizieren und sein Verhalten kontrolliert zu beobachten. Es ist ziemlich schwierig, eine genaue Kopie einer Produktionsumgebung (mit ihrer Konfiguration, Infrastruktur, Vernetzung usw.) in Staging- oder QA-Umgebungen zu reproduzieren. Tests, die in diesen niedrigeren Umgebungen durchgeführt werden, können ein falsches Selbstvertrauen vermitteln, wenn es darum geht, Änderungen in der Produktion vorzunehmen. Der einzige Weg, um zu wissen, dass Ihre Änderungen serienreif sind, ist, sie in der Produktion auszuführen und ihr Verhalten zu beobachten. Es gibt Möglichkeiten, dies mit Istio zu tun, während man alle negativen Folgen eindämmen kann. Zu Istio wird es einen separaten Artikel geben.

Container

Linux-Container haben zu einer massiven Veränderung der Art und Weise beigetragen, wie wir unsere Anwendungen erstellen, paketieren und ausführen. Containertechnologie wie Docker macht es Entwicklern leicht, ihre Anwendungen, Konfigurationen und Abhängigkeiten zu nehmen und sie zu einem „Image“ zu verpacken, das dann in „Containern“ ausgeführt werden kann. Container führen Ihre Anwendung als einfache Prozesse auf einem Host aus, der durch eingebaute Linux-Primitive isoliert ist.

In der Vergangenheit haben wir dies vielleicht mit VM-Images und VMs getan, aber Container erlauben es uns, nur die notwendigen Teile zu packen und den zugrunde liegenden Linux-Kernel zu teilen. Sie sind viel leichter und bringen auch Vorteile in Bezug auf die Hardwaredichte. Sobald wir uns in Containern befinden, können wir Anwendungen sicher zwischen den Umgebungen verschieben und das Divergieren von Konfigurationen und Umgebungen vermeiden. 

Da Container eine einfache, einheitliche API für das Starten, Stoppen, Inspizieren und Prüfen von Anwendungen bereitstellen, können wir generische Tools entwickeln, um diese Anwendungen auf jeder Art von Infrastruktur auszuführen, die Linux-fähig ist. Ihr Service-Betreiber und Ihre Deployment-Tools müssen nicht mehr in Handarbeit für bestimmte Sprachen und deren Eigenheiten erstellt werden. So ist Kubernetes beispielsweise eine führende Container Plattform welches mit einer übergeordneten Anwendungs-API Container auf einem Cluster von Maschinen mit ausgefeilten Orchestrierungs-, Platzierungs- und Sicherheitsmaßnahmen bereitstellen und verwalten kann. Kubernetes hat Konstrukte wie „Deployment“, die eine minimale Anzahl von Instanzen für einen bestimmten Dienst sicherstellen und auch aktiv Zustandsüberprüfungen durchführen kann. 

Continuous integration and Continuous Delivery

Im vorherigen Abschnitt haben wir uns damit beschäftigt, während des Entwicklungszyklus mit automatisierten Tests Feedback zu erhalten. Um mit einer Cloud-Native- oder Microservices-Architektur erfolgreich zu sein, müssen wir die Mechanismen für die Erstellung und Bereitstellung von Codeänderungen in der Produktion so weit wie möglich automatisieren. Continuous Integration ist eine Praxis, die Entwicklern so schnell wie möglich Feedback gibt, indem sie die Integration von Code-Änderungen so schnell wie möglich erzwingt, idealerweise mindestens einmal täglich. Das bedeutet, dass Code-Änderungen aller Teammitglieder der Versionskontrolle unterliegen, erstellt und getestet werden, um sicherzustellen, dass die Anwendung noch stabil ist und bei Bedarf freigegeben werden kann. Kontinuierliche Bereitstellung baut auf kontinuierlicher Integration (CI und CD) auf, indem sie den Teams eine automatisierte Pipeline zur Bereitstellung ihrer Anwendung in einer neuen Umgebung bietet. Continuous Delivery orchestriert die Schritte, die erforderlich sind, um eine Anwendung erfolgreich vom Code Commit bis zur Produktion zu führen. Wir sollten die Komplexität, die mit jedem Versuch der Automatisierung von Implementierungen verbunden ist, reduzieren, weshalb Container und Containerplattformen eine ausgezeichnete Wahl für den Aufbau kontinuierlicher Lieferpipelines sind. Container paketieren unsere Anwendungen zusammen mit ihren Abhängigkeiten, um Konfigurationsveränderungen und unerwartete Umgebungseinstellungen zu reduzieren, so dass wir bei der Bereitstellung unserer Anwendungen sicherer sein können.

Obwohl die Bereitstellung eine Schlüsselrolle für eine CI/CD-Plattform spielt, ist das Routing von Traffic ebenso wichtig. Was passiert, wenn wir eine neue Bereitstellung in einer Umgebung, insbesondere in der Produktion, einführen? Wir können nicht einfach die alte Version herunterfahren und die neue Version hochfahren, was einen Ausfall bedeuten würde. Wir können sie auch nicht ersetzen. Was wir wollen, ist eine Möglichkeit, den Rollout eines neuen Releases zu steuern, indem wir selektiv Traffic in die neue Software Version bringen. Um dies zu erreichen, brauchen wir die Fähigkeit, den Traffic zu kontrollieren. Mit Istio können wir z.B. den Datenverkehr zu neuen Implementierungen fein granular steuern und das Risiko reduzieren. Da wir bestrebt sind, Implementierungen schnell durchzuführen, sollten wir auch die Risiken für diese Implementierungen verringern. Istio hilft dabei.

Masiar IghaniDigitale Transformation: Automatisierte Tests, Container und CI/CD – Teil 3