welche

chapters/Automatisierung.tex

@@ -16,7 +16,7 @@ Die Projektphasen des Wasserfallmodells werden in Anforderungsanalyse, Systemdes
     In diese Phase geht es darum, Anforderungen zu sammeln und zu analysieren. Dies geschieht in Form von Texten oder Modellen, die der Strukturierung und Klassifizierung dienen.
 
     \item[Systemdesign]
-    Hier wird die Architektur der Module, Schnittstellen und Daten festgelegt, die der Spezifikation aus der Anforderungsanalyse genügen sollen.
+    Hier wird die Architektur der Module, Schnittstellen und Daten festgelegt, welche der Spezifikation aus der Anforderungsanalyse genügen sollen.
 
     \item[Implementierung] 
     Die Programmierung mit dem dazugehörige Modultest sind Bestandteil der Entwicklungsphase der Implementierung.
@@ -37,7 +37,7 @@ Es gibt verschiedene weit verbreitete Automatisierungspraktiken. Dazu gehören\c
     \item CD (\textit{Continuous Deployment})
 \end{itemize}
 Die Idee bei \textit{Continuous Integration} besteht darin, wiederholt (mehrmals täglich) die Software in einer kontrollierten definierten Umgebung automatisiert zu integrieren und zu testen (automated build). Die Tests können den Modul- Integration- und auch den Abnahmetest umfassen.
-Durch diese Verfahren können Fehler durch Codeänderungen automatisch erkannt werden, die sonst durch aufwendige, manuelle Testverfahren oder sogar erst im Betrieb erkannt worden wären.
+Durch diese Verfahren können Fehler durch Codeänderungen automatisch erkannt werden, welche sonst durch aufwendige, manuelle Testverfahren oder sogar erst im Betrieb erkannt worden wären.
 Je nach Umfang kann CI das ganze Volumen von Testszenarien abwickeln und so die Testphase voll automatisiert abdecken.\\
 
 \medskip

chapters/Einleitung.tex

@@ -76,11 +76,11 @@ entsprechende Empfehlungen abgeleitet.
 
 \section{Aufbau}
 \todo{Fix name Ref}
-Im Kapitel \nameref{automatisierung-im-softwareentwicklungsprozess} werden Grundlagen für die Phasen der Softwareentwicklung und deren Automatisierung unter CI/CD aufgezeigt, welche um eine Darstellung über das Branchkonzept unter Git ergänzt wird.
+Im Kapitel \ref{automatisierung-im-softwareentwicklungsprozess} werden Grundlagen für die Phasen der Softwareentwicklung und deren Automatisierung unter CI/CD aufgezeigt, welche um eine Darstellung über das Branchkonzept unter Git ergänzt wird.
 
-Diese Grundlagen dienen dem Verständnis der im Anschluss in Kapitel \nameref{heraus} dargestellten Ergebnisse der Erhebung und Analyse von Problemen bei der Einführung und im Betrieb von \cicd. Hierbei wird das in der Einleitung angerissene Problem vertieft und erläutert.
+Diese Grundlagen dienen dem Verständnis der im Anschluss in Kapitel \ref{heraus} dargestellten Ergebnisse der Erhebung und Analyse von Problemen bei der Einführung und im Betrieb von \cicd. Hierbei wird das in der Einleitung angerissene Problem vertieft und erläutert.
 
-Aus der Problemanalyse werden im Kapitel \nameref{mas} Lösungsansätze und Empfehlungen formuliert und auch eine konkrete Umsetzungsempfehlung für das Eingangsproblem entwickelt.
+Aus der Problemanalyse werden im Kapitel \ref{mas} Lösungsansätze und Empfehlungen formuliert und auch eine konkrete Umsetzungsempfehlung für das Eingangsproblem entwickelt.
 
 \section{Abgrenzung}
 

chapters/grund.tex

@@ -82,7 +82,7 @@ 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
 geordnet wird. Zusätzlich wird häufig bei der Nennung der Abkürzung \cd
-nicht deutlich, ob \cdel oder \cdl gemeint ist.
+nicht deutlich, ob \cdel oder \cdl gemeint ist.\cite{ws19,redhat,info_aktu}
 
 ~
 
@@ -91,6 +91,7 @@ automatisierten und überwachten Prozesses in einer Pipeline durchgeführt
 werden, unabhängig von der Zuordnung zu einem Oberbegriff.
 
 ~
+
 \subsection{Continuous Integration}\label{ci}
 \textbf{„CI``} (\textbf{Continuous Integration}) bezeichnet eine entwicklerorientierte
 Methode, bei der Code durchgängig integriert und getestet wird.
@@ -184,7 +185,7 @@ Das Risiko für Fehler im Betrieb ist geringer, da Änderungen in kleinen Schrit
 
 \section{Git und die Bedeutung von Branches}
 \label{grund:git}
-Die \scm Git besitzt im Zusammenhang mit CI/CD die Möglichkeit, die 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 operativen Systeme versioniert zu steuern. Dies wird auch als \textbf{GitOps} bezeichnet und ist eine weit verbreitete CI/CD Methode.
 Git basiert auf dem Konzept von Branches,
 welches verschiedene Codeversionen enthalten kann. Ein Branch ist ein
 Entwicklungszweig, auf dem die Änderungen innerhalb eines

chapters/problems.tex

@@ -6,6 +6,8 @@ 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,
@@ -14,18 +16,26 @@ Problembeschreibungen basieren auf Experteninterviews,
 Literaturrecherchen und Beobachtungen bei verschiedenen
 Praxisprojekten.
 
+~
+
 Die Interviews wurden mit Softwareentwicklern sowie
 Automatisierungs- und Integrationsexperten geführt. (CI/CD Systeme für
 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. \ref{be:gitlab} \ref{be:jx}
 
+~
+
 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
@@ -161,17 +171,16 @@ ein unautorisierter Zugriff auf das Produktionssystem erfolgen könnte.\cite{plo
 $\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}
+\subsubsection{\textbf{E06} -- Coding-Konvention}\label{E06}
 
-Unternehmens- oder Projekt-Codingrichtlinien können den Vorgaben des
-gewünschten Tools widersprechen. Ein Workaround ist notwendig.
+Unternehmens- oder Projekt Coding Conventions können den Vorgaben des
+gewünschten Tools widersprechen. Ein Workaround ist notwendig. \cite{plonski_herausforderungen_Leo_2020}
 
 ~
 
 $\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}
@@ -331,7 +340,7 @@ 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)
+(siehe \ref{B03} \nameref{B03})
 
 \subsubsection{\textbf{B05} -- unbewusste Einbindung von Software, welche durch
 Löschungsroutinen nicht permanent zur Verfügung steht} \label{B05}