manuel/Seminararbeit_2020
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

spellcheck 4 und cicd und scm

Browse Source
This commit is contained in:
Manuel Plonski
2020-03-21 10:06:36 +01:00
parent 0336f50e2b
commit 1ed037280b
7 changed files with 124 additions and 112 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
chapters/Einleitung.tex
View File

@@ -41,9 +41,9 @@ Funktionalität der Software oder sogar einen Systemausfall bewirken.
\medskip
\section{Ziel der Arbeit}
\textbf{Mit dieser Seminararbeit soll untersucht werden, inwieweit sich solche und weitere typische und häufige Komplikationen bei der Einführung und dem Betrieb von CI/CD verhindern lassen.}
\textbf{Mit dieser Seminararbeit soll untersucht werden, inwieweit sich solche und weitere typische und häufige Komplikationen bei der Einführung und dem Betrieb von \cicd verhindern lassen.}
\textbf{Sie stellt dar, wie das Auftreten eines ungewollten Deployments und weiterer Probleme sowohl in der Einführung als auch im Betrieb eines CI/CD Systems durch geeignete Planung und technische Maßnahmen verhindert werden können.}
\textbf{Sie stellt dar, wie das Auftreten eines ungewollten Deployments und weiterer Probleme sowohl in der Einführung als auch im Betrieb eines \cicd Systems durch geeignete Planung und technische Maßnahmen verhindert werden können.}
Anhand einer Problemrecherche und Analyse werden Empfehlungen
entwickelt, welche bei der Planung und Einführung eines Systems
@@ -75,7 +75,7 @@ entsprechende Empfehlungen abgeleitet.
\section{Aufbau}
\todo{Fix name Ref}
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.
Im Kapitel \ref{automatisierung-im-softwareentwicklungsprozess} werden Grundlagen für die Phasen der Softwareentwicklung und deren Automatisierung unter \cicd aufgezeigt, welche um eine Darstellung über das Branchkonzept unter Git ergänzt wird.
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.

22
chapters/experience.tex
View File

@@ -1,28 +1,36 @@
\chapter{Persönliche Beobachtungen aus der Praxis mit CI/CD}\label{beobachtung}
\section{CI/CD auf GitLab-CI basis für ein privates Projekt}\label{be:gitlab}
Migration von vorhandener Legacy-Software in die All-in-One Lösung von GitLab-CI.
\section{CI/CD auf Basis von GitLab-CI für ein privates Projekt}\label{be:gitlab}
Durchführung einer Migration von vorhandener Legacy-Software in die All-in-One Lösung von GitLab-CI.
~
Incident-Reporting Software basierend auf Java wurde:
Dabei wurde Incident-Reporting Software basierend auf Java:
\begin{itemize}
\item containerisiert
\item containerisiert.
\item durch die Migration auf CI/CD automatisiert gebaut und ausgeliefert.
\end{itemize}
%\Rightarrow% Probleme bei der Migration, aufgrund von Toolrequirments
\section{CI/CD auf Jenkins X}\label{be:jx}
~
Praxissemesterprojekt: Erforschung von Datafeedback in GitLab unter Jenkins X.
Aufbau einer serverlosen Jenkins X CI/CD Plattform zur Erforschung von Datafeedbackmöglichkeiten zu GitLab ohne GitLab CI
~
%\Rightarrow% Aufbau einer serverlosen Jenkins X CI/CD Plattform zur Erforschung von Datafeedbackmöglichkeiten zu GitLab ohne GitLab CI
~
%\Rightarrow% Betrieb und Erhalt einer selfhosted CI/CD Variante benötigt Detailplanung
\chapter*{Projekte, auf die sich die Experteninterviews beziehen}
\section[CI/CD bei PFS]{CI/CD in der Plattformsteuerung}\label{be:pfs}
Einführung von CI/CD zum automatisiertem Bau, Test und Istallation von Systemen als VM-Images.
Einführung von CI/CD zum automatisierten Bau, Test und Istallation von Systemen als VM-Images.
\section{CI/CD in ``Access 4.0''}\label{be:a4}
\section[CI/CD in Access 4.0]{CI/CD in ``Access 4.0''}\label{be:a4}
CI/CD Automatisierung von Microservices mit Kubernetes als Zielumgebung. Kubernetes Cluster läuft auf Bare--Metall-Switches und nicht auf virtuellen Maschinen.

22
chapters/grund.tex
View File

@@ -29,27 +29,27 @@ Systemdesign, die Programmierung, der Test sowie der Betrieb.
\begin{description}
\item[Anforderungsanalyse]\label{phase-anford}
\item[Anforderungsanalyse:]\label{phase-anford}
In diese Phase geht es darum, Anforderungen zu sammeln und zu
analysieren. Dies geschieht in Form von Texten oder Modellen, welche der
Strukturierung und Klassifizierung dienen.
\item[Systemdesign]\label{phase-sys}
\item[Systemdesign:]\label{phase-sys}
Hier wird die Architektur der Module, Schnittstellen und Daten
festgelegt, welche der Spezifikation aus der Anforderungsanalyse genügen
sollen.
\item[Implementierung]\label{phase-code}
\item[Implementierung:]\label{phase-code}
Die Programmierung mit dem dazugehörigen Modultest sind Bestandteil der
Entwicklungsphase der Implementierung
Entwicklungsphase der Implementierung.
\item[Softwaretest]\label{phase-test}
\item[Softwaretest:]\label{phase-test}
In der Testphase wird ein System oder eine Komponente gegen die zuvor
spezifizierten Anforderungen überprüft. Das Testergebnis dient der
Behebung von Softwarefehlern, um ein fehlerfreies System in Produktion zu
übernehmen.
\item[Betrieb]\label{phase-ops}
\item[Betrieb:]\label{phase-ops}
Der Betrieb um fasst die Inbetriebnahme und Wartung der Software.
\end{description}
@@ -83,7 +83,7 @@ nicht deutlich, ob \cdel oder \cdl gemeint ist.\cite{ws19,redhat,info_aktu}
~
Am Ende zähl nur, dass dies Funktionen entlang eines
Am Ende zählt nur, dass dies Funktionen entlang eines
automatisierten und überwachten Prozesses in einer Pipeline durchgeführt
werden, unabhängig von der Zuordnung zu einem Oberbegriff.
@@ -181,7 +181,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, operative Systeme versioniert zu steuern. Dies wird auch als \textbf{GitOps} bezeichnet und ist eine weit verbreitete CI/CD Methode\todo{quelle}.
Die \scm Git besitzt im Zusammenhang mit \cicd die Möglichkeit, operative Systeme versioniert zu steuern. Dies wird auch als \textbf{GitOps} bezeichnet und ist eine weit verbreitete \cicd Methode\todo{quelle}.
~
@@ -195,12 +195,12 @@ Projekt-Repository sequenziell fortgeschrieben werden.
Der Name des Branches ist dafür ausschlaggebend, welcher Pfad in der
Pipeline durchlaufen wird. Das Branch-Pattern beschreibt die Funktion,
welche dem Branch zukommt. Wird eine Änderung auf einem Branch,
wird sie auf die gewünschte Weise vom CI/CD System verwaltet, integriert
wird sie auf die gewünschte Weise vom \cicd System verwaltet, integriert
und in den Betrieb gebracht.
~
Typisches Branchpattern besteht aus zwei permanenten Branches
Ein typisches Branchpattern besteht aus zwei permanenten Branches
und mehreren temporären. Der Masterbranch repräsentiert die stabilste
Softwareversion - diese Version lässt sich auch in der Produktion
vorfinden - häufig gibt es noch den permanenten Developmentbranch, auf
@@ -257,7 +257,7 @@ neuer temporärer Featurebranch mit der Spiegelung der Änderungen vor.
\textbf{Build und Test in individueller Testumgebung}
\end{enumerate}
CI/CD wird von Git angestoßen: CI/CD erkennt die neue Software Version
\cicd wird von Git angestoßen: \cicd erkennt die neue Software Version
und startet einen Development-Build auf dem temporäreren Featurebranch,
da es im Branchpattern entsprechend definiert wurde.

72
chapters/mass.tex
View File

@@ -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.

105
chapters/problems.tex
View File

@@ -1,16 +1,16 @@
\chapter[Herausforderungen von CI/CD]{Herausforderungen bei der Einführung und im Betrieb von CI/CD}
\label{heraus}
Die Umsetzung und Einführung eines CI/CD System beinhaltet weit mehr als
Die Umsetzung und Einführung eines \cicd System beinhaltet weit mehr als
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
So läuft die Einführung und der Betrieb eines \cicd 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,
skizziert, welche zum Teil typisch und häufig im Umfeld von \cicd sind,
oder durch die starke Integration besonders zum Tragen kommen. Die
Problembeschreibungen basieren auf Experteninterviews,
Literaturrecherchen und Beobachtungen bei verschiedenen
@@ -19,20 +19,20 @@ Praxisprojekten.
~
Die Interviews wurden mit Softwareentwicklern sowie
Automatisierungs- und Integrationsexperten geführt. (CI/CD Systeme für
Automatisierungs- und Integrationsexperten geführt. (\cicd 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
Meine Praxiserfahrungen basieren auf der Einführung eines \cicd Systems
unter GitLab-CI sowie dem Aufbau einer Serverless - \cicd 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.
verschiedenen \cicd Systemen in ihrer Anwendung.
~
@@ -44,46 +44,46 @@ wird in der Darstellung nach Problemursache gruppiert.
\section[Herausforderungen während der Einführung]{Probleme während der Einführung eines CI/CD System}
In diesem Kapitel werden Probleme dargestellt, welche während der
Planungs- und Einführungsphasen von CI/CD in Erscheinung treten, dabei
Planungs- und Einführungsphasen von \cicd in Erscheinung treten, dabei
können sie zu Verzögerungen im Einführungsprozess fuhren oder sogar eine
Einführung verhindern.
Eine wesentliche Entscheidung in dieser Phase ist die Toolauswahl.
Die Nutzung einer All-in-One Lösung verspricht eine schnelle
Implementierung und Verfügbarkeit von CI/CD, vor allem wenn sie durch
Implementierung und Verfügbarkeit von \cicd, vor allem wenn sie durch
die firmeninternen Compliance - Vorgaben zugelassen ist (All-in-One
Tool).
Das individuelle CI/CD System wird auf die konkrete Projekt- und
Das individuelle \cicd System wird auf die konkrete Projekt- und
Systemumgebung (Quellcodeverwaltung, Tools zur Codeüberprüfung,
Dependency-Management) ausgelegt. Häufig finden sich in dieser Lösung
Tools, welche bereits im Einsatz sind und so für den Entwickler weniger
Umstellung bedeuten. Unterschiedliche Einzeltools bilden zusammen mit
dem automatisierten System (\textit{Build-Server}) das CI/CD System.
dem automatisierten System (\textit{Build-Server}) das \cicd System.
In diesem Zusammenhang wird der Use Case definiert als eine konkrete
Anwendung eines CI/CD Systems für ein Softwareentwicklungsprojekt mit
Anwendung eines \cicd Systems für ein Softwareentwicklungsprojekt mit
allen Anforderungen des Projektes. (siehe \ref{mas:m1} \nameref{mas:m1})
\subsection[aufgrund nicht ausreichender Planungstiefe]{Probleme aufgrund nicht ausreichender Planungstiefe}
Die im Anschluss dargestellten Herausforderungen bei einer Einführung
von CI/CD können entstehen, wenn bei der Planung Details über den Use
Case sowie die potentiellen Tools nicht tief analysiert werden.
von \cicd können entstehen, wenn bei der Planung Details über den Use
Case sowie die potenziellen Tools unzureichend analysiert werden.
\subsubsection[E01]{\textbf{E01} - Toolauswahl deckt nicht die Anforderungen des
Softwareentwicklungsprojekts}\label{E01}
Insbesondere bei der Wahl eines All-in-One Tool kann es passieren, dass
der Use Case nicht darstellbar ist. Beispielsweise könnte der Use Case
der Use Case nicht darstellbar ist. Beispielsweise kann der Use Case
einer Softwareentwicklung für ein Autoradio nicht mit einem All-in-One
Tool für Cloud- und Webanwendung umgesetzt werden. \cite{shahin2017continuous,plonski_herausforderungen_Leo_2020}
~
$\Rightarrow$ Das CI/CD System ist nicht funktionsfähig für diese Anwendung und die
$\Rightarrow$ Das \cicd System ist nicht funktionsfähig für diese Anwendung und die
Toolauswahl muss wiederholt werden
@@ -92,7 +92,7 @@ Toolauswahl muss wiederholt werden
Gerade bei einem All-in-One Tool ist die Einführung besonders
herausfordernd. Während bei einer individuellen Lösung häufig bereits
existierende, dem Nutzer bekannte Tools im CI/CD -- System implementiert
existierende, dem Nutzer bekannte Tools im \cicd -- System implementiert
werden, ist bei dem All-in-One Tool häufig mehr an Umstellung zu leisten
in Bezug auf Tool und Methode. \cite{plonski_herausforderungen_grund_2020,plonski_herausforderungen_Leo_2020}
@@ -104,7 +104,7 @@ $\Rightarrow$ Notwendigkeit von zusätzlichem Training für Methode und Tool
\subsubsection{\textbf{E03} - Migrationsaufwand}\label{E03}
Für ein bereits existierendes Projekt muss die Migration aus der alten
Umgebung in das neue CI/CD System vorgesehen werden.
Umgebung in das neue \cicd System vorgesehen werden.
Code-, Test- und Deploymentscripte sowie die Zielumgebung müssen
angepasst werden (Server, Software, Internetanbindung, Security).
@@ -119,24 +119,24 @@ Problemen oder Verzögerungen führen können. \cite{plonski_herausforderungen_g
$\Rightarrow$ Je nach Tool erheblicher Migrationsaufwand
\subsubsection{\textbf{E04} - Fehlender Automatisierungsexperten}\label{E04}
\subsubsection{\textbf{E04} - Fehlende Automatisierungsexperten}\label{E04}
Wird ein selfhosted CI/CD-System nicht durch einen
Wird ein selfhosted \cicd-System nicht durch einen
Automatisierungsexperten umgesetzt und betreut, stehen die CI Tools zwar
zur Automatisierung bereit, sind aber noch nicht integriert. Der
Entwickler muss die Integration der Tools für sein Projekt nach eigenem
Ermessen selbst vornehmen. Das führt zu einer Vielzahl unterschiedlicher
Setups eines CI/CD - Systems.
Setups eines \cicd - Systems.
Diese unterschiedlichen Setups gehen zu Lasten von Wartbarkeit,
Übersichtlichkeit und Fehleranfälligkeit.
Bei unsachgemäßer Nutzung eines CI/CD Systems können z.B.
Integrationsfehler erst im Deployment zu Tage treten, ob wohl die Tests
Bei unsachgemäßer Nutzung eines \cicd Systems können z.B.
Integrationsfehler erst im Deployment zu Tage treten, obwohl die Tests
erfolgreich durchlaufen wurden.
Die Wartung des CI/CD Systems ist auch Aufgabe des
Automatisierungsexperten. Ein CI/CD System benötigt kontinuierliche
Die Wartung des \cicd Systems ist auch Aufgabe des
Automatisierungsexperten. Ein \cicd System benötigt kontinuierliche
Wartung im laufenden Betrieb. Dazu gehört die Überwachung und Anpassung
von Systemstatus, Automatisierung, Speicherverbrauch, Zertifikaten,
Konfiguration und Architektur.
@@ -146,7 +146,7 @@ Die Server müssen angepasst, aufgestockt, beschleunigt und die Balance
~
$\Rightarrow$ Im individuellen CI/CD-System muss diese Aufgabe geplant werden,
$\Rightarrow$ Im individuellen \cicd-System muss diese Aufgabe geplant werden,
während bei der All-in-One Lösung der Provider diese Aufgabe wahrnimmt
@@ -154,16 +154,16 @@ $\Rightarrow$ Im individuellen CI/CD-System muss diese Aufgabe geplant werden,
\subsection[im Umfeld von Richtlinien und Standards]{Probleme im Umfeld von Richtlinien und Standards}
Es gibt eine Vielzahl von projekt- und unternehmensspezifischen
Richtlinien, unter denen CI/CD Systeme implementiert und betrieben
Richtlinien, unter denen \cicd Systeme implementiert und betrieben
werden. Unkenntnis über deren Existenz oder Inhalt führen zu den
folgenden Herausforderungen bei einer Einführung.
\subsubsection{\textbf{E05} -- Konflikt zwischen Sicherheitsrichtlinien und Funktionsweise des Tools}\label{E05}
Dazu gehören Sicherheitsrichtlinien im Unternehmen, beispielsweise
könnte das Ausführen eines privilegierten Containers in einem CI/CD
System nicht zugelassen sein, wenn die CI/CD Systeme Zugriffe auf
Produktivsysteme besitzen und so durch ein modifiziertes CI/CD Script
könnte das Ausführen eines privilegierten Containers in einem \cicd
System nicht zugelassen sein, wenn die \cicd Systeme Zugriffe auf
Produktivsysteme besitzen und so durch ein modifiziertes \cicd Script
ein unautorisierter Zugriff auf das Produktionssystem erfolgen könnte. \cite{plonski_herausforderungen_Leo_2020,plonski_herausforderungen_grund_2020} \ref{be:jx}
~
@@ -173,8 +173,8 @@ $\Rightarrow$ Kann zum Scheitern der Systemeinführung führen oder ein Workarou
\subsubsection{\textbf{E06} -- Coding-Konvention}\label{E06}
Unternehmens- oder Projekt Coding Conventions können den Vorgaben des
gewünschten Tools widersprechen. Ein Workaround ist notwendig. \cite{plonski_herausforderungen_Leo_2020}
Unternehmens- oder Projekt Coding Konventionen können den Vorgaben des
gewünschten Tools widersprechen. \cite{plonski_herausforderungen_Leo_2020}
~
@@ -186,12 +186,12 @@ Anwendungssoftware und dem Tool}
\label{E07}
Der Portmissmatch ist ein typisches Problem bei All-in-One Lösungen. Das
CI/CD System geht davon aus, dass die Software ihren Service über einen
\cicd System geht davon aus, dass die Software ihren Service über einen
spezifischen Port zu Verfügung stellen kann (z.B. Port 3000). Die zu
migrierende Software nutzt einen anderen Port oder vielleicht überhaupt
keinen Port, wenn sie z.B. einen Message-Bus anwendet.
Darüber hinaus könnte das CI/CD System das operative Zielsystem, z.B.
Darüber hinaus könnte das \cicd System das operative Zielsystem, z.B.
Kubernetes so konfigurieren, dass es auf einen Lifeness Check(
Lebenszeichen über den Bereitschaftsstatus der Software) genau über
diesen Port erhält. Solange die Software nicht angepasst ist und dieses
@@ -216,8 +216,8 @@ $\Rightarrow$ Ein Workaround ist notwendig
\section[Herausforderungen im Betrieb]{Probleme, welche im Betrieb eines CI/CD Systems entstehen können.}
Viele Herausforderungen in einer Umstellung auf CI/CD werden erst nach
der Einführung einer CI/CD Pipeline sichtbar und Probleme entstehen aus
Viele Herausforderungen in einer Umstellung auf \cicd werden erst nach
der Einführung einer \cicd Pipeline sichtbar und Probleme entstehen aus
Unkenntnis über spezifische Anforderungen des Tools - der gewünschte
Prozessdurchlauf funktioniert nicht und es müssen Workarounds gefunden
werden - die Betriebskosten des Tools erhöhen sich.
@@ -227,13 +227,13 @@ werden - die Betriebskosten des Tools erhöhen sich.
Eine wesentliche Änderung ist die Umstellung auf eine
Softwareentwicklung durch kleine inkrementelle Änderungen, welche
kontinuierlich implementiert und integriert werden. Daraus ergeben sich
besondere Anforderungen an die Hardware, auf der ein CI/CD System
besondere Anforderungen an die Hardware, auf der ein \cicd System
installiert wird.
\subsubsection{\textbf{B01} extreme Laufzeiten im Build-Prozess}\label{B01}
CI/CD Systeme und Plattformen sind in ihrer Anwendung so ausgerichtet,
dass viele Projekte parallel CI/CD betreiben.
\cicd Systeme und Plattformen sind in ihrer Anwendung so ausgerichtet,
dass viele Projekte parallel \cicd betreiben.
Durch den Ansatz, inkrementell kleinste Codeänderungen sofort zu
integrieren, wird bei jeder Codeänderung der Build-Prozess durchlaufen. \ref{be:jx}
@@ -244,6 +244,8 @@ $\Rightarrow$ Dieses Vorgehen kann zu einer hohen Belastung der CPU führen, den
Parallelbetrieb mit anderen Projekten kann es zu enormen Laufzeiten
beim Build-Prozess kommen.
~
Dieser Problematik wurde in meinem Praxisprojekt unter dem Einsatz von Quarkus beobachtet. (\ref{be:jx})
@@ -254,7 +256,7 @@ minimalen Bedarf an RAM erstellt werden.
Ein Build-Prozess unter Quarkus ist entsprechend aufwendig. Auf einem
Entwicklungs-PC lasst sich ein Build-Prozess in etwa 5 bis 10 Minuten
abbilden, während er auf einem CI/CD System mit einer etwas älteren
abbilden, während er auf einem \cicd System mit einer etwas älteren
Hardware bis zu eineinhalb Stunden dauern kann.
\subsubsection{\textbf{B02} erschöpfte Speicherkapazität des CI/CD System}\label{B02}
@@ -270,8 +272,9 @@ Software selbst und ihr Containerimage.\cite{plonski_herausforderungen_Leo_2020}
$\Rightarrow$ Manuelles Eingreifen in die Speicherung der Artefakte wird notwendig
und ist zudem fehleranfällig.
~
Über ein CI/CD System der Telekom wurden entsprechende Probleme
Über ein \cicd System der Telekom wurden entsprechende Probleme
geschildert: Es entstehen sehr schnell sehr viele Daten und die
Speichermedien laufen voll, da kontinuierlich bei jeder Änderung alles
an Artefakten abgelegt wird.
@@ -294,7 +297,7 @@ $\Rightarrow$ Lange Wartezeiten für eine nicht mehr benötigte Pipelineausfüh
Nutzung des Masterbranch} \label{B04}
Wird versehentlich direkt auf dem Masterbranch gearbeitet und diese
Änderung im Source Code Managementsystem freigegeben, kann es zur
Änderung in der \scm freigegeben, kann es zur
Ausführung der Release-Pipeline kommen und die Softwareversion wird
unbeabsichtigt ausgeliefert. \cite{plonski_herausforderungen_Leo_2020,plonski_herausforderungen_grund_2020,shahin2017continuous} \ref{be:jx}
@@ -302,7 +305,7 @@ unbeabsichtigt ausgeliefert. \cite{plonski_herausforderungen_Leo_2020,plonski_he
$\Rightarrow$ Nicht gewünschter Code befindet sich in Produktion.
~
Dieses Problem wurde bereits in der Einleitung angerissen. Um hier eine
konkrete Lösungsmöglichkeit zu erarbeiten, erfolgt eine weitere Analyse
@@ -311,7 +314,7 @@ innerhalb einer konkreten Systemumgebung.
~
Das versehentliche Arbeiten auf dem Masterbranch ist zunächst ein
typisches Problem im Git und GitOps (\ref{grund:git}) Umfeld. In einem CI/CD Umfeld hat es
typisches Problem im Git und GitOps (\ref{grund:git}) Umfeld. In einem \cicd Umfeld hat es
noch viel weitreichendere Folgen, denn durch die durchgängige
Automatisierung besteht das Problem nicht nur aus der ungewollten
Branchüberschreibung -- es weitet sich bis in die Produktion aus.
@@ -325,7 +328,7 @@ Hierzu die Darstellung des Falls an einem Beispiel unter \gitops (\ref{grund:git
\setlength{\leftskip}{3em}
\noindent Mit Hilfe des Versionsmanagementsystem Git besteht die Möglichkeit, dass
\noindent Mit Hilfe der \scm Git besteht die Möglichkeit, dass
jeder Entwickler im eigenen „Featurebranch`` an seinem Code
entwickelt. Dieser Code wird später im Masterbranch
zusammengeführt, um die Codeänderung dem Programm zuzuführen.
@@ -344,12 +347,12 @@ validieren.
In diesem Fall wird die Push-Operation jedoch nicht auf dem
Featurebranch, sondern auf dem Masterbranch ausgeführt. Anstelle eine
temporäre Testversion zu erhalten, bewirkt der Push auf dem Masterbranch
die Ausführung von CI/CD für ein Release.
die Ausführung von \cicd für ein Release.
~
Dies führt zum Start der Releasepipeline. Die Codeänderung landet als
neues Softwarerelease im Produktionssystem und nicht, wie gewünscht, in
Dies führt zum Start der Releasepipeline. Die Codeänderung wird als
neues Softwarerelease im Produktionssystem ausgerollt und nicht, wie gewünscht, in
einer Testumgebung.
\setlength{\leftskip}{0pt}
@@ -383,7 +386,7 @@ Die statische Codeanalyse erwartet den Source Code in einem spezifischen
Ordner. Unkenntnis über diese Vorgabe kann dazu führen, dass der Source
Code in einem anderen Verzeichnis bereitgestellt wird und das
Analysetool findet im spezifizierten Verzeichnis keinen Code.
Manche Tools melden einen positiven Status und der CI/CD Prozess läuft weiter. \ref{be:jx} \cite{shahin2017continuous}
Manche Tools melden einen positiven Status und der \cicd Prozess läuft weiter. \ref{be:jx} \cite{shahin2017continuous}
~
@@ -398,8 +401,8 @@ formuliert, kann es zwar sein, dass sie so verfasst sind, dass jede
Zeile des Codes durchlaufen wird, sie dennoch nichts darüber aussagen,
wie funktionsfähig das Modul oder Gesamtsystem ist.
Der Code passiert die Tests mit einer positiven Statusmeldung, aber
die Funktion des Moduls /Gesamtsystem ist nicht gewährleistet. \cite{connolly,shahin2017continuous} \ref{be:jx}
Der Code passiert die Tests mit einer positiven Statusmeldung, jedoch ist
die Funktion des Moduls/Gesamtsystems nicht gewährleistet. \cite{connolly,shahin2017continuous} \ref{be:jx}
~

2
pandoc/einleitung.tex
View File

@@ -27,7 +27,7 @@ Eine dieser Herausforderungen, welche erst im Betrieb deutlich werden,
ist die unabsichtliche Auslieferung eines nicht produktionsbereiten
Codes in den Betrieb.
Eine falsche Handhabung im Sourcecodemanagementtool kann in einem CI/CD
Eine falsche Handhabung in der \scm kann in einem CI/CD
Umfeld zu diesem ungewollten Deployment führen und so eine fehlerhafte
Funktionalität der Software oder sogar einen Systemausfall bewirken.

7
thesis.tex
View File

@@ -94,12 +94,11 @@
% Alwas use \cleardoublepage before \part{...}.
\todo{Einfügen Doku}
\todo{Tabelle}
\todo{Quelle backwords}
\todo{Readthru}
\todo{Grafik}
\todo{märz}
\todo{svc}
\todo{cicd}
\todo{märtz}
\todo{Grafik}
\cleardoublepage
\part{Seminararbeit}\label{pt:thesis}
\include{chapters/Einleitung}