spellcheck teil 1

chapters/problems.tex

@@ -51,7 +51,7 @@ 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
+Implementierung und Verfügbarkeit von CI/CD, vor allem wenn sie durch
 die firmeninternen Compliance - Vorgaben zugelassen ist (All-in-One
 Tool).
 
@@ -119,7 +119,7 @@ Problemen oder Verzögerungen führen können. \cite{plonski_herausforderungen_g
 
 $\Rightarrow$ Je nach Tool erheblicher Migrationsaufwand
 
-\subsubsection{\textbf{E04} - Fehlender Automatisierungsexperten/Integrationsexperte}\label{E04}
+\subsubsection{\textbf{E04} - Fehlender Automatisierungsexperten}\label{E04}
 
 Wird ein selfhosted CI/CD-System nicht durch einen
 Automatisierungsexperten umgesetzt und betreut, stehen die CI Tools zwar
@@ -153,12 +153,12 @@ $\Rightarrow$ Im individuellen CI/CD-System muss diese Aufgabe geplant werden,
 
 \subsection[im Umfeld von Richtlinien und Standards]{Probleme im Umfeld von Richtlinien und Standards}
 
-Es gibt eine Vielzahl von projekt- und unternehmensspezifische
+Es gibt eine Vielzahl von projekt- und unternehmensspezifischen
 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}
+\subsubsection{\textbf{E05} -- Konflikt zwischen Sicherheitsrichtlinien und Funktionsweise des Tools}\label{E05}
 
 Dazu gehören Sicherheitsrichtlinien im Unternehmen, beispielsweise
 könnte das Ausführen eines privilegierten Containers in einem CI/CD
@@ -196,7 +196,7 @@ 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}
+immer wieder neu starten, um eine Selbstreparatur zu ermöglichen. \cite{plonski_herausforderungen_Leo_2020} \ref{be:gitlab}
 
 ~
 
@@ -207,7 +207,7 @@ $\Rightarrow$ Pipeline zeigt ungewolltes Verhalten -- ist nicht funktionsfähig
 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}
+auf einen fixen Namespace zu. \cite{plonski_herausforderungen_Leo_2020} \ref{be:gitlab}
 
 ~
 
@@ -236,7 +236,7 @@ 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}
+integrieren, wird bei jeder Codeänderung der Build-Prozess durchlaufen. \ref{be:jx}
 
 ~
 
@@ -244,12 +244,12 @@ $\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 einer meiner Projekte aufgetreten (\ref{be:jx}). \todo{check me}
+Dieser Problematik wurde in meinem Praxisprojekt unter dem Einsatz von Quarkus beobachtet. (\ref{be:jx})
 
 
 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
+Mit diesem Framework können sehr performante APIs mit einem
 minimalen Bedarf an RAM erstellt werden.
 
 Ein Build-Prozess unter Quarkus ist entsprechend aufwendig. Auf einem
@@ -279,9 +279,9 @@ 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
+Sobald eine gewisse Kette von Prozessen in der Pipeline angestoßen wird, kann sie nicht
 mehr unterbrochen werden und auf den konsistenten Zustand zuvor
-zurückgesetzt werden.
+zurückgesetzt werden. 
 
 ~
 
@@ -302,39 +302,60 @@ unbeabsichtigt ausgeliefert. \cite{plonski_herausforderungen_Leo_2020,plonski_he
 
 $\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
+~
+
+Hierzu die Darstellung des Falls an einem Beispiel unter \gitops (\ref{grund:git}):
+
+~
+
+
+\setlength{\leftskip}{3em}
+
+\noindent Mit Hilfe des Versionsmanagementsystem Git besteht die Möglichkeit, dass
+jeder Entwickler im eigenen „Featurebranch`` an seinem Code
+entwickelt. 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.
 
+\setlength{\leftskip}{0pt}
+
+~
+
 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``
@@ -366,7 +387,7 @@ Manche Tools melden einen positiven Status und der CI/CD Prozess läuft weiter.
 
 ~
 
-$\Rightarrow$  Ungetesteter Code befindet sich in Produktion
+$\Rightarrow$  ungetesteter Code befindet sich in Produktion
 
 
 \subsubsection{\textbf{B07} -- Modultest nur auf Codeabdeckung ausgelegt}
@@ -389,7 +410,7 @@ $\Rightarrow$  Funktional ungetesteter Code befindet sich in Produktion
 Datenbankänderungen} \label{B08}
 
 Häufig geht mit Änderungen im Code auch eine Datenbankmigration einher.
-Diese Datenbankmigration muss ebenfalls durch \cicd automatisierte werden.
+Diese Datenbankmigration muss ebenfalls durch \cicd automatisiert 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}