Seminararbeit_2020/chapters/problems.tex

\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 an/inxx \todo{xx} verschiedenen
Praxisprojekten.

Die Interviews wurden mit Softwareentwicklern unter CI/CD sowie
Automatisierungs- und Integrationsexperten geführt. (CI/CD Systeme für
VM-Images (xxx\todo{xx})und Microservices in einer Vielzahl komplexer
Zielumgebungen) (xxx genauer beschreiben???)\todo{genau... genauer beschreiben}

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.

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. (beispiel einfügenXxxx und xxxx\todo{xx}

\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\todo{Blödes Problem}}\label{E06}

Unternehmens- oder Projekt-Codingrichtlinien können den Vorgaben des
gewünschten Tools widersprechen. Ein Workaround ist notwendig.

~

$\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 operativexx System, 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
x(xxx intenetquelle)

xx zu finden:

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 Aps 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 CI / CD 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$  xxxIm Falle von Konflkten geht code verlorenxx.
  Nicht gewünschter Code befindet sich in Produktion

\begin{quote}
\url{https://code.i-harness.com/de/q/6d10a0}
\end{quote}

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 GitObs (xx) 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 Gitobs(xx):
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 B03 - fehlende Möglichkeit zum kontrolliertem Stopp der Pipeline)

\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, Das
Codeanalysetool 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}

Unkenntnis über Test/ und Tool (Automatisierungs- und
Produktionsrelevanz) Tests durchlaufen alle Codezeilen, ohne die
Funktion zu testen -- Smoketestsxx erklären

Werden Tests 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 den Smoktests 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.
Das automatisierte Deployment muss in der richtigen Reihenfolge
ausgeführt werden: Der Codemigration, muss der Systemstopp folgen
\ldots{} dann sytyotm startxx \cite{connolly,plonski_herausforderungen_Leo_2020,shahin2017continuous}

~

$\Rightarrow$ Probleme im Deployment-Vorgang