\chapter[Herausforderungen von CI/CD]{Herausforderungen bei der Einführung und im Betrieb von CI/CD} \label{heraus} Die Umsetzung und Einführung eines CI/CD System beinhaltet weit mehr als die einfache Automatisierung bestehender Prozesse. Sie birgt tiefgreifende Änderungen für die Softwareentwicklung im Prozess als auch im mentalen Wandel bezüglich Methode und Tools. ~ So läuft die Einführung und der Betrieb eines CI/CD Systems nicht immer reibungslos. Im Folgenden werden häufig anzutreffende Probleme skizziert, welche zum Teil typisch und häufig im Umfeld von CI/CD sind, oder durch die starke Integration besonders zum Tragen kommen. Die Problembeschreibungen basieren auf Experteninterviews, Literaturrecherchen und Beobachtungen bei verschiedenen Praxisprojekten. ~ Die Interviews wurden mit Softwareentwicklern sowie Automatisierungs- und Integrationsexperten geführt. (CI/CD Systeme für VM-Images und Microservices in einer Vielzahl komplexer Zielumgebungen) \ref{be:pfs} \ref{be:a4} ~ Meine Praxiserfahrungen basieren auf der Einführung eines CI/CD Systems unter GitLab-CI sowie dem Aufbau einer Serverless - CI/CD Plattform unter Jenkins X auf Kubernetes. \ref{be:gitlab} \ref{be:jx} ~ Eine weitere Quelle sind Fachartikel, Paper und Erfahrungsberichte zu verschiedenen CI/CD Systemen in ihrer Anwendung. ~ Die Probleme wurden erfasst und in Hinblick auf den Zeitpunkt, zu dem das Problem sichtbar wird (Einführung oder Betrieb), Problemdarstellung, Ursache und Folge analysiert. Neben dem Zeitpunkt der Problemerscheinung wird in der Darstellung nach Problemursache gruppiert. \section[Herausforderungen während der Einführung]{Probleme während der Einführung eines CI/CD System} In diesem Kapitel werden Probleme dargestellt, welche während der Planungs- und Einführungsphasen von CI/CD in Erscheinung treten, dabei können sie zu Verzögerungen im Einführungsprozess fuhren oder sogar eine Einführung verhindern. Eine wesentliche Entscheidung in dieser Phase ist die Toolauswahl. Die Nutzung einer All-in-One Lösung verspricht eine schnelle Implementierung und Verfügbarkeit von CI/CD, vor Allem wenn sie durch die firmeninternen Compliance - Vorgaben zugelassen ist (All-in-One Tool). Das individuelle CI/CD System wird auf die konkrete Projekt- und Systemumgebung (Quellcodeverwaltung, Tools zur Codeüberprüfung, Dependency-Management) ausgelegt. Häufig finden sich in dieser Lösung Tools, welche bereits im Einsatz sind und so für den Entwickler weniger Umstellung bedeuten. Unterschiedliche Einzeltools bilden zusammen mit dem automatisierten System (\textit{Build-Server}) das CI/CD System. In diesem Zusammenhang wird der Use Case definiert als eine konkrete Anwendung eines CI/CD Systems für ein Softwareentwicklungsprojekt mit allen Anforderungen des Projektes. (siehe \ref{mas:m1} \nameref{mas:m1}) \subsection[aufgrund nicht ausreichender Planungstiefe]{Probleme aufgrund nicht ausreichender Planungstiefe} Die im Anschluss dargestellten Herausforderungen bei einer Einführung von CI/CD können entstehen, wenn bei der Planung Details über den Use Case sowie die potentiellen Tools nicht tief analysiert werden. \subsubsection[E01]{\textbf{E01} - Toolauswahl deckt nicht die Anforderungen des Softwareentwicklungsprojekts}\label{E01} Insbesondere bei der Wahl eines All-in-One Tool kann es passieren, dass der Use Case nicht darstellbar ist. Beispielsweise könnte der Use Case einer Softwareentwicklung für ein Autoradio nicht mit einem All-in-One Tool für Cloud- und Webanwendung umgesetzt werden.\cite{shahin2017continuous,plonski_herausforderungen_Leo_2020} ~ $\Rightarrow$ Das CI/CD System ist nicht funktionsfähig für diese Anwendung und die Toolauswahl muss wiederholt werden \subsubsection{\textbf{E02} - Umstellung der Nutzer auf Tools und Methode}\label{E02} Gerade bei einem All-in-One Tool ist die Einführung besonders herausfordernd. Während bei einer individuellen Lösung häufig bereits existierende, dem Nutzer bekannte Tools im CI/CD -- System implementiert werden, ist bei dem All-in-One Tool häufig mehr an Umstellung zu leisten in Bezug auf Tool und Methode.\cite{plonski_herausforderungen_grund_2020,plonski_herausforderungen_Leo_2020} ~ $\Rightarrow$ Notwendigkeit von zusätzlichem Training für Methode und Tool \subsubsection{\textbf{E03} - Migrationsaufwand}\label{E03} Für ein bereits existierendes Projekt muss die Migration aus der alten Umgebung in das neue CI/CD System vorgesehen werden. Code-, Test- und Deploymentscripte sowie die Zielumgebung müssen angepasst werden (Server, Software, Internetanbindung, Security). Die problemlose Umstellung auf ein All-in-One Tool hängt stark vom Use Case ab. Es gibt Anwendungen, deren Integration ohne große Umstellungen funktionieren kann, vor allem bei Neuentwicklungen. Aber es gibt entsprechende Gegenbeispiele, welche in dieser Umstellungsphase zu Problemen oder Verzögerungen führen können.\cite{plonski_herausforderungen_grund_2020,swan_silos,clark_deliver} ~ $\Rightarrow$ Je nach Tool erheblicher Migrationsaufwand \subsubsection{\textbf{E04} - Fehlender Automatisierungsexperten/Integrationsexperte}\label{E04} Wird ein selfhosted CI/CD-System nicht durch einen Automatisierungsexperten umgesetzt und betreut, stehen die CI Tools zwar zur Automatisierung bereit, sind aber noch nicht integriert. Der Entwickler muss die Integration der Tools für sein Projekt nach eigenem Ermessen selbst vornehmen. Das führt zu einer Vielzahl unterschiedlicher Setups eines CI/CD - Systems. Diese unterschiedlichen Setups gehen zu Lasten von Wartbarkeit, Übersichtlichkeit und Fehleranfälligkeit. Bei unsachgemäßer Nutzung eines CI/CD Systems können z.B. Integrationsfehler erst im Deployment zu Tage treten, ob wohl die Tests erfolgreich durchlaufen wurden. Die Wartung des CI/CD Systems ist auch Aufgabe des Automatisierungsexperten. Ein CI/CD System benötigt kontinuierliche Wartung im laufenden Betrieb. Dazu gehört die Überwachung und Anpassung von Systemstatus, Automatisierung, Speicherverbrauch, Zertifikaten, Konfiguration und Architektur. Die Server müssen angepasst, aufgestockt, beschleunigt und die Balance überwacht werden. \cite{shahin2017continuous,plonski_herausforderungen_Leo_2020} ~ $\Rightarrow$ Im individuellen CI/CD-System muss diese Aufgabe geplant werden, während bei der All-in-One Lösung der Provider diese Aufgabe wahrnimmt \subsection[im Umfeld von Richtlinien und Standards]{Probleme im Umfeld von Richtlinien und Standards} Es gibt eine Vielzahl von projekt- und unternehmensspezifische Richtlinien, unter denen CI/CD Systeme implementiert und betrieben werden. Unkenntnis über deren Existenz oder Inhalt führen zu den folgenden Herausforderungen bei einer Einführung. \subsubsection{\textbf{E05} -- Sicherheitsrichtlinien widersprechen den Zugriffen durch das Tool\todo{anders formulieren}}\label{E05} Dazu gehören Sicherheitsrichtlinien im Unternehmen, beispielsweise könnte das Ausführen eines privilegierten Containers in einem CI/CD System nicht zugelassen sein, wenn die CI/CD Systeme Zugriffe auf Produktivsysteme besitzen und so durch ein modifiziertes CI/CD Script ein unautorisierter Zugriff auf das Produktionssystem erfolgen könnte.\cite{plonski_herausforderungen_Leo_2020,plonski_herausforderungen_grund_2020}\ref{be:jx} ~ $\Rightarrow$ Kann zum Scheitern der Systemeinführung führen oder ein Workaround ist notwendig \subsubsection{\textbf{E06} -- Coding-Konvention}\label{E06} Unternehmens- oder Projekt Coding Conventions können den Vorgaben des gewünschten Tools widersprechen. Ein Workaround ist notwendig. \cite{plonski_herausforderungen_Leo_2020} ~ $\Rightarrow$ Kann zum Scheitern der Systemeinführung führen oder ein Workaround ist notwendig \subsubsection{\textbf{E07} -- Nicht übereinstimmende Portvorgaben zwischen der Anwendungssoftware und dem Tool} \label{E07} Der Portmissmatch ist ein typisches Problem bei All-in-One Lösungen. Das CI/CD System geht davon aus, dass die Software ihren Service über einen spezifischen Port zu Verfügung stellen kann (z.B. Port 3000). Die zu migrierende Software nutzt einen anderen Port oder vielleicht überhaupt keinen Port, wenn sie z.B. einen Message-Bus anwendet. Darüber hinaus könnte das CI/CD System das operative Zielsystem, z.B. Kubernetes so konfigurieren, dass es auf einen Lifeness Check( Lebenszeichen über den Bereitschaftsstatus der Software) genau über diesen Port erhält. Solange die Software nicht angepasst ist und dieses Signal nicht empfangen kann, würde das operative System die Anwendung immer wieder neu starten, um eine Selbstreparatur zu ermöglichen.\ref{be:gitlab} \cite{plonski_herausforderungen_Leo_2020} ~ $\Rightarrow$ Pipeline zeigt ungewolltes Verhalten -- ist nicht funktionsfähig \subsubsection{\textbf{E08} -- Namespace Restriktionen}\label{E08} Eine häufig anzutreffende Richtlinie im Kubernetik-Umfeld betrifft die Vorgabe, in einem Cluster jede Anwendung im eigenen Namespace bereitzustellen. Häufig aber lässt das CI/ CD Tool nur ein Deployment auf einen fixen Namespace zu.\cite{be:gitlab,plonski_herausforderungen_Leo_2020} ~ $\Rightarrow$ Ein Workaround ist notwendig \section[Herausforderungen im Betrieb]{Probleme, welche im Betrieb eines CI/CD Systems entstehen können.} Viele Herausforderungen in einer Umstellung auf CI/CD werden erst nach der Einführung einer CI/CD Pipeline sichtbar und Probleme entstehen aus Unkenntnis über spezifische Anforderungen des Tools - der gewünschte Prozessdurchlauf funktioniert nicht und es müssen Workarounds gefunden werden - die Betriebskosten des Tools erhöhen sich. \subsection[aufgrund von erhöhte Hardwarebeanspruchung]{Probleme durch erhöhte Hardwarebeanspruchung} Eine wesentliche Änderung ist die Umstellung auf eine Softwareentwicklung durch kleine inkrementelle Änderungen, welche kontinuierlich implementiert und integriert werden. Daraus ergeben sich besondere Anforderungen an die Hardware, auf der ein CI/CD System installiert wird. \subsubsection{\textbf{B01} extreme Laufzeiten im Build-Prozess}\label{B01} CI/CD Systeme und Plattformen sind in ihrer Anwendung so ausgerichtet, dass viele Projekte parallel CI/CD betreiben. Durch den Ansatz, inkrementell kleinste Codeänderungen sofort zu integrieren, wird bei jeder Codeänderung der Build-Prozess durchlaufen.\ref{be:jx} ~ $\Rightarrow$ Dieses Vorgehen kann zu einer hohen Belastung der CPU führen, denn im Parallelbetrieb mit anderen Projekten kann es zu enormen Laufzeiten beim Build-Prozess kommen. Ein Beispiel dieser Problematik unter der Nutzung von Quarkus ist in einer meiner Projekte aufgetreten (\ref{be:jx}). \todo{check me} Quarkus ist ein neues für Webentwicklung geeignetes Java Framework (APIs und Microservices) und verspricht ein „Native Compiling`` von Java Code. Mit diesem Framework können also sehr performante APIs mit einem minimalen Bedarf an RAM erstellt werden. Ein Build-Prozess unter Quarkus ist entsprechend aufwendig. Auf einem Entwicklungs-PC lasst sich ein Build-Prozess in etwa 5 bis 10 Minuten abbilden, während er auf einem CI/CD System mit einer etwas älteren Hardware bis zu eineinhalb Stunden dauern kann. \subsubsection{\textbf{B02} erschöpfte Speicherkapazität des CI/CD System}\label{B02} Der Betrieb eines \cicd Systems kann auch in Bezug auf Speicherplatz zu Engpässen führen. Für jede kleineste Codeänderung wird das ganze Set von Artefakten generiert und abgespeichert. Dazu gehören der z.B. der Code, die Testprotokolle, Reports zur Codeanalyse, Compilerlogs, die Software selbst und ihr Containerimage.\cite{plonski_herausforderungen_Leo_2020} ~ $\Rightarrow$ Manuelles Eingreifen in die Speicherung der Artefakte wird notwendig und ist zudem fehleranfällig. Über ein CI/CD System der Telekom wurden entsprechende Probleme geschildert: Es entstehen sehr schnell sehr viele Daten und die Speichermedien laufen voll, da kontinuierlich bei jeder Änderung alles an Artefakten abgelegt wird. \subsubsection{\text{B03} - fehlende Möglichkeit zum kontrolliertem Stopp der Pipeline}\label{B03} Sobald eine gewisse Kette von Prozessen angestoßen ist, kann sie nicht mehr unterbrochen werden und auf den konsistenten Zustand zuvor zurückgesetzt werden. ~ $\Rightarrow$ Lange Wartezeiten für eine nicht mehr benötigte Pipelineausführung \subsection[aufgrund Unkenntnis über Tool und Methode]{Probleme durch Unkenntnis über Tool und Methode} \subsubsection{\textbf{B04} -- ungewolltes Aktivieren der Pipeline durch unbewusste Nutzung des Masterbranch} \label{B04} Wird versehentlich direkt auf dem Masterbranch gearbeitet und diese Änderung im Source Code Managementsystem freigegeben, kann es zur Ausführung der Release-Pipeline kommen und die Softwareversion wird unbeabsichtigt ausgeliefert.\cite{plonski_herausforderungen_Leo_2020,plonski_herausforderungen_grund_2020,shahin2017continuous}\ref{be:jx} ~ $\Rightarrow$ Nicht gewünschter Code befindet sich in Produktion. \todo{QUELLE} Dieses Problem wurde bereits in der Einleitung angerissen. Um hier eine konkrete Lösungsmöglichkeit zu erarbeiten, erfolgt eine weitere Analyse innerhalb einer konkreten Systemumgebung. Das versehentliche Arbeiten auf dem Masterbranch ist zunächst ein typisches Problem im Git und GitOps (\ref{grund:git}) Umfeld. In einem CI/CD Umfeld hat es noch viel weitreichendere Folgen, denn durch die durchgängige Automatisierung besteht das Problem nicht nur aus der ungewollten Branchüberschreibung -- es weitet sich bis in die Produktion aus. Hierzu die Darstellung dieses Falls am einem Beispiel unter \gitops (\ref{grund:git}): Mit Hilfe des Versionsmanagementsystem Git besteht die Möglichkeit, dass jeder Entwickler in seinem eigenen „Featurebranch`` an seinem Code weiterentwickelt. Dieser Code wird später im Masterbranch zusammengeführt, um die Codeänderung dem Programm zuzuführen. Wenn der Entwickler unbewusst anstelle eines persönlichen Featurebranch den Masterbranch für diese Entwicklung nutzt, wird er im weiteren Verlauf ein Push-Kommando nutzen (da er davon ausgeht, im Featurebranch zu arbeiten), um seine Änderungen in einer separaten Testumgebung zu validieren. In diesem Fall wird die Push-Operation jedoch nicht auf dem Featurebranch, sondern auf dem Masterbranch ausgeführt. Anstelle eine temporäre Testversion zu erhalten, bewirkt der Push auf dem Masterbranch die Ausführung von CI/CD für ein Release. Dies führt zum Start der Releasepipeline. Die Codeänderung landet als neues Softwarerelease im Produktionssystem und nicht, wie gewünscht, in einer Testumgebung. In diesem Fall wäre die Notwendigkeit eines kontrollierten Stopps einer Pipeline von Relevanz. Würde der Entwickler noch während der Ausführung der Releasepipeline die Situation erkennen -- wäre dieser „Notstopp`` eine Möglichkeit, das Deployment noch zu verhindern. (siehe \ref{B03} \nameref{B03}) \subsubsection{\textbf{B05} -- unbewusste Einbindung von Software, welche durch Löschungsroutinen nicht permanent zur Verfügung steht} \label{B05} Häufig gibt es Richtlinien, welche die Löschung von Artefakten einer Software nach einem vorgegebenen Zeitraum veranlassen, solange sie keinem offiziellem Release zugeordnet sind. Bei Unkenntnis über eine solche Richtlinie kann der Zugriff auf die Version der Software durch diese Löschung verloren gehen. \cite{plonski_herausforderungen_Leo_2020} ~ $\Rightarrow$ Programmabbruch \subsubsection{\textbf{B06} -- unzureichende Tests - Ungetesteter Code in Produktion}\label{B06} Die statische Codeanalyse erwartet den Source Code in einem spezifischen Ordner. Unkenntnis über diese Vorgabe kann dazu führen, dass der Source Code in einem anderen Verzeichnis bereitgestellt wird und das Analysetool findet im spezifizierten Verzeichnis keinen Code. Manche Tools melden einen positiven Status und der CI/CD Prozess läuft weiter.\ref{be:jx} \cite{shahin2017continuous} ~ $\Rightarrow$ Ungetesteter Code befindet sich in Produktion \subsubsection{\textbf{B07} -- Modultest nur auf Codeabdeckung ausgelegt} \label{B07} Werden Modultests nicht tief genug in Bezug auf die Funktionalität formuliert, kann es zwar sein, dass sie so verfasst sind, dass jede Zeile des Codes durchlaufen wird, sie dennoch nichts darüber aussagen, wie funktionsfähig das Modul oder Gesamtsystem ist. Der Code passiert die Tests mit einer positiven Statusmeldung, aber die Funktion des Moduls /Gesamtsystem ist nicht gewährleistet. \cite{connolly,shahin2017continuous} \ref{be:jx} ~ $\Rightarrow$ Funktional ungetesteter Code befindet sich in Produktion \subsubsection{\textbf{B08} -- Fehleranfälligkeit bei Migrationen für Datenbankänderungen} \label{B08} Häufig geht mit Änderungen im Code auch eine Datenbankmigration einher. Diese Datenbankmigration muss ebenfalls durch \cicd automatisierte werden. Treten während der Migration probleme auf, so müssen diese ebenfalls durch das \cicd System abgefangen werden und entsprechende Maßnamen durchgefürt werden. Sind diese Fallbacks nicht definiert, so entstehen unvorhergesehende Folgeprobleme. \cite{connolly,plonski_herausforderungen_Leo_2020,shahin2017continuous} ~ $\Rightarrow$ Probleme im Deployment-Vorgang