TECH BLOG - Einleitung 1. Teil: CI/CD Antipatterns

Ich möchte den Tech Blog mit einem Post über CI/CD Patterns und Antipatterns beginnen. Ich denke, dass die meisten hier angeführten Dos and Don’ts gut bekannt sind, dennoch halten sich aber viele der Antipatterns immer noch hartnäckig. Wenn Sie ein Neuling in Bezug auf CI/CD sind, dann sollte Ihnen die Liste zumindest helfen, die grundlegenden Konzepte hinter CI/CD zu verstehen und die gröbsten Fehler von Beginn an zu vermeiden.

Beginnen wir mit den Antipattern. Eine Liste von Dingen, die Sie davon abhalten, CI/CD erfolgreich in Ihrem Unternehmen oder Projekt anzuwenden. Wenn Ihnen also das eine oder andere Element auf der Liste vertraut ist, versuchen Sie es zu ändern!

Antipattern

Langsamer Build und aufwändiges Deployment

Langsame und unnötig komplexe Builds und Deployments sind eine sehr schlechte Sache. Zum einen verschwendet es einfach Zeit, die Entwickler zum Implementieren von Features nutzen könnten. Auf der anderen Seite führen langsame oder fehleranfällige Builds/Deployments dazu, dass Entwickler beidem aus dem Weg gehen. Anstatt Build und Deployment also regelmäßig durchzuführen, wird beides wenn möglich vermieden. Damit wird ein Build/Deployment zu einer komplizierten, seltenen und mühsamen Sache, mit der niemand wirklich umgehen kann. Builds/Deployments können langsam sein, weil...

  • während des Builds/Deployments manuelle Schritte erforderlich sind

  • automatisierte Schritte zu viel Zeit benötigen

Manuelle Schritte sind noch schlimmer als ein automatisierter, aber langsamer Build/Deployment Prozess, da dies zu Fehleranfälligkeit und Guru Bildung führt. Oft können manuelle Builds oder Deployments dann nur von einigen wenigen Leuten mit „magischen“ Deployment-Fähigkeiten durchgeführt werden – somit ist der komplette Entwicklungsprozess von einigen wenigen Personen abhängig. Ich habe für Unternehmen gearbeitet, bei denen man vorab den zuständigen Operations-Kollegen schmeicheln musste, um überhaupt ein Deployment durch zu bekommen. Anstatt also ein schnelles, automatisiertes 3-Minuten-Deployment durchzuführen, musste ein Entwickler zuerst die Operations-Kollegen überreden, das Deployment umzusetzen. Sie mit einer Tasse Kaffee zu bestechen hat gute Erfolgschancen...

Die einzelnen Schritte von Build und Deplyoment zu automatisieren, ist schon eine gute Leistung. Aber wenn es zu lange dauert, ist es immer noch ein Problem. Die Gründe dafür sind:

  • Entwickler haben längere Wartezeiten - und wenn sie nicht warten möchten, ob der Build/das Deployment erfolgreich waren, dann müssen sie später darauf zurückkommen, was zu einem mühsamen Context-Switch führt. Im schlimmsten Fall überprüfen sie den Build überhaupt nicht.

  • Lange Builds können zu Bottlenecks werden, wenn es am ungünstigsten ist - zum Beispiel, wenn Sie einen Fehler in der Produktion beheben müssen.

  • Wenn ein Build zu lange dauert, wird er weniger häufig ausgelöst, was die Fehlerrate erhöht und das Auffinden von Fehlern erschwert.

Es gibt viele Möglichkeiten, den Build/Deployment Prozess zu beschleunigen und nicht jeder Schritt muss für jede Phase der Deployment-Pipeline gleich schnell erfolgen. Versuchen Sie zunächst einmal, einen schnellen Build und ein schnelles lokales Deployment zu erreichen. Es gibt dafür kein Rezept, aber versuchen Sie, die Aktionen zu identifizieren, die am längsten dauern und beschleunigen sie diese. Ein Schritt nach dem anderen... Im Allgemeinen sollten Sie auf Tasks achten, die Dinge aus dem Internet herunterladen (zum Beispiel Maven Artifacts) und versuchen, aufwändige Tasks auf mehrere Knoten aufzuteilen und parallel auszuführen. Berücksichtigen Sie auch die Verwendung von leistungsstarker Hardware für Ihren Build-Server.

Am ärgerlichsten sind jedoch Deployments, die manchmal funktionieren und manchmal nicht. Ich weiß, dass es einige Zeit dauern kann, um herauszufinden, was falsch läuft, aber es ist den Kampf wert. Ein zuverlässiges Deployment ist die Grundlage für ein zuverlässiges Deployment und eine gut funktionierende Software. Diese Probleme müssen ohne weitere Verzögerung behoben werden.


Keine oder unzureichende Konfigurationsverwaltung

Es gibt eine goldene Regel: Alles, was Teil Ihrer Software ist, muss im Versions-Kontroll-Systems (CVS) eingecheckt sein. Jede einzelne Konfiguration, Dokumentation, Testfall und Skript muss eingecheckt werden. Dies führt dazu, dass Sie vollständige Tags und Versionen Ihrer Anwendung haben – mit wirklich allen nötigen Dateien. Das ist die Grundlage für jeden weiteren Schritt. Ein funktionierendes, vollautomatisiertes Deployment ohne funktionierendes Configuration Management ist nicht möglich. Jez Humbles liefert einen schönen Überblick in seinem Buch und auf der dazu gehörigen Website (https://continuousdelivery.com/foundations/configuration-management).

Beim Configuration Management sprechen wir nicht nur über die Konfiguration der Anwendung - das ist der erste und wichtigste Schritt. Aber auch andere Teile der Development Chain profitieren von gutem Configuration Management. Was uns zu unserem nächsten Antipattern führt:

Nicht reproduzierbare Umgebungen

Kürzlich habe ich einem Kunden dabei unterstützt, seine IT in Richtung Continuous Integration zu transformieren. Um dies zu tun, war es notwendig, eine neue Umgebung für automatisierte Akzeptant-Tests zu erstellen. Die Implementierung der Testautomatisierung einschließlich der Service Virtualisierung war eine machbare Herausforderung und funktionierte wie erwartet. Es war jedoch fast unmöglich, eine funktionierende neue Umgebung für die Anwendungen zu schaffen. Das Wissen, wie man eine geeignete Infrastruktur aufbaut und die Anwendung initial aufsetzt, war verloren gegangen. Hinzu kamen komplizierte und langsame Betriebsprozesse, was die Situation noch verschlimmerte.

Als Teil von Continuous Delivery ist es wichtig, reproduzierbare Environments zu erstellen. Die Entwicklungsumgebung, die CI/CD Tool Chain und das Erstellen der für die Anwendung nötigen Infrastruktur müssen gut dokumentiert und leicht reproduzierbar sein. Bei der Einrichtung neuer Umgebungen empfiehlt es sich, den Ansatz "Infrastructure as Code" zu verwenden. Durch die Verwendung von Konfigurationsdateien und Skripten zum Einrichten und Konfigurieren von Umgebungen kann das Setup vollständig automatisiert werden. Das ist eine ziemlich einfache Aufgabe, wenn Sie Cloud-Dienste wie AWS verwenden, bei denen Sie Ihre gesamte Infrastruktur mit Hilfe von CloudFormation-Templates (https://aws.amazon.com/de/cloudformation/) definieren können. Wenn Sie Ihre eigene Infrastruktur hosten, können Tools wie Chef oder Puppet nützlich sein. Auch die Verwendung von Docker Containern ist empfehlenswert, da es den IaC-Ansatz gut unterstützt.

Auch Continuous Integration-Tools können als Service genutzt werden, was eine einfaches Setup ermöglicht. Cloudbees (https://www.cloudbees.com/products/jenkins-cloud) bietet Jenkins als Service an, AWS hat eine eigene Continuous Integration Plattform (https://aws.amazon.com/de/codepipeline/?nc2=h_m1). Wenn das keine Option ist, können Sie beispielsweise Jenkins in Docker ausführen und dort bereitstellen, wo Sie möchten. Aber in diesem Fall muss man einige zusätzliche Anstrengungen unternehmen, um alles richtig einzurichten. Wir haben in der Vergangenheit bereits eine vollständige CI/CD-Pipeline mit Jenkins und Blue Ocean, Nexus und SonarQube mit Containern erstellt, die in AWS bereitgestellt wurden - nach der Einrichtung funktionierte es gut, aber es war jedoch zeitaufwändig, alles richtig zu konfigurieren. Auch kann es teuer werden, Jenkins selbst zu hosten, da Jenkins eine wirklich leistungsfähige Maschine benötigt, um gut zu laufen.

Wenn man innerhalb des Java-Ökosystems arbeitet, scheint eine leicht zu konfigurierende Entwicklungsumgebung immer noch eine schwierige Sache zu sein. Wenn Sie Maven oder Gradle verwenden, um Ihr Projekt zu erstellen, ist zumindest die die, die Sie verwenden und das IDE-Setup nicht mehr so wichtig. Aber Sie müssen immer noch die passenden Tools installieren und die lokale Umgebung richtig einrichten, damit alles funktioniert. Es gibt verschiedene Projekte, die sich mit Cloud-basierten IDEs beschäftigen (https://codenvy.com/product//), mit denen direkt im Browser entwickeln werden kann, aber ich habe so eine Lösung noch bei keinem unserer Kunden angetroffen.

Auch die Arbeit mit zentralisierten, vorkonfigurierten Entwicklungsumgebungen ist eine Option, hat jedoch einige Nachteile, wenn es um Anpassung und Benutzerfreundlichkeit geht. Ich denke, das Beste was man hier tun kann, ist eine saubere Installation mit Skripten und ein gutes Handbuch, wie man die lokale Entwicklungsumgebung und die notwendigen Tools einrichtet. Obwohl das ein Oldschool-Ansatz ist, habe ich noch keinen besseren für Java Enterprise-Projekte gefunden. Javascript-Entwickler lieben es, Vagrant (https://www.vagrantup.com//) zu verwenden, um ihre Entwicklungsumgebung zu erstellen und es funktioniert großartig - aber Javascript hat andere Anforderungen. Die folgende Diskussion befasst sich mit Java Entwicklungsumgebungen und Vagrant: https://stackoverflow.com/questions/17625421/vagrant-for-a-java-project-should-you-compile-in-the-vm-or-on-the-host.

Gemischte Umgebungen

Jede Umgebung (Entwicklung, Test, Integration usw.), die Sie während Ihres Entwicklungsprozesses oder als Teil Ihrer Deployment-Pipeline verwenden, sollte einen genau definierten Zweck haben. Wenn Unternehmen beginnen, Umgebungen für unterschiedliche Zwecke zu nutzen oder hier keine klaren Regeln haben, beginnt das Chaos. Das Schlimmste was Sie tun können, ist die Verwendung einer Umgebung für manuelle und automatisierte Tests. Das sorgt meist dafür, dass automatisierte Tests fehlschlagen, da manuelle Tests Testdaten geändert haben oder manuelle Tester mit dem unpassenden Setup des Environments zu kämpfen haben. Denn Sie können nur entweder eine Umgebung für die Ausführung automatisierter Tests einrichten oder das richtige Setup für manuelle Tests bereitstellen, beides ist nicht möglich. Dieser Blogeintrag gibt einen schnellen Überblick über die verschiedenen Testphasen, während wir uns entlang der Delivery-Pipeline bewegen: https://www.testingexcellence.com/delivery-pipeline-agile-project/. Im Allgemeinen kann die agile Testpyramide ein guter Indikator für die erforderlichen Umgebungen sein.



So sollten Sie also vorgehen: Definieren Sie für jede Umgebung den Zweck der Umgebung, die Teststufe, die Sie abdecken möchten und die Anforderungen an das Setup. Es macht einen großen Unterschied, ob Sie eine Umgebung für Komponententests oder End-2-End-Tests benötigen, da letztere wesentlich komplexer zu warten ist. Je besser der Zweck einer Umgebung definiert ist, desto einfacher und kostengünstiger ist es, die Umgebungen zu betreiben. Der Wert, den eine Umgebung bieten kann steigt und der Aufwand sinkt.


Walter Pindhofer

Über den Autor:

Walter Pindhofer
Chief Solution Architect / Delivery Manager

Als CSA ist Walter Pindhofer für die Konzeption und Umsetzung von maßgeschneiderten Lösungen für namhafte Enterprise Unternehmen zuständig. Als großer Befürworter von Continuous Improvement beschäftigt er sich stark mit DevOps, CI/CD und agilen Methoden.

Beschleunigen Sie Ihre Delivery!

Von Continuous Integration bis DevOps bieten wir einen strategischen Ansatz, um die Liefergeschwindigkeit und Qualität unserer Kunden zu verbessern:

  • Die Automatisierung entlang der Delivery-Pipeline beschleunigt die Zeit, die ein Feature vom Check-In bis zum Release in Produktion benötigt.

  • Unsere bewährten Methoden und Best Practices ermöglichen einen sicheren Übergang von der traditionellen Softwareentwicklung zu Continuous Delivery.
Next

TECH BLOG - Einleitung 2. Teil: CI/CD Patterns and Best Practices

26.04.2018, 11:28
#

Nachdem wir uns im vorherigen Blog-Beitrag mit Anti-Patterns beschäftigt haben, konzentrieren wir uns hier nun auf die richtige Vorgehensweise. Es gibt viele Best Practices wenn es um CI/CD geht - ich habe versucht, Patterns auszuwählen, die entweder sehr wichtig sind oder oft falsch gemacht werden. Letzteres ist der Fall für unser erstes Thema.

Mehr erfahren
Previous

Willkommen bei unserer Tech Blog Serie: Continuous Delivery von Microservices in AWS

28.03.2018, 13:55
#

Heutzutage erwarten Kunden, dass IT-Unternehmen neue Funktionen schneller als je zuvor bereitstellen. In der Vergangenheit reichte es oft noch, dass Unternehmen vierteljährlich eine neue Version eines Systems lieferten. In den letzten Jahren mussten aber viele von ihnen auf monatliche Releases umstellen, um die Kundenbedürfnisse zu erfüllen. Das scheint immer noch nicht genug zu sein. Heute erwarten Kunden einen kontinuierlichen Fluss neuer Features, wie es die großen IT-Unternehmen Google und Co. schon seit Jahren tun.

Mehr erfahren