xx wurde ge x

chapters/problems.tex

@@ -11,17 +11,17 @@ 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
+Literaturrecherchen und Beobachtungen bei verschiedenen
 Praxisprojekten.
 
-Die Interviews wurden mit Softwareentwicklern unter CI/CD sowie
+Die Interviews wurden mit Softwareentwicklern 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}
+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.
+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.
@@ -54,7 +54,7 @@ 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}
+allen Anforderungen des Projektes. (siehe \ref{mas:m1} \nameref{mas:m1})
 
 \subsection[aufgrund nicht ausreichender Planungstiefe]{Probleme aufgrund nicht ausreichender Planungstiefe}
 
@@ -173,7 +173,8 @@ $\Rightarrow$ Kann zum Scheitern der Systemeinführung führen oder ein Workarou
 
 
 \subsubsection{\textbf{E07} -- Nicht übereinstimmende Portvorgaben zwischen der
-Anwendungssoftware und dem Tool}\label{E07}
+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
@@ -181,7 +182,7 @@ 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.
+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
@@ -234,24 +235,22 @@ $\Rightarrow$ Dieses Vorgehen kann zu einer hohen Belastung der CPU führen, den
   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)
+Ein Beispiel dieser Problematik unter der Nutzung von Quarkus ist in einer meiner Projekte aufgetreten (\ref{be:jx}). \todo{check me}
 
-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
+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
+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
+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
@@ -292,24 +291,21 @@ unbeabsichtigt ausgeliefert.\cite{plonski_herausforderungen_Leo_2020,plonski_her
 
 ~
 
-$\Rightarrow$  xxxIm Falle von Konflkten geht code verlorenxx.
-  Nicht gewünschter Code befindet sich in Produktion
+$\Rightarrow$  Nicht gewünschter Code befindet sich in Produktion.
 
-\begin{quote}
-\url{https://code.i-harness.com/de/q/6d10a0}
-\end{quote}
+\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 GitObs (xx) Umfeld. In einem CI/CD Umfeld hat es
+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 Gitobs(xx):
+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
@@ -365,18 +361,15 @@ weiter.\ref{be:jx} \cite{shahin2017continuous}
 $\Rightarrow$  Ungetesteter Code befindet sich in Produktion
 
 
-\subsubsection{\textbf{B07} -- Modultest nur auf Codeabdeckung ausgelegt}\label{B07}
+\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
+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 den Smoktests mit einer positiven Statusmeldung, aber
+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}
 
 ~
@@ -388,9 +381,9 @@ $\Rightarrow$  Funktional ungetesteter Code befindet sich in Produktion
 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}
+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}
 
 ~