spellcheck teil 1

chapters/Einleitung.tex

@@ -26,10 +26,10 @@ bestehender Prozesse eingeführt. \cicd besitzt eine zentrale Rolle,
 welche auch den Entwicklungsprozess selbst verändert. Diese zentrale
 Rolle und Komplexität wird häufig unterschätzt. Schon während der
 Einführung oder später im Betrieb treten unerwartete Herausforderungen
-zu Tage, vom gravierenden Fehler in Produktion bis zum Systemstillstand.
+zu Tage, vom gravierenden Fehler im Produktionssystem bis hin zum Systemstillstand.
 
 \medskip
-Eine typische Herausforderungen, welche erst im Betrieb deutlich werden,
+Eine typische Herausforderung, welche erst im Betrieb deutlich wird,
 ist die unabsichtliche Auslieferung eines nicht produktionsbereiten
 Codes in den Betrieb.
 
@@ -51,12 +51,11 @@ herangezogen werden können.
 
 \medskip
 Diese Empfehlungen sind sehr allgemein formuliert, bedingt durch die
-große Vielseitigkeit in den Einsatzumgebungen als auch durch in der
+große Vielseitigkeit in den Einsatzumgebungen und in der
 Toollandschaft.
 
 \medskip
-Sie werden ergänzt durch Ansätze und Strategien, an denen man sich in
+Sie werden ergänzt durch Ansätze und Strategien, welche eine Orientierung für die Umsetzung liefern.
-der Umsetzung orientieren kann.
 
 \medskip
 Für das dargestellte Problem des ungewollten Deployment eines nicht
@@ -71,7 +70,7 @@ wissenschaftliche Arbeiten, Erfahrungsberichte sowie eigene
 Beobachtungen im \cicd Umfeld herangezogen.
 
 \medskip
-Aus der Problemanalyse wurden die Ursachen identifiziert und
+Aus der Problemanalyse wurden Ursachen identifiziert und
 entsprechende Empfehlungen abgeleitet.
 
 \section{Aufbau}

chapters/grund.tex

@@ -7,10 +7,7 @@ Im diesem Kapitel wird ausgehend von den Phasen des
 Softwareentwicklungsprozesses die Funktionsweise von \cicd aufgezeigt.
 
 Im Anschluss wird Git und die Rolle von Branches in diesem Umfeld
-erläutert. Diese Erklärungen dienen dem Verständnis im Kapitel der
+erläutert. Diese Erklärungen dienen dem Verständnis der im Kapitel \ref{heraus} geschilderten Problemdarstellungen.
-Problemdarstellungen.
-
-
 
 ~
 
@@ -49,7 +46,7 @@ Systemdesign, die Programmierung, der Test sowie der Betrieb.
     \item[Softwaretest]\label{phase-test}
     In der Testphase wird ein System oder eine Komponente gegen die zuvor
     spezifizierten Anforderungen überprüft. Das Testergebnis dient der
-    Behebung von Softwarefehlern um ein fehlerfreies System in Produktion zu
+    Behebung von Softwarefehlern, um ein fehlerfreies System in Produktion zu
     übernehmen.
 
     \item[Betrieb]\label{phase-ops}
@@ -74,14 +71,14 @@ Software schneller und in regelmäßigen Zyklen bereitgestellt.
 
 Werden diese Prinzipien \cil, \cdel und
 \cdl zusammenhängend ausgeführt, so wird das
-betreffende System als \textbf{CI-CD Pipeline}\label{ci-cd-pipeline} bezeichnet.
+betreffende System als \textit{\textbf{CI-CD Pipeline}}\label{ci-cd-pipeline} bezeichnet.
 
 ~
 
 In Theorie und Praxis gibt es eine Vielzahl von Definitionen zu \cicd.
 Es gibt Funktionalitäten, welche dem \cil zugeschrieben werden und an anderer
-Stelle in einer Darstellung von \cicd dem \cdel zu
+Stelle in einer Darstellung von \cicd dem \cdel zu geordnet sind.
-geordnet wird. Zusätzlich wird häufig bei der Nennung der Abkürzung \cd
+Zusätzlich wird häufig bei der Nennung der Abkürzung \cd
 nicht deutlich, ob \cdel oder \cdl gemeint ist.\cite{ws19,redhat,info_aktu}
 
 ~
@@ -93,7 +90,7 @@ werden, unabhängig von der Zuordnung zu einem Oberbegriff.
 ~
 
 \subsection{Continuous Integration}\label{ci}
-\textbf{„CI``} (\textbf{Continuous Integration}) bezeichnet eine entwicklerorientierte
+\textbf{„CI``} (\textit{\textbf{Continuous Integration}}) bezeichnet eine entwicklerorientierte
 Methode, bei der Code durchgängig integriert und getestet wird.
 
 ~
@@ -108,7 +105,7 @@ rechtzeitig zu erkennen.
 Sobald eine Änderung durch einen Entwickler durchgeführt wurde, wird die
 Integration gestartet und der entsprechende Code automatisch durch
 unterschiedliche Teststufen (Modul-, Integrations- und Systemtests)
-validiert. So wird sichergestellt, dass Fehler durch rechtzeitig erkannt
+validiert. So wird sichergestellt, dass Fehler rechtzeitig erkannt
 werden.
 
 ~
@@ -141,9 +138,8 @@ archiviert.
 
 ~
 
-Ein \cil durchlauf wird auch als \textbf{CI -- Run}
+Ein \cil Durchlauf wird auch als \textbf{CI -- Run} bezeichnet.
-bezeichnet.
+Ein Beispiel für solche \textit{Build-Server} sind \textit{Jenkins, „drone.io`` und
-Ein Beispiel für solche \textit{Build-Server} sind \textit{Jenkins, „drone.io``,
 GitLab-CI}.
 
 ~
@@ -162,7 +158,7 @@ findet nicht statt.
 
 \subsubsection*{Beispiel für eine cloudähnliche Container-Zielumgebung:} 
 In dieser Umgebung können die Container-Images nur von einem lokalen Image-Registry bezogen werden.
-Continuous Delivery spielt die Artefakte eines erfolgreichen Release-CI-Run automatisch in das lokale Image-Registry der Zielumgebung.
+\cdel spielt die Artefakte eines erfolgreichen Release-CI-Run automatisch in das lokale Image-Registry der Zielumgebung.
 Das Container-Image steht nun bereit, wurde jedoch noch nicht installiert.
 
  
@@ -175,17 +171,20 @@ nimmt.
 
 ~
 
-Für den Entwicklungsalltag bedeutet diesen Praktiken, dass kleinste
+Für den Entwicklungsalltag bedeuteten diesen Praktiken, dass kleinste
 Codeänderungen innerhalb von wenigen Minuten produktiv werden können.
 
 ~
 
-Das Risiko für Fehler im Betrieb ist geringer, da Änderungen in kleinen Schritten mit jedem CI/CD Run integriert, getestet werden.
+Das Risiko für Fehler im Betrieb ist geringer, da Änderungen in kleinen Schritten mit jedem \textit{CI -- Run} integriert und getestet werden.
 
 
 \section{Git und die Bedeutung von Branches}
 \label{grund:git}
-Die \scm Git besitzt im Zusammenhang mit CI/CD die Möglichkeit operativen Systeme versioniert zu steuern. Dies wird auch als \textbf{GitOps} bezeichnet und ist eine weit verbreitete CI/CD Methode.
+Die \scm Git besitzt im Zusammenhang mit CI/CD die Möglichkeit, operative Systeme versioniert zu steuern. Dies wird auch als \textbf{GitOps} bezeichnet und ist eine weit verbreitete CI/CD Methode\todo{quelle}.
+
+~
+
 Git basiert auf dem Konzept von Branches,
 welches verschiedene Codeversionen enthalten kann. Ein Branch ist ein
 Entwicklungszweig, auf dem die Änderungen innerhalb eines
@@ -201,10 +200,10 @@ und in den Betrieb gebracht.
 
 ~
 
-Ein weit verbreitetes Branchpattern besteht aus zwei permanente Branches
+Typisches Branchpattern besteht aus zwei permanenten Branches
 und mehreren temporären. Der Masterbranch repräsentiert die stabilste
-Softwareversion, diese Version lässt sich auch in der Produktion
+Softwareversion - diese Version lässt sich auch in der Produktion
-vorfinden, häufig gibt es noch den permanenten Developmentbranch, auf
+vorfinden - häufig gibt es noch den permanenten Developmentbranch, auf
 dem die Codeänderungen aus den temporären Branches zusammengeführt
 werden. Dieser Branch lässt sich in Testumgebungen (Staging-Umgebungen)
 finden.
@@ -217,7 +216,7 @@ dem Masterbranch gemergt.
 Daneben existieren temporäre Branches, welche für die Entwicklung neuer
 Funktionen oder Bugfixes vorgesehen sind. Sie werden nach dem Merge mit
 dem Developmentbranch gelöscht. Diese temporären Branches sind
-ausschließlich für eine abgegrenzte Codeänderung vorgesehen -- und so
+ausschließlich für eine abgegrenzte Codeänderung gedacht -- und so
 ist für sie eine schnelle und häufige Integration vorgesehen.
 
 ~
@@ -225,8 +224,8 @@ ist für sie eine schnelle und häufige Integration vorgesehen.
 Die wichtigsten Git – Operationen sind Push und Merge:
 
 \begin{description}
-  \item[Push] der lokale Branch wird auf den zentralen Branch gespiegelt
+  \item[Push:] der lokale Branch wird auf den zentralen Branch gespiegelt
-  \item[Merge] systematische Integration von zwei Branches von einem Source zu einem Targetbranch  
+  \item[Merge:] systematische Integration von zwei Branches von einem Source zu einem Targetbranch  
   
 \end{description}
 
@@ -265,8 +264,8 @@ da es im Branchpattern entsprechend definiert wurde.
 \begin{itemize}
 \item
   Es findet eine Überprüfung statt, ob die Integration mit dem
-  Developmentbranch funktionieren könnte und deckt mögliche
+  Developmentbranch funktionieren könnte und mögliche
-  Mergekonflikte auf
+  Mergekonflikte werden aufgedeckt
 \item
   Eine nur für den Entwickler vorgesehene Softwareversion in einer
   Testumgebung wird erstellt (bzw. für weiteres Testing)

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
+Hierzu die Darstellung des Falls an einem Beispiel unter \gitops (\ref{grund:git}):
-weiterentwickelt. Dieser Code wird später im Masterbranch
+
+~
+
+
+\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}
 

hdathesis-config.tex

@@ -19,7 +19,7 @@
 \newcommand{\myFaculty}{Fachbereich Informatik\xspace}
 \newcommand{\myUni}{Hochschule Darmstadt\xspace}
 \newcommand{\myLocation}{Darmstadt\xspace}
-\newcommand{\myTime}{28. November 2019\xspace}
+\newcommand{\myTime}{19. März 2020\xspace}
 \newcommand{\myVersion}{version 4.4\xspace}
 
 % ****************************************************************************************************

thesis.tex

@@ -98,6 +98,7 @@
 \todo{Readthru}
 \todo{Grafik}
 \todo{svc}
+\todo{cicd}
 \cleardoublepage
 \part{Seminararbeit}\label{pt:thesis}
 \include{chapters/Einleitung}