added mass

chapters/grund.tex

@@ -146,7 +146,7 @@ GitLab-CI}.
 ~
 
 \subsection*{Continuous Delivery / Continuous Deployment}
-
+\todo{Mehr zu CDE und CD schreiben}
 Die Abkürzung CD kann sowohl für Continuous Delivery als auch für
 Continuous Deployment stehen und bezeichnen die weitere Automatisierung
 in der Pipeline und stehen für das Ausmaß der Automatisierung.

chapters/mass.tex

@@ -0,0 +1,318 @@
+\chapter{Empfehlungen für die Planung und Implementierung von CI/CD}
+
+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
+Maßnahmen.
+
+\section{Planung eines CI/CD Systems}
+
+Die Einführung eines CI/CD 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
+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
+Teilprozesse und ihre Abfolge definiert, welche das CI/CD System
+abbilden soll.
+
+Typische Prozesse hierfür sind der
+
+\begin{description}
+    \item[Build-Prozess] 
+    Compile, ggf, Multimudulcompiling und Containerbau
+    \item[Testprozess]
+    Modul, Integrations- und Systemtest
+    \item[Analyseprozess] 
+    statisch oder dynamische Codeanalyse, Dependencyanalyse, Lizenzscan, Containersicherheitsanalyse
+    \item[Delivery oder Deployment]
+\end{description}
+
+Die detaillierte Definition der \textbf{Inputschnittstelle} für das
+CI/CD System (z.B. xxxx ) 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.
+
+Zu diesem Zeitpunkt ist es notwendig, die \textbf{Rahmenbedingungen} für
+das CI/CD -- 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.
+
+Für jeden \textbf{Prozessschritt} muss eine \textbf{detaillierte
+funktionale Anforderung} erfolgen, beispielsweise könnte für den
+Analyseprozess die Arten von Checks festgelegt werden, wie der Check auf
+bestimmte Designpatterns, Variablennamen, der Check gegen vorhandene
+Regellisten.\\
+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
+Softwareentwicklungsprozess vorliegendes Projekt eingeführt, muss eine
+\textbf{Migration} geplant werden. Hierbei müssen alle zu migrierende
+Artefakte zu den entsprechenden Prozessschritten bestimmt und
+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
+Festlegung der Zielumgebung für Artefakte (für Delivery) und im Falle
+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
+zugänglich ist.
+
+\subsection{Design des CI/CD Systems}\label{mas:m1.3}
+
+\subsubsection{Toolauswahl}\label{mas:m1.3.1}
+
+In diesem Planungsschritt gilt es, aus den Vorgaben über den Umfang,
+Inhalt und die Zielumgebung des Use Case die \textbf{Wahl der
+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,
+mit einer genauen Analyse über Funktionalität und Schnittstellen
+erstellt werden.
+
+Ein systematischer Abgleich der Anforderungen aus \ref{mas:m1.1} und \ref{mas:m1.2} gegen
+die Tooleigenschaften liefert eine potenzielle Toolauswahl, welche gegen
+die Detailanforderungen und Rahmenbedingungen überprüft wird.
+
+Dabei geht es um die Bestimmung der grundlegenden Realisierbarkeit und
+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
+Betrachtung.
+
+Für den Fall, dass Module zu einer individuellen Lösung konfiguriert
+werden, muss eine Integrationsanalyse durchgeführt werden.
+
+\subsubsection{Design im Toolkontext}\label{mas:m1.3.2}
+
+Nach der Toolentscheidung erfolgt die Detailplanung des Designs für die
+getroffene Toolauswahl.
+
+Hierzu gehört das Design der Toolintegration, die Migration, aber auch
+das Design von möglichen technischen Maßnahmen wie in 4./3xx
+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
+ist ebenfalls vom Use Case vorgegeben und bestimmt die Ausstattung der
+Hardware mit CPU und RAM.
+
+So hat eine pure Webanwendung mit einer CI Anfrage pro Stunde keine
+besondere Anforderung an die eine Hardware, während ein CI-System,
+welches 25 CI Anfragen in der Stunde erhält und für die Entwicklung von
+CPU-oder sogar GPU intensiven Anwendungen gedacht ist, eine viel
+stärkere Hardware mit höheren Taktraten und Kernen benötigt.
+
+Solche hardwareintensiven Anwendungen finden sich häufig unter Machine
+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
+aus dem Unternehmens- und Projektumfeld.
+
+\section{Dokumentation}\label{mas:m2}
+
+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
+das Integrations-(xxx oben definieren) und Automatisierungsteam(xxxoben
+definiern).
+
+Die Dokumentation stellt für den Entwickler Informationen bereit, welche
+ihm Kenntnisse zu den In- und Output-Schnittstellen vermittelt. Er muss
+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 den CI/CD Engine,
+(xxx bei der automatisierung -- vielleicht auch tools und ) eingesetzte
+Tools und deren Interfaces und über die Konfiguration des aktuellen
+Systems, um den Betrieb und die Wartung für das Automatisierungsteam zu
+ermöglichen.
+
+Bei Störungen im CI/CD System kann diese Dokumentation helfen, das
+System wiederherzustellen bzw. sogar extern als Workaround zu betreiben
+(durch Verfassung der einzelnen CI/CD Schritte in Einzelscripten).
+
+\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 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
+Policies genutzt werden.
+
+Beispielsweise kann durch technische Maßnahme verhindert werden, dass
+eine ungetestete Softwareversion in einer Produktionsumgebung ungewollt
+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} B06 -- unzureichende Tests -- ungetesteter Code in Produktion)}
+
+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.
+
+Die ungewollte Ausführung eines unorchestrierten Containers ist ein
+Problem, welches ebenfalls durch technische Maßnahmen vermieden werden
+kann.(einbisschen andeuten wieexxx)
+
+Auch im \textbf{Speichermanagement} gibt es Möglichkeiten, den \emph{in
+(\ref{B02} B02 - erschöpfte Speicherkapazität des CI/CD System)} beschriebenen
+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
+organisatorischen Maßnahme und kann für unterschiedliche Prozessschritte
+als Qualitätssicherungsmaßnahme vorgesehen werden. Die technische
+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.
+
+So können auch \textbf{Konflikte}, welche durch eine \textbf{parallele
+Ausführung} zweier Pipelines entstehen, mit Hilfe von technischen
+Vorkehrungen erkannt werden und zum Stopp der Pipeline führen. (andeuten
+wie xx)
+
+\subsection{Beispiel für die Umsetzung von Maßnahmen zur Vermeidung
+von B04 -- ungewolltes Aktivieren der Pipeline durch unbewusste Nutzung
+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
+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.
+
+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.
+
+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.}
+
+\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:
+
+Verhinderung der Push-Operation für Code auf den Masterbranch
+
+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
+hochzuladen. In diesem Augenblick erhält er jetzt eine Fehlermeldung
+aufgrund des Verbotes des Push-Kommandos. Desweitern verhindert der
+Prüfschritt für das Vieraugenprinzip, dass der Entwickler ein Release
+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
+von Push-Operationen auf gewissen Branches.
+
+Das Versionsmanagementsystem GitLab lässt sich so konfigurieren, dass
+man auf dem Masterbranch ein Push-Kommando 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
+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.
+
+\subsubsection{Dokumentation zur Erläuterung der Funktionalität für den
+Entwickler}
+
+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.
+
+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.

pandoc/mass.tex

@@ -0,0 +1,319 @@
+4. Empfehlungen für die Planung und Implementierung von CI/CD
+
+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
+Maßnahmen.
+
+4.1Planung eines CI/CD Systems
+
+Die Einführung eines CI/CD 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
+Anforderungen und dem Design beantwortet werden.
+
+4.1.1 Frage nach dem Umfang der Automatisierung und den Objekten der
+Automatisierung
+
+Entsprechend des individuell vorliegenden Entwicklungsprozess werden die
+Teilprozesse und ihre Abfolge definiert, welche das CI/CD System
+abbilden soll.
+
+Typische Prozesse hierfür sind der
+
+\textbf{Build-Prozess} (Compile, ggf, Multimudulcompiling und
+Containerbau),
+
+\textbf{Testprozess} (Modul, Integrations- und Systemtest),
+
+\textbf{Analyseprozess} (statisch oder dynamische Codeanalyse,
+Dependencyanalyse, Lizenzscan, Containersicherheitsanalyse)
+
+\textbf{Delivery} oder \textbf{Deployment}
+
+Die detaillierte Definition der \textbf{Inputschnittstelle} für das
+CI/CD System (z.B. xxxx ) 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.
+
+Zu diesem Zeitpunkt ist es notwendig, die \textbf{Rahmenbedingungen} für
+das CI/CD -- 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.
+
+Für jeden \textbf{Prozessschritt} muss eine \textbf{detaillierte
+funktionale Anforderung} erfolgen, beispielsweise könnte für den
+Analyseprozess die Arten von Checks festgelegt werden, wie der Check auf
+bestimmte Designpatterns, Variablennamen, der Check gegen vorhandene
+Regellisten.\\
+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
+Softwareentwicklungsprozess vorliegendes Projekt eingeführt, muss eine
+\textbf{Migration} geplant werden. Hierbei müssen alle zu migrierende
+Artefakte zu den entsprechenden Prozessschritten bestimmt und
+beschrieben werden.
+
+\textbf{4.1.2 Definition der Zielumgebung für Artefakte oder Software}
+
+Eine relevante Vorgabe in der Planung eines CI/CD-Systems ist die
+Festlegung der Zielumgebung für Artefakte (für Delivery) und im Falle
+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
+zugänglich ist.
+
+\textbf{4.1.3 Design des CI/CD Systems}
+
+4.1.3.1 Toolauswahl
+
+In diesem Planungsschritt gilt es, aus den Vorgaben über den Umfang,
+Inhalt und die Zielumgebung des Use Case die \textbf{Wahl der
+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,
+mit einer genauen Analyse über Funktionalität und Schnittstellen
+erstellt werden.
+
+Ein systematischer Abgleich der Anforderungen aus 4.1.1 und 4.1.2 gegen
+die Tooleigenschaften liefert eine potenzielle Toolauswahl, welche gegen
+die Detailanforderungen und Rahmenbedingungen überprüft wird.
+
+Dabei geht es um die Bestimmung der grundlegenden Realisierbarkeit und
+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
+Betrachtung.
+
+Für den Fall, dass Module zu einer individuellen Lösung konfiguriert
+werden, muss eine Integrationsanalyse durchgeführt werden.
+
+4.1.3.2 Design im Toolkontext
+
+Nach der Toolentscheidung erfolgt die Detailplanung des Designs für die
+getroffene Toolauswahl.
+
+Hierzu gehört das Design der Toolintegration, die Migration, aber auch
+das Design von möglichen technischen Maßnahmen wie in 4./3xx
+dargestellt.
+
+4.1.4 Festlegung der Hardware für das CI/CD System
+
+Die Art der Anfragen und die 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.
+
+So hat eine pure Webanwendung mit einer CI Anfrage pro Stunde keine
+besondere Anforderung an die eine Hardware, während ein CI-System,
+welches 25 CI Anfragen in der Stunde erhält und für die Entwicklung von
+CPU-oder sogar GPU intensiven Anwendungen gedacht ist, eine viel
+stärkere Hardware mit höheren Taktraten und Kernen benötigt.
+
+Solche hardwareintensiven Anwendungen finden sich häufig unter Machine
+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
+aus dem Unternehmens- und Projektumfeld.
+
+4.2 Dokumentation
+
+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
+das Integrations-(xxx oben definieren) und Automatisierungsteam(xxxoben
+definiern).
+
+Die Dokumentation stellt für den Entwickler Informationen bereit, welche
+ihm Kenntnisse zu den In- und Output-Schnittstellen vermittelt. Er muss
+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 den CI/CD Engine,
+(xxx bei der automatisierung -- vielleicht auch tools und ) eingesetzte
+Tools und deren Interfaces und über die Konfiguration des aktuellen
+Systems, um den Betrieb und die Wartung für das Automatisierungsteam zu
+ermöglichen.
+
+Bei Störungen im CI/CD System kann diese Dokumentation helfen, das
+System wiederherzustellen bzw. sogar extern als Workaround zu betreiben
+(durch Verfassung der einzelnen CI/CD Schritte in Einzelscripten).
+
+4.3 technische Maßnahmen
+
+4.3.1 Lösungsansätze zur Umsetzung der Maßnahmen
+
+Bei der Einführung eines CI/CD System können mit Hilfe von technischen
+Maßnahmen einige Probleme 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
+Policies genutzt werden.
+
+Beispielsweise kann durch technische Maßnahme verhindert werden, dass
+eine ungetestete Softwareversion in einer Produktionsumgebung ungewollt
+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{(B06 -- unzureichende Tests -- ungetesteter Code in Produktion)}
+
+Weitere Beispiele sind die Verhinderung einer ungewollten Ausführung
+eines Releases \emph{(B04 -- ungewolltes Aktivieren der Pipeline durch
+unbewusste Nutzung des Masterbranch),} deren Umsetzung im
+Anschlusskapitel an einer konkreten Systemumgebung aufgezeigt wird.
+
+Die ungewollte Ausführung eines unorchestrierten Containers ist ein
+Problem, welches ebenfalls durch technische Maßnahmen vermieden werden
+kann.(einbisschen andeuten wieexxx)
+
+Auch im \textbf{Speichermanagement} gibt es Möglichkeiten, den \emph{in
+(B02 - erschöpfte Speicherkapazität des CI/CD System)} beschriebenen
+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
+organisatorischen Maßnahme und kann für unterschiedliche Prozessschritte
+als Qualitätssicherungsmaßnahme vorgesehen werden. Die technische
+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.
+
+So können auch \textbf{Konflikte}, welche durch eine \textbf{parallele
+Ausführung} zweier Pipelines entstehen, mit Hilfe von technischen
+Vorkehrungen erkannt werden und zum Stopp der Pipeline führen. (andeuten
+wie xx)
+
+\textbf{4.3.2 Beispiel für die Umsetzung von Maßnahmen zur Vermeidung
+von B04 -- ungewolltes Aktivieren der Pipeline durch unbewusste Nutzung
+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
+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.
+
+Das Branchpattern besteht aus einem Master-, Develop- und Featurebranch.
+
+\textbf{4.3.2.1 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.
+
+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.}
+
+\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:
+
+Verhinderung der Push-Operation für Code auf den Masterbranch
+
+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
+hochzuladen. In diesem Augenblick erhält er jetzt eine Fehlermeldung
+aufgrund des Verbotes des Push-Kommandos. Desweitern verhindert der
+Prüfschritt für das Vieraugenprinzip, dass der Entwickler ein Release
+durch Merge ausführen kann.
+
+\textbf{4.3.2.1 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
+von Push-Operationen auf gewissen Branches.
+
+Das Versionsmanagementsystem GitLab lässt sich so konfigurieren, dass
+man auf dem Masterbranch ein Push-Kommando 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
+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.
+
+\textbf{4.3.2.1 Dokumentation zur Erläuterung der Funktionalität für den
+Entwickler}
+
+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.
+
+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.

thesis.tex

@@ -100,6 +100,7 @@
 \cleardoublepage
 \include{chapters/grund}
 \include{chapters/problems}
+\include{chapters/mass}
 \include{chapters/fazit}
 
 \cleardoublepage