adding problems

bibliography.bib

@@ -62,3 +62,50 @@
     url = "https://services.google.com/fh/files/misc/state-of-devops-2019.pdf"
     note = "[Online; accessed 18-März-2020]"
 }
+
+@misc{clark_deliver,
+	title = {Deliver quality software at speed with {CI}/{CD}},
+	url = {https://www.computerweekly.com/feature/Deliver-quality-software-at-speed-with-CI-CD},
+	abstract = {Continuous integration and delivery promises a remarkable acceleration in software development, but some basics need to be in place to ensure success},
+	language = {en},
+	urldate = {2020-03-19},
+	journal = {ComputerWeekly.com},
+	author = {Clark, Lindsay}
+}
+
+@misc{connolly,
+	title = {A {Year} of {Continuous} {Deployment}: {Lessons} {Learned}},
+	shorttitle = {A {Year} of {Continuous} {Deployment}},
+	url = {https://dzone.com/articles/a-year-of-continuous-deployment-lessons-learned},
+	abstract = {Seizing an opportunity in the development of a new feature to being a continuous deployment cycle from a greenfield service, this team reviews what they learned.},
+	language = {en},
+	urldate = {2020-03-19},
+	journal = {dzone.com},
+	author = { Connolly , Stephen}
+}
+
+
+@misc{swan_silos,
+	title = {Silos {Begone}! {The} {Road} to {DevOps} at {Autodesk} and {Lessons} {Learned} {Along} the {Way}},
+	url = {https://www.cloudbees.com/blog/silos-begone-road-devops-autodesk-and-lessons-learned-along-way},
+	language = {en},
+	urldate = {2020-03-19},
+	author = {Swan, George}
+}
+
+
+@misc{plonski_herausforderungen_grund_2020,
+	title = {Herausforderungen beim {Einführen} und {Betreiben} von {CI}/{CD}},
+	author = {Nobach, Leonhard},
+	collaborator = {Plonski, Manuel},
+	month = march,
+	year = {2020}
+}
+
+@misc{plonski_herausforderungen_Leo_2020,
+	title = {Herausforderungen beim {Einführen} und {Betreiben} von {CI}/{CD}},
+	author = {Grund, Norbert},
+	collaborator = {Plonski, Manuel},
+	month = march,
+	year = {2020}
+}

chapters/experience.tex

@@ -0,0 +1,4 @@
+\chapter{Beobachtungen durch Projekte xxx}\label{beobachtung}
+
+\section{CI/CD GitLab xx}\label{be:gitlab}
+\section{CI/CD auf Jenkins X}\label{be:jx}

chapters/grund.tex

@@ -261,7 +261,7 @@ da es im Branchpattern entsprechend definiert wurde.
 \def\labelenumi{(\arabic{enumi})}
 \setcounter{enumi}{2}
 \item
-  \textbf{Übertragung und Test in der Developmentumgebung xx}
+  \textbf{Übertragung und Test in der Developmentumgebung xx\todo{xx}}
 \end{enumerate}
 
 Sind die Entwicklungsaktivitäten auf dem Featurebranch erfolgreich

chapters/problems.tex

@@ -0,0 +1,399 @@
+\chapter[Herausforderungen von CI/CD]{Herausforderungen bei der Einführung und im Betrieb von CI/CD}
+
+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}
+
+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}
+
+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}
+
+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,article:google}
+
+~
+
+$\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}}
+
+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.
+
+~
+
+$\Rightarrow$ Kann zum Scheitern der Systemeinführung führen oder ein Workaround ist
+  notwendig
+
+\subsubsection{\textbf{E06} -- Coding-Konvention}
+
+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
+
+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.
+
+~
+
+$\Rightarrow$ Pipeline zeigt ungewolltes Verhalten -- ist nicht funktionsfähig
+
+\subsubsection{\textbf{E08} -- Namespace Restriktionen}
+
+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.
+
+~
+
+$\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}
+
+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.
+
+~
+
+$\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}
+
+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.
+
+~
+
+$\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.
+
+Kollege xxx --
+
+\subsubsection{\text{B03} - fehlende Möglichkeit zum kontrolliertem Stopp der
+Pipeline}
+
+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}
+
+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.
+
+~
+
+$\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.
+
+Das bedeutet den 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}
+
+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.
+
+~
+
+$\Rightarrow$ Programmabbruch
+
+
+\subsubsection{\textbf{B06} -- unzureichende Tests - Nutzung des CI/CD Systems}
+
+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.
+
+~
+
+$\Rightarrow$  Ungetesteter Code befindet sich in Produktion
+
+
+\subsubsection{\textbf{B07} -- Modultest nur auf Codeabdeckung ausgelegt}
+
+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.
+
+~
+
+$\Rightarrow$  Funktional ungetesteter Code befindet sich in Produktion
+
+
+\subsubsection{\textbf{B08} -- Fehleranfälligkeit bei Migrationen für
+Datenbankänderungen}
+
+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
+
+~
+
+$\Rightarrow$ Probleme im Deployment-Vorgang
+

classicthesis.sty

@@ -298,6 +298,8 @@
 % Disable single lines at the end of a paragraph (Hurenkinder)
 \widowpenalty = 10000
 \displaywidowpenalty = 10000 % formulas
+% Disable intent globaly
+\setlength{\parindent}{0pt}
 
 % Graffiti as in GKP's book "Concrete Mathematics"
 % thanks to Lorenzo Pantieri and Enrico Gregorio

customnumber.tex

@@ -0,0 +1,29 @@
+\newcounter{alphasect}
+\def\alphainsection{0}
+
+\let\oldsubsection=\subsection
+\def\subsection{%
+  \ifnum\alphainsection=1%
+    \addtocounter{alphasect}{1}
+  \fi%
+\oldsubsection}%
+
+\renewcommand\thesubsection{%
+  \ifnum\alphainsection=1% 
+    \Alph{alphasect}
+  \else%
+    \arabic{section}
+  \fi%
+}%
+
+\newenvironment{alphasection}{%
+  \ifnum\alphainsection=1%
+    \errhelp={Let other blocks end at the beginning of the next block.}
+    \errmessage{Nested Alpha section not allowed}
+  \fi%
+  \setcounter{alphasect}{0}
+  \def\alphainsection{1}
+}{%
+  \setcounter{alphasect}{0}
+  \def\alphainsection{0}
+}%

pandoc/problems-temlp.tex

@@ -0,0 +1,407 @@
+3 Beeinträchtigung(xxProbleme) bei der Einführung und im Betrieb von
+CI/CD
+
+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 verschiedenen
+Praxisprojekten.
+
+Die Interviews wurden mit Softwareentwicklern unter CI/CD sowie
+Automatisierungs- und Integrationsexperten geführt. (CI/CD Systeme für
+VM-Images (xxx)und Microservices in einer Vielzahl komplexer
+Zielumgebungen) (xxx 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.
+
+\emph{\textbf{Kapxx 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 (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
+
+\textbf{\textgreater\textgreater Kapitel xxx 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.
+
+\textbf{E01 - Toolauswahl deckt nicht die Anforderungen des
+Softwareentwicklungsprojekts}
+
+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.
+
+\begin{itemize}
+\item
+  das CI/CD System ist nicht funktionsfähig für diese Anwendung und die
+  Toolauswahl muss wiederholt werden
+\end{itemize}
+
+\textbf{E02 Umstellung der Nutzer auf Tools und Methode}
+
+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.
+
+\begin{itemize}
+\item
+  Notwendigkeit von zusätzlichem Training für Methode und Tool
+\end{itemize}
+
+\textbf{E03 Migrationsaufwand}
+
+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.
+
+\begin{itemize}
+\item
+  Je nach Tool erheblicher Migrationsaufwand
+\end{itemize}
+
+\textbf{E04 - Fehlender Automatisierungsexperten/Integrationsexperte}
+
+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.
+
+\begin{itemize}
+\item
+  Im individuellen CI/CD-System muss diese Aufgabe geplant werden,
+  während bei der All-in-One Lösung der Provider diese Aufgabe wahrnimmt
+\end{itemize}
+
+\textbf{Kap - \textgreater{} 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.
+
+\textbf{E05 -- Sicherheitsrichtlinien widersprechen den Zugriffen durch
+das Tool}
+
+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.
+
+\begin{itemize}
+\item
+  Kann zum Scheitern der Systemeinführung führen oder ein Workaround ist
+  notwendig
+\end{itemize}
+
+\textbf{E06 -- Coding-Konvention}
+
+Unternehmens- oder Projekt-Codingrichtlinien können den Vorgaben des
+gewünschten Tools widersprechen. Ein Workaround ist notwendig.
+
+\begin{itemize}
+\item
+  Kann zum Scheitern der Systemeinführung führen oder ein Workaround ist
+  notwendig
+\end{itemize}
+
+\textbf{E07- Nicht übereinstimmende Portvorgaben zwischen der
+Anwendungssoftware und dem} Tool
+
+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.
+
+\begin{itemize}
+\item
+  Pipeline zeigt ungewolltes Verhalten -- ist nicht funktionsfähig
+\end{itemize}
+
+\textbf{E08 -- Namespace Restriktionen}
+
+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.
+
+\begin{itemize}
+\item
+  ein Workaround ist notwendig
+\end{itemize}
+
+\emph{\textbf{Kap. 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.
+
+\textbf{Kap 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.
+
+\textbf{B01 extreme Laufzeiten im Build-Prozess}
+
+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.
+
+\begin{itemize}
+\item
+  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.
+\end{itemize}
+
+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
+
+\textbf{B02 erschöpfte Speicherkapazität des CI/CD System}
+
+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.
+
+\begin{itemize}
+\item
+  Manuelles Eingreifen in die Speicherung der Artefakte wird notwendig
+  und ist zudem fehleranfällig.
+\end{itemize}
+
+Ü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.
+
+Kollege xxx --
+
+\textbf{B03 - fehlende Möglichkeit zum kontrolliertem Stopp der
+Pipeline}
+
+Sobald eine gewisse Kette von Prozessen angestoßen ist, kann sie nicht
+mehr unterbrochen werden und auf den konsistenten Zustand zuvor
+zurückgesetzt werden.
+
+\begin{itemize}
+\item
+  Lange Wartezeiten für eine nicht mehr benötigte Pipelineausführung
+\end{itemize}
+
+Kapitel Probleme durch Unkenntnis über Tool und Methode
+
+\textbf{B04 -- ungewolltes Aktivieren der Pipeline durch unbewusste
+Nutzung des Masterbranch}
+
+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.
+
+\begin{itemize}
+\item
+  xxxIm Falle von Konflkten geht code verlorenxx
+\item
+  Nicht gewünschter Code befindet sich in Produktion
+\end{itemize}
+
+\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.
+
+Das bedeutet den 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)
+
+\textbf{B05 -- unbewusste Einbindung von Software, welche durch
+Löschungsroutinen nicht permanent zur Verfügung steht}
+
+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.
+
+\begin{itemize}
+\item
+  Programmabbruch
+\end{itemize}
+
+\textbf{B06 -- unzureichende Tests - Nutzung des CI/CD Systems}
+
+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.
+
+\begin{itemize}
+\item
+  Ungetesteter Code befindet sich in Produktion
+\end{itemize}
+
+\textbf{B07 -- Modultest nur auf Codeabdeckung ausgelegt}
+
+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.
+
+\begin{itemize}
+\item
+  Funktional ungetesteter Code befindet sich in Produktion
+\end{itemize}
+
+\textbf{B08 -- Fehleranfälligkeit bei Migrationen für
+Datenbankänderungen}
+
+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
+
+\begin{itemize}
+\item
+  Probleme im Deployment-Vorgang
+\end{itemize}

thesis.tex

@@ -45,6 +45,7 @@
 \input{classicthesis-config}
 \input{begriffe}
 \usepackage{todonotes}
+%\usepackage{cite}
 %*************************************************************************
 % Bibliographies
 %*************************************************************************
@@ -98,24 +99,26 @@
 
 \cleardoublepage
 \include{chapters/grund}
+\include{chapters/problems}
 \include{chapters/fazit}
 
 \cleardoublepage
-\part{Work in Progress}\label{pt:wip}
+%\part{Work in Progress}\label{pt:wip}
-\include{chapters/VorNach}
+%\include{chapters/VorNach}
 %\part{Gliederung}\label{pt:thesis}
-\include{chapters/Gliederung}
+%\include{chapters/Gliederung}
 %\include{chapters/examples/chapter02}
 %\include{chapters/examples/chapter03}
 \listoftodos
 %*************************************************************************
 % Backmatter
 %*************************************************************************
-%\appendix
+\appendix
-%\renewcommand{\thechapter}{\alph{chapter}}
+\renewcommand{\thechapter}{\alph{chapter}}
 \cleardoublepage
-%\part{Appendix}
+\part{Appendix}
-%\include{chapters/examples/appendix01}
+\include{chapters/experience}
+\include{chapters/examples/appendix01}
 %\include{chapters/examples/appendix02}
 %*************************************************************************
 % Other Stuff in the Back