spellcheck 4 und cicd und scm

chapters/mass.tex

@@ -1,6 +1,6 @@
 \chapter{Empfehlungen für die Planung und Implementierung von CI/CD}
 \label{mas}
-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.
+Auch wenn ein \cicd System nach der Einführung als Gesamtkomplex vorliegt, 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 Automatisierungsteam sehr viel umfangreichere Detailkenntnisse besitzen wird, muss der Softwareentwickler nur das für ihn relevanten Wissen in Form von Dokumentation vorliegen haben.
@@ -9,23 +9,23 @@ Im Folgenden werden Empfehlungen aufgezeigt, welche das Auftreten der
 oben geschilderten Probleme verhindern können.
 
 Die dargestellten Maßnahmen beziehen sich auf die Planung und Implementierung
-eines CI/CD Systems, Dokumentation und auch konkrete technische
+eines \cicd Systems, Dokumentation und auch konkrete technische
 Maßnahmen.
 
 \section{Planung eines CI/CD Systems}
 \label{mas:m1}
 
-Die Einführung eines CI/CD Systems beinhaltet nicht nur eine einfache
+Die Einführung eines \cicd Systems beinhaltet nicht nur eine einfache
 Automatisierung bestehender Prozesse, es handelt sich um eine komplexe
 Automatisierung mit einem hohen Grad an Integration. Aus diesem Grund
 stellt die sorgfältige Planung des Systems die Basis für eine
-erfolgreiche Einführung von CI/CD. Hierbei müssen Fragen zu den
+erfolgreiche Einführung von \cicd. Hierbei müssen Fragen zu den
 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 Entwicklungsprozesses werden die
-Teilprozesse und ihre Abfolge definiert, welche das CI/CD System
+Teilprozesse und ihre Abfolge definiert, welche das \cicd System
 abbilden soll.
 
 Typische Prozesse hierfür sind der
@@ -44,10 +44,10 @@ Die detaillierte Definition der \textbf{Inputschnittstelle} für das
 \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.
+\cicd System aufgerufen wird.
 
 Zu diesem Zeitpunkt ist es notwendig, die \textbf{Rahmenbedingungen} für
-das CI/CD -- System festzulegen. Dazu gehören alle Arten von
+das \cicd -- System festzulegen. Dazu gehören alle Arten von
 unternehmens- oder projektspezifischen Konventionen und Richtlinien
 beispielsweise zu Security, Code oder Systemarchitektur. Auch die
 vorliegende Hardware könnte als Rahmenbedingung vorgegeben sein.
@@ -64,7 +64,7 @@ Für den Prozessschritt des Delivery gilt es zu entscheiden, ob die
 Softwareartefakte in einem einfachen Dateisystem bereitgestellt werden
 oder in einem Artefakt-Managementsystem.
 
-Wird das CI/CD-System für ein bereits sich im
+Wird das \cicd-System für ein bereits sich im
 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
@@ -72,7 +72,7 @@ beschrieben werden.
 
 \subsection{Definition der Zielumgebung für Artefakte oder Software}\label{mas:m1.2}
 
-Eine relevante Vorgabe in der Planung eines CI/CD-Systems ist die
+Eine relevante Vorgabe in der Planung eines \cicd-Systems ist die
 Festlegung der Zielumgebung für Artefakte (für Delivery) und im Falle
 des Deployments die Zielumgebung für die Software.
 
@@ -123,7 +123,7 @@ dargestellt.
 
 \subsection{Festlegung der Hardware für das CI/CD System}\label{mas:m1.4}
 
-Die Art und Häufigkeit der Anfragen an das CI/CD System
+Die Art und Häufigkeit der Anfragen an das \cicd System
 ist ebenfalls vom Use Case vorgegeben und bestimmt die Ausstattung der
 Hardware mit CPU und RAM.
 
@@ -139,12 +139,12 @@ Learning Anwendungen und auch bei Quarkus- Native-Compiles.
 Der Speicherbedarf muss ermittelt werden, entsprechend des
 Speicherkonzepts und passend zu den gewählten Tools. Auch die Vorgaben
 zur Spiegelung für die redundante Verwaltung der Datenserver können bei
-der Konfigurationsentscheidung eine Rolle spielen, so wie Konventionen
+der Konfigurationsentscheidung eine Rolle spielen, sowie Konventionen
 aus dem Unternehmens- und Projektumfeld.
 
 \section{Dokumentation}\label{mas:m2}
 
-Ein CI/CD System wird zum zentralen Element des
+Ein \cicd System wird zum zentralen Element des
 Softwareentwicklungsprozesses. Die starke Integration und Komplexität
 erfordert eine umfangreiche Dokumentation für Entwickler als auch für
 das Automatisierungsteam.
@@ -157,25 +157,25 @@ Ablauf durch die Pipeline beeinflussen können.
 
 ~
 
-Das Automatisierungsteam benötigt Informationen über sowohl die CI/CD Engine, eingesetzte
+Das Automatisierungsteam benötigt Informationen über sowohl die \cicd Engine, eingesetzte
 Tools und deren Interfaces als auch über die aktuelle Konfiguration der Systeme.
 
-Bei Störungen im CI/CD System kann diese Dokumentation helfen, das
+Bei Störungen im \cicd System kann diese Dokumentation helfen, das
 System wiederherzustellen bzw. sogar extern als Workaround zu betreiben
-(durch den Einsatz von Skripten zum Aufruf der einzelnen CI/CD Schritte).
+(durch den Einsatz von Skripten zum Aufruf der einzelnen \cicd Schritte).
 
 ~
 
-Im Anhang befindet sich das Bespiel einer Entwicklerdokumentation für die CI/CD Implementierung eines Softwareentwicklungsprojektes. 
-Die Dokumentation gehört zu einem Projekt, welches einen einfachen Java-Webservice durch CI/CD automatisch integriert und ausgeliefert.
+Im Anhang befindet sich das Bespiel einer Entwicklerdokumentation für die \cicd Implementierung eines Softwareentwicklungsprojektes. 
+Die Dokumentation gehört zu einem Projekt, welches einen einfachen Java-Webservice durch \cicd automatisch integriert und ausliefert.
 \todo{ref zu doku}
 
 \section{technische Maßnahmen}\label{mas:m3}
 
 \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\todo{Synonym} vermieden werden, welche durch Unkenntnis der
+Bei der Einführung eines \cicd System können mit Hilfe von technischen
+Maßnahmen einige Probleme\todo{Synonym} vermieden werden, welche durch fehlendes Know-How 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.
@@ -207,8 +207,8 @@ 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
+Weitere Maßnahmen könnten die Einführung einer \textbf{Hardwarequote} sein, um
+eine ungewollte Hardwarebeanspruchung für einzelne Nutzer
 vorzubeugen.
 
 ~
@@ -230,13 +230,13 @@ 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 der Push-Operation im CI/CD
+entsteht durch die Folgen bei der Ausführung der Push-Operation im \cicd
 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.
+Das Szenario wird mit Hilfe einer einfachen \cicd Umgebung dargestellt.
 Sie besteht aus einer kleinen Pipeline, welche die Funktionen Build und
 Deploy abdeckt.
 
@@ -245,7 +245,7 @@ Das Branchpattern besteht aus einem Master-, Develop- und Featurebranch.
 \subsubsection{Anforderungen für Branchmanagement/Deployment}
 
 Im Folgenden werden die Anforderungen definiert, welche mit Hilfe der
-CI/CD Tools oder des Versionsmanagementsystem umgesetzt werden müssen.
+\cicd Tools oder die \scm umgesetzt werden müssen.
 
 ~
 
@@ -269,7 +269,7 @@ Möglichkeiten zu intervenieren, können erst später ansetzen.
 
 
 
-Diese Richtlinien stellen somit die Grundlage, dass kein Code durch das
+Diese Anforderungen 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
@@ -294,13 +294,14 @@ durch Merge ausführen kann.
 
 \subsubsection{Umsetzung im Versionsmanagmenttool oder in den CI Tools}
 
-Es gibt eine Vielzahl von Versionsmanagementsystemen, welche in der Lage
-sind, gewisse Operationen regulieren können. Zum Beispiel das Verhindern
+Es gibt eine Vielzahl von \textit{Quellcodeverwaltungen}, welche in der Lage
+sind, gewisse Operationen zu regulieren. Zum Beispiel das Verhindern
 von Push-Operationen auf gewissen Branches.
 
 ~
+
 \setlength{\leftskip}{3em}
-Das Versionsmanagementsystem GitLab lässt sich so konfigurieren, dass
+\noindent Die \scm GitLab lässt sich so konfigurieren, dass
 man auf dem Masterbranch die Push-Operation nicht nutzen darf. Beim
 Auslösen des Push kann eine Fehlermeldung angezeigt werden.
 
@@ -319,22 +320,22 @@ Release-Freigabe durch die entsprechend autorisierte Person dar.
 
 ~
 
+\setlength{\leftskip}{0px}
+
 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
+\setlength{\leftskip}{3em}
+\noindent 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.
 
@@ -353,11 +354,12 @@ Auch in der Projektdokumentation sollte auf dieses Regelwerk hingewiesen
 werden. Neben der Darstellung der Branchpattern sollten die vorhandenen
 Branches mit den erlaubten Operationen aufgeführt sein.
 
-Eine Übersicht der möglichen Fehlermeldungen mit dem Verweis der
-umgesetzten technischen Maßnahmen ergänzt die Darstellung.
+Eine Übersicht der möglichen Fehlermeldungen mit dem Hinweis auf die
+umgesetzten technischen Maßnahmen ergänzt die Beschreibung.
 
 Mit dieser Darstellung zur konkreten Umsetzung der Maßnahme zur
 Vermeidung der unbewussten Entwicklung auf dem Masterbranch wird dieses
 Kapitel abgeschlossen.
 
-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.
+Das Bespiel verdeutlicht, wie umfangreich sich die Möglichkeiten der technischen Maßnahmen entfalten,
+sobald man die Ebene von realem Use Case und Toolumgebung betritt.