diff --git a/chapters/grund.tex b/chapters/grund.tex index aa72150..b62b3ed 100644 --- a/chapters/grund.tex +++ b/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. diff --git a/chapters/mass.tex b/chapters/mass.tex new file mode 100644 index 0000000..148b979 --- /dev/null +++ b/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. diff --git a/pandoc/mass.tex b/pandoc/mass.tex new file mode 100644 index 0000000..ab70a5a --- /dev/null +++ b/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. diff --git a/pandoc/maßnahmen.docx b/pandoc/maßnahmen.docx new file mode 100644 index 0000000..6339166 Binary files /dev/null and b/pandoc/maßnahmen.docx differ diff --git a/thesis.tex b/thesis.tex index a11f936..2e5366b 100644 --- a/thesis.tex +++ b/thesis.tex @@ -100,6 +100,7 @@ \cleardoublepage \include{chapters/grund} \include{chapters/problems} +\include{chapters/mass} \include{chapters/fazit} \cleardoublepage