spellcheck 2

chapters/mass.tex

@@ -3,13 +3,13 @@
 Auch wenn ein \cicd System nach der Einführung als Gesamtkomplex vorliegt, welcher schnell und einfach den Softwareentwicklungsprozess beschleunigt, ist es unumgänglich, sich bei der Einführung auf die Detailebene des Use Cases als auch der Tools zu begeben. Nur so besteht die Chance, später im Betrieb des Systems die Vorteile von CI/CD nutzen zu können.
 
 \todo{Aufschlüsseln der Rolle von Automatisierungs teams und Entwickler benzüglich Doku}
-Während das automatisierungs Team eine sehr viel umfangreichere Detailkenntnisse besitzen wird, muss der Softwareentwickler nur das für ihn relevanten Wissen in Form von Dokumentation vorliegen haben.
+Während das Automatisierungsteam sehr viel umfangreichere Detailkenntnisse besitzen wird, muss der Softwareentwickler nur das für ihn relevanten Wissen in Form von Dokumentation vorliegen haben.
 
 Im Folgenden werden Empfehlungen aufgezeigt, welche das Auftreten der
 oben geschilderten Probleme verhindern können.
 
-Die dargestellten Maßnahmen beziehen auf die Planung und Implementierung
-eines CI/CD Systems, die Dokumentation und auch konkrete technische
+Die dargestellten Maßnahmen beziehen sich auf die Planung und Implementierung
+eines CI/CD Systems, Dokumentation und auch konkrete technische
 Maßnahmen.
 
 \section{Planung eines CI/CD Systems}
@@ -24,24 +24,24 @@ Anforderungen und dem Design beantwortet werden.
 
 \subsection{Frage nach dem Umfang der Automatisierung und den Objekten der Automatisierung}\label{mas:m1.1}
 
-Entsprechend des individuell vorliegenden Entwicklungsprozess werden die
+Entsprechend des individuell vorliegenden Entwicklungsprozesses werden die
 Teilprozesse und ihre Abfolge definiert, welche das CI/CD System
 abbilden soll.
 
 Typische Prozesse hierfür sind der
 
 \begin{description}
-    \item[Build-Prozess] 
+    \item[Build-Prozess:] 
     Compile, ggf, Multimudulcompiling und Containerbau
-    \item[Testprozess]
+    \item[Testprozess:]
     Modul, Integrations- und Systemtest
-    \item[Analyseprozess] 
+    \item[Analyseprozess:] 
     statisch oder dynamische Codeanalyse, Dependencyanalyse, Lizenzscan, Containersicherheitsanalyse
     \item[Delivery oder Deployment]
 \end{description}
 
 Die detaillierte Definition der \textbf{Inputschnittstelle} für das
-\cicd System (z.B. Webhooks oder Dateiformate ) muss ebenfalls erstellt werden. Dazu gehört
+\cicd System (z.B. Webhooks oder Dateiformate) muss ebenfalls erstellt werden. Dazu gehört
 das Format, die Art, der Ort (Übergabeordner oder Repository) und der
 Kontext (z.B. Release-Erstellung oder Snapshot-Version) unter dem das
 CI/CD System aufgerufen wird.
@@ -65,8 +65,8 @@ Softwareartefakte in einem einfachen Dateisystem bereitgestellt werden
 oder in einem Artefakt-Managementsystem.
 
 Wird das CI/CD-System für ein bereits sich im
-Softwareentwicklungsprozess vorliegendes Projekt eingeführt, muss eine
-\textbf{Migration} geplant werden. Hierbei müssen alle zu migrierende
+Softwareentwicklungsprozess vorliegendes Projekt eingeführt, ist die Planung einer
+\textbf{Migration} notwendig. Hierbei müssen alle zu migrierende
 Artefakte zu den entsprechenden Prozessschritten bestimmt und
 beschrieben werden.
 
@@ -79,7 +79,7 @@ des Deployments die Zielumgebung für die Software.
 Die Laufzeitumgebung der produktiven Software variiert in Abhängigkeit
 des Use Case: Beispielsweise kann es sich um ein Autoradio, eine
 Cloudumgebung, eine App, eine Website, einen Großrechner oder einen
-Cluster handeln, welcher lokal vorliegt oder über das Internet
+Cluster handeln, welche lokal vorliegt oder ausschließlich über ein Netzwerk
 zugänglich ist.
 
 \subsection{Design des CI/CD Systems}\label{mas:m1.3}
@@ -92,7 +92,7 @@ Toolkonfiguration} und auch die Entscheidung zwischen
 \textbf{individueller Lösung} oder einer \textbf{All-in-One Lösung} zu
 treffen.
 
-Zunächst muss eine Toolübersicht über Einzel- als auch All-in-One Tools,
+Zunächst sollte eine Toolübersicht über Einzel- als auch All-in-One Tools,
 mit einer genauen Analyse über Funktionalität und Schnittstellen
 erstellt werden.
 
@@ -106,11 +106,11 @@ auch um den Änderungsaufwand im Falle von Konflikten.
 In die Entscheidung der Konfiguration fließen neben der funktionalen
 Betrachtung auch der Entwicklungsaufwand für Einführung und Migration,
 Lizenzkosten, Hardwarekosten und Training ein. Weitere betriebsbedingte
-Aufwände beispielsweise für das Integrationsteam gehören auch zu dieser
+Aufwände beispielsweise für das Automatisierungsteam gehören auch zu dieser
 Betrachtung.
 
-Für den Fall, dass Module zu einer individuellen Lösung konfiguriert
-werden, muss eine Integrationsanalyse durchgeführt werden.
+Für den Fall, dass Tools und Systeme zu einer individuellen Lösung konfiguriert
+werden, ist eine Integrationsanalyse notwendig.
 
 \subsubsection{Design im Toolkontext}\label{mas:m1.3.2}
 
@@ -123,7 +123,7 @@ dargestellt.
 
 \subsection{Festlegung der Hardware für das CI/CD System}\label{mas:m1.4}
 
-Die Art der Anfragen und die Häufigkeit der Anfragen an das CI/CD System
+Die Art und Häufigkeit der Anfragen an das CI/CD System
 ist ebenfalls vom Use Case vorgegeben und bestimmt die Ausstattung der
 Hardware mit CPU und RAM.
 
@@ -146,7 +146,7 @@ aus dem Unternehmens- und Projektumfeld.
 
 Ein CI/CD System wird zum zentralen Element des
 Softwareentwicklungsprozesses. Die starke Integration und Komplexität
-erfordert eine umfangreiche Dokumentation für Entwickler, als auch für
+erfordert eine umfangreiche Dokumentation für Entwickler als auch für
 das Automatisierungsteam.
 
 Die Dokumentation stellt für den Entwickler Informationen bereit, welche
@@ -155,12 +155,14 @@ für sein individuelles Projekt Information darüber haben, wie und welche
 Schritte durchlaufen werden und wie die Inputschnittstellen diesen
 Ablauf durch die Pipeline beeinflussen können.
 
+~
+
 Das Automatisierungsteam benötigt Informationen über sowohl die CI/CD Engine, eingesetzte
-Tools und deren Interfaces als auch die aktuelle Konfiguration der Systeme.
+Tools und deren Interfaces als auch über die aktuelle Konfiguration der Systeme.
 
 Bei Störungen im CI/CD System kann diese Dokumentation helfen, das
 System wiederherzustellen bzw. sogar extern als Workaround zu betreiben
-(durch verwenden Skripten zum Aufruf der einzelnen CI/CD Schritte).
+(durch den Einsatz von Skripten zum Aufruf der einzelnen CI/CD Schritte).
 
 ~
 
@@ -173,23 +175,29 @@ Die Dokumentation gehört zu einem Projekt, welches einen einfachen Java-Webserv
 \subsection{Lösungsansätze zur Umsetzung der Maßnahmen}\label{mas:m3.1}
 
 Bei der Einführung eines CI/CD System können mit Hilfe von technischen
-Maßnahmen einige Probleme vermieden werden, welche durch Unkenntnis der
+Maßnahmen einige Probleme\todo{Synonym} vermieden werden, welche durch Unkenntnis der
 Entwickler über die Funktionsweise des Systems verursacht werden.
 Zusätzlich können technische Maßnahmen auch für die Einhaltung von
 Richtlinien genutzt werden.
 
+~
+
+\setlength{\leftskip}{3em}
 Beispielsweise kann durch technische Maßnahme verhindert werden, dass
 eine ungetestete Softwareversion in einer Produktionsumgebung ungewollt
-verwIO-et wird: Mit Hilfe eines Artefakt-Archivierungssystems können
+verwendet wird: Mit Hilfe eines Artefakt-Archivierungssystems können
 passende Einstellungen vorgenommen werden, welche gewährleisten, dass
 nur getestete Softwareversionen in die Produktion übertragen werden.
 \emph{(\ref{B06} \nameref{B06})}
 
+~
+
 Weitere Beispiele sind die Verhinderung einer ungewollten Ausführung
 eines Releases \emph{(\ref{B04} B04 -- ungewolltes Aktivieren der Pipeline durch
 unbewusste Nutzung des Masterbranch),} deren Umsetzung im
 Anschlusskapitel an einer konkreten Systemumgebung aufgezeigt wird.
 
+~
 
 Auch im \textbf{Speichermanagement} gibt es Möglichkeiten, den \emph{in
 (\ref{B02} B02 - erschöpfte Speicherkapazität des CI/CD System)} beschriebenen
@@ -197,10 +205,14 @@ Speicherengpass zu verhindern: Durch ein \emph{geeignetes
 \textbf{Lifecycle-Management}} könnten gewisse Artefakte nach einiger
 Zeit gelöscht werden.
 
+~
+
 Weitere Maßnahmen könnten die Einführung einer \textbf{Hardwarequote} um
 für eine ungewollte Hardwarebeanspruchung für einzelne Nutzer
 vorzubeugen.
 
+~
+
 Das \textbf{vier-Augenprinzip} klingt zunächst nach einer \todo{rewrite}
 organisatorischen Maßnahme und kann für unterschiedliche Prozessschritte
 als Qualitätssicherungsmaßnahme vorgesehen werden. Die technische
@@ -208,6 +220,9 @@ Komponente dieser Maßnahme wäre die Dokumentation und
 Ausführungsbestätigung dieser Schritte, welche als Voraussetzung für die
 Fortsetzung des spezifischen Entwicklungsprozesses implementiert wird.
 
+\setlength{\leftskip}{0pt}
+
+~
 
 \subsection{Beispiel für die Umsetzung von Maßnahmen zur Vermeidung
 von B04 -- ungewolltes Aktivieren der Pipeline durch unbewusste Nutzung
@@ -215,10 +230,12 @@ des Masterbranch}
 
 Die in B04 dargestellte Problemstellung besteht nicht nur aus der
 versehentlichen Nutzung des Masterbranchs als Featurebranch. Die Brisanz
-entsteht durch die Folgen bei der Ausführung des Push-Kommando im CI/CD
+entsteht durch die Folgen bei der Ausführung der Push-Operation im CI/CD
 Umfeld. Der Build-Prozess wird gestartet und endet mit dem Deployment in
 der produktiven Umgebung.
 
+~
+
 Das Szenario wird mit Hilfe einer einfachen CI/CD Umgebung dargestellt.
 Sie besteht aus einer kleinen Pipeline, welche die Funktionen Build und
 Deploy abdeckt.
@@ -230,40 +247,48 @@ Das Branchpattern besteht aus einem Master-, Develop- und Featurebranch.
 Im Folgenden werden die Anforderungen definiert, welche mit Hilfe der
 CI/CD Tools oder des Versionsmanagementsystem umgesetzt werden müssen.
 
+~
+
 Die erste Überlegung wäre, gleich zu dem Zeitpunkt, an dem der
 Entwickler seine „versehentliche`` Programmiertätigkeit auf dem
 Masterbranch beginnt, eingreifen zu können. An dieser Stelle sind jedoch
 die Optionen in den weit verbreiteten Tools nicht gegeben und die
 Möglichkeiten zu intervenieren, können erst später ansetzen.
 
-\textbf{Ziel ist es, dass Softwareänderungen nur über das Merge-Kommando
-in den Masterbranch übertragen werden dürfen.}
+\begin{itemize}
+
+    \item \textbf{Ziel ist es, dass Softwareänderungen nur über die Merge-Operation
+    in den Masterbranch übertragen werden dürfen.}\todo{umformulieren}
+
+    \item \textbf{Ein Release darf nur ausgeführt werden, nach dem die
+    Softwareänderung von einer autorisierten Person über das
+    Vieraugenprinzip eine Überprüfung durchlaufen hat.}
+    
+\end{itemize}
+
+
 
-\textbf{Ein Release darf nur ausgeführt werden, nach dem die
-Softwareänderung von einer autorisierten Person über das
-Vieraugenprinzip eine Überprüfung durchlaufen hat.\\
-}
 
 Diese Richtlinien stellen somit die Grundlage, dass kein Code durch das
 unbewusste Arbeiten auf dem Masterbranch in Produktion gelangt.
 
 Hieraus ergeben sich die folgenden Einzelanforderungen für technische
 Maßnahmen:
+\begin{itemize}
+    \item Verhinderung der Push-Operation für Code auf den Masterbranch
+    \item Code muss über die Merge-Operation auf den Masterbranch übertragen werden
+    \item Bei der Merge-Operation auf dem Masterbranch muss der Vorgang einer
+    Code- und/oder Testüberprüfung durch eine weitere berechtigte Person
+    nach dem Vieraugenprinzip vor der Release-Ausführung bestätigt werden
 
-Verhinderung der Push-Operation für Code auf den Masterbranch
+\end{itemize}
 
-Code muss über die Merge-Operation auf den Masterbranch übertragen
-werden
-
-Bei der Merge-Operation auf dem Masterbranch muss der Vorgang einer
-Code- und/oder Testüberprüfung durch eine weitere berechtigte Person
-nach dem Vieraugenprinzip vor der Release-Ausführung bestätigt werden
 
 Im betrachteten Problemfall würde der Entwickler zunächst unbemerkt auf
 dem Masterbranch arbeiten. Er bestätigt seine Codeänderungen und würde
-versuchen, sie mit dem Push-Kommando auf das Remote-Git-Repository
+versuchen, sie mit der Push-Operation auf das Remote-Git-Repository
 hochzuladen. In diesem Augenblick erhält er jetzt eine Fehlermeldung
-aufgrund des Verbotes des Push-Kommandos. Desweitern verhindert der
+aufgrund des Verbotes der Push-Operation. Desweitern verhindert der
 Prüfschritt für das Vieraugenprinzip, dass der Entwickler ein Release
 durch Merge ausführen kann.
 
@@ -273,36 +298,54 @@ Es gibt eine Vielzahl von Versionsmanagementsystemen, welche in der Lage
 sind, gewisse Operationen regulieren können. Zum Beispiel das Verhindern
 von Push-Operationen auf gewissen Branches.
 
+~
+\setlength{\leftskip}{3em}
 Das Versionsmanagementsystem GitLab lässt sich so konfigurieren, dass
-man auf dem Masterbranch ein Push-Kommando nicht nutzen darf. Beim
+man auf dem Masterbranch die Push-Operation nicht nutzen darf. Beim
 Auslösen des Push kann eine Fehlermeldung angezeigt werden.
 
+~
+
 Entsprechend können im GitLab die Einstellungen getroffen werden, dass
 nur die Merge-Operation erlaubt ist.
 
-Ebenfalls ist es möglich, im GitLab bei einem Merge-Kommando einen
+~
+
+Ebenfalls ist es möglich, in GitLab bei einer Merge-Operation einen
 zusätzlichen Validierungsschritt zu implementieren, welcher nur von
 Usern mit einer speziellen Berechtigung bestätigt werden kann. Dieser
 Schritt stellt dann die Bestätigung der Vieraugenüberprüfung und
 Release-Freigabe durch die entsprechend autorisierte Person dar.
 
+~
+
 Sind diese Möglichkeiten der Regulierung von Operationen mit dem
 vorhandenen Versionshaltungstool nicht gegeben, gibt es noch die
 Möglichkeit über das CI-Tool einzugreifen:
 
+~
+
 Ein CI-Tool kann bei der Aktivierung nicht nachvollziehen, ob sich die
 Anfrage aus einem Push- oder Merge-Aufruf ergeben hat.
 
+~
+
 Aber es gibt die Möglichkeit der Überprüfung des letzten Commits aus dem
 Versionshaltungstool.
 
+~
+
 Die eine vorgegebene Berechtigung des Users kann überprüft werden,
 welche z.B. mit Hilfe von digitalen Signaturen umgesetzt werden könnte.
 
+~
+
 Diese Regel stellt sicher, dass die CI-Pipeline für ein Release
 gestartet wird, wenn der letzte Commit durch eine berechtigte Person
 durchgeführt wird.
 
+\setlength{\leftskip}{0pt}
+
 \subsubsection{Dokumentation zur Erläuterung der Funktionalität für den
 Entwickler}
 
@@ -317,6 +360,4 @@ Mit dieser Darstellung zur konkreten Umsetzung der Maßnahme zur
 Vermeidung der unbewussten Entwicklung auf dem Masterbranch wird dieses
 Kapitel abgeschlossen.
 
-Sobald man sich auf die Ebene von realem Use Case und Toolumgebung
-begibt entfalten sich die Möglichkeiten der technischen Maßnahmen und
-die Realisierung kann entsprechend in Abhängigkeit davon variieren.
+Das Bespiel verdeutlicht, wie umfangreich sich die Möglichkeiten der technischen Maßnahmen entfalten , sobald man die Ebene von realem UseCase und Toolumgebung verlässt.

chapters/problems.tex

@@ -411,8 +411,8 @@ Datenbankänderungen} \label{B08}
 
 Häufig geht mit Änderungen im Code auch eine Datenbankmigration einher.
 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}
+Treten während der Migration Probleme auf, so müssen diese ebenfalls durch das \cicd System abgefangen und entsprechende Maßnamen durchgeführt werden.
+Sind diese Fallbacks nicht definiert, entstehen unvorhergesehende Folgeprobleme. \cite{connolly,plonski_herausforderungen_Leo_2020,shahin2017continuous}
 
 ~