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

spellcheck teil 1

Browse Source
This commit is contained in:
Manuel Plonski
2020-03-20 21:18:55 +01:00
parent 868b08e817
commit 35673cf42d
5 changed files with 70 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
chapters/Einleitung.tex
View File

@@ -26,10 +26,10 @@ bestehender Prozesse eingeführt. \cicd besitzt eine zentrale Rolle,
welche auch den Entwicklungsprozess selbst verändert. Diese zentrale
Rolle und Komplexität wird häufig unterschätzt. Schon während der
Einführung oder später im Betrieb treten unerwartete Herausforderungen
zu Tage, vom gravierenden Fehler in Produktion bis zum Systemstillstand.
zu Tage, vom gravierenden Fehler im Produktionssystem bis hin zum Systemstillstand.
\medskip
Eine typische Herausforderungen, welche erst im Betrieb deutlich werden,
Eine typische Herausforderung, welche erst im Betrieb deutlich wird,
ist die unabsichtliche Auslieferung eines nicht produktionsbereiten
Codes in den Betrieb.
@@ -51,12 +51,11 @@ herangezogen werden können.
\medskip
Diese Empfehlungen sind sehr allgemein formuliert, bedingt durch die
große Vielseitigkeit in den Einsatzumgebungen als auch durch in der
große Vielseitigkeit in den Einsatzumgebungen und in der
Toollandschaft.
\medskip
Sie werden ergänzt durch Ansätze und Strategien, an denen man sich in
der Umsetzung orientieren kann.
Sie werden ergänzt durch Ansätze und Strategien, welche eine Orientierung für die Umsetzung liefern.
\medskip
Für das dargestellte Problem des ungewollten Deployment eines nicht
@@ -71,7 +70,7 @@ wissenschaftliche Arbeiten, Erfahrungsberichte sowie eigene
Beobachtungen im \cicd Umfeld herangezogen.
\medskip
Aus der Problemanalyse wurden die Ursachen identifiziert und
Aus der Problemanalyse wurden Ursachen identifiziert und
entsprechende Empfehlungen abgeleitet.
\section{Aufbau}

49
chapters/grund.tex
View File

@@ -7,10 +7,7 @@ Im diesem Kapitel wird ausgehend von den Phasen des
Softwareentwicklungsprozesses die Funktionsweise von \cicd aufgezeigt.
Im Anschluss wird Git und die Rolle von Branches in diesem Umfeld
erläutert. Diese Erklärungen dienen dem Verständnis im Kapitel der
Problemdarstellungen.
erläutert. Diese Erklärungen dienen dem Verständnis der im Kapitel \ref{heraus} geschilderten Problemdarstellungen.
~
@@ -49,7 +46,7 @@ Systemdesign, die Programmierung, der Test sowie der Betrieb.
\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
Behebung von Softwarefehlern, um ein fehlerfreies System in Produktion zu
übernehmen.
\item[Betrieb]\label{phase-ops}
@@ -74,14 +71,14 @@ Software schneller und in regelmäßigen Zyklen bereitgestellt.
Werden diese Prinzipien \cil, \cdel und
\cdl zusammenhängend ausgeführt, so wird das
betreffende System als \textbf{CI-CD Pipeline}\label{ci-cd-pipeline} bezeichnet.
betreffende System als \textit{\textbf{CI-CD Pipeline}}\label{ci-cd-pipeline} bezeichnet.
~
In Theorie und Praxis gibt es eine Vielzahl von Definitionen zu \cicd.
Es gibt Funktionalitäten, welche dem \cil zugeschrieben werden und an anderer
Stelle in einer Darstellung von \cicd dem \cdel zu
geordnet wird. Zusätzlich wird häufig bei der Nennung der Abkürzung \cd
Stelle in einer Darstellung von \cicd dem \cdel zu geordnet sind.
Zusätzlich wird häufig bei der Nennung der Abkürzung \cd
nicht deutlich, ob \cdel oder \cdl gemeint ist.\cite{ws19,redhat,info_aktu}
~
@@ -93,7 +90,7 @@ werden, unabhängig von der Zuordnung zu einem Oberbegriff.
~
\subsection{Continuous Integration}\label{ci}
\textbf{„CI``} (\textbf{Continuous Integration}) bezeichnet eine entwicklerorientierte
\textbf{„CI``} (\textit{\textbf{Continuous Integration}}) bezeichnet eine entwicklerorientierte
Methode, bei der Code durchgängig integriert und getestet wird.
~
@@ -108,7 +105,7 @@ rechtzeitig zu erkennen.
Sobald eine Änderung durch einen Entwickler durchgeführt wurde, wird die
Integration gestartet und der entsprechende Code automatisch durch
unterschiedliche Teststufen (Modul-, Integrations- und Systemtests)
validiert. So wird sichergestellt, dass Fehler durch rechtzeitig erkannt
validiert. So wird sichergestellt, dass Fehler rechtzeitig erkannt
werden.
~
@@ -141,9 +138,8 @@ archiviert.
~
Ein \cil durchlauf wird auch als \textbf{CI -- Run}
bezeichnet.
Ein Beispiel für solche \textit{Build-Server} sind \textit{Jenkins, „drone.io``,
Ein \cil Durchlauf wird auch als \textbf{CI -- Run} bezeichnet.
Ein Beispiel für solche \textit{Build-Server} sind \textit{Jenkins, „drone.io`` und
GitLab-CI}.
~
@@ -162,7 +158,7 @@ findet nicht statt.
\subsubsection*{Beispiel für eine cloudähnliche Container-Zielumgebung:}
In dieser Umgebung können die Container-Images nur von einem lokalen Image-Registry bezogen werden.
Continuous Delivery spielt die Artefakte eines erfolgreichen Release-CI-Run automatisch in das lokale Image-Registry der Zielumgebung.
\cdel spielt die Artefakte eines erfolgreichen Release-CI-Run automatisch in das lokale Image-Registry der Zielumgebung.
Das Container-Image steht nun bereit, wurde jedoch noch nicht installiert.
@@ -175,17 +171,20 @@ nimmt.
~
Für den Entwicklungsalltag bedeutet diesen Praktiken, dass kleinste
Für den Entwicklungsalltag bedeuteten diesen Praktiken, dass kleinste
Codeänderungen innerhalb von wenigen Minuten produktiv werden können.
~
Das Risiko für Fehler im Betrieb ist geringer, da Änderungen in kleinen Schritten mit jedem CI/CD Run integriert, getestet werden.
Das Risiko für Fehler im Betrieb ist geringer, da Änderungen in kleinen Schritten mit jedem \textit{CI -- Run} integriert und getestet werden.
\section{Git und die Bedeutung von Branches}
\label{grund:git}
Die \scm Git besitzt im Zusammenhang mit CI/CD die Möglichkeit operativen Systeme versioniert zu steuern. Dies wird auch als \textbf{GitOps} bezeichnet und ist eine weit verbreitete CI/CD Methode.
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}.
~
Git basiert auf dem Konzept von Branches,
welches verschiedene Codeversionen enthalten kann. Ein Branch ist ein
Entwicklungszweig, auf dem die Änderungen innerhalb eines
@@ -201,10 +200,10 @@ und in den Betrieb gebracht.
~
Ein weit verbreitetes Branchpattern besteht aus zwei permanente Branches
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
Softwareversion - diese Version lässt sich auch in der Produktion
vorfinden - häufig gibt es noch den permanenten Developmentbranch, auf
dem die Codeänderungen aus den temporären Branches zusammengeführt
werden. Dieser Branch lässt sich in Testumgebungen (Staging-Umgebungen)
finden.
@@ -217,7 +216,7 @@ dem Masterbranch gemergt.
Daneben existieren temporäre Branches, welche für die Entwicklung neuer
Funktionen oder Bugfixes vorgesehen sind. Sie werden nach dem Merge mit
dem Developmentbranch gelöscht. Diese temporären Branches sind
ausschließlich für eine abgegrenzte Codeänderung vorgesehen -- und so
ausschließlich für eine abgegrenzte Codeänderung gedacht -- und so
ist für sie eine schnelle und häufige Integration vorgesehen.
~
@@ -225,8 +224,8 @@ ist für sie eine schnelle und häufige Integration vorgesehen.
Die wichtigsten Git – Operationen sind Push und Merge:
\begin{description}
\item[Push] der lokale Branch wird auf den zentralen Branch gespiegelt
\item[Merge] systematische Integration von zwei Branches von einem Source zu einem Targetbranch
\item[Push:] der lokale Branch wird auf den zentralen Branch gespiegelt
\item[Merge:] systematische Integration von zwei Branches von einem Source zu einem Targetbranch
\end{description}
@@ -265,8 +264,8 @@ da es im Branchpattern entsprechend definiert wurde.
\begin{itemize}
\item
Es findet eine Überprüfung statt, ob die Integration mit dem
Developmentbranch funktionieren könnte und deckt mögliche
Mergekonflikte auf
Developmentbranch funktionieren könnte und mögliche
Mergekonflikte werden aufgedeckt
\item
Eine nur für den Entwickler vorgesehene Softwareversion in einer
Testumgebung wird erstellt (bzw. für weiteres Testing)

57
chapters/problems.tex
View File

@@ -51,7 +51,7 @@ 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 CI/CD, vor allem wenn sie durch
die firmeninternen Compliance - Vorgaben zugelassen ist (All-in-One
Tool).
@@ -119,7 +119,7 @@ Problemen oder Verzögerungen führen können. \cite{plonski_herausforderungen_g
$\Rightarrow$ Je nach Tool erheblicher Migrationsaufwand
\subsubsection{\textbf{E04} - Fehlender Automatisierungsexperten/Integrationsexperte}\label{E04}
\subsubsection{\textbf{E04} - Fehlender Automatisierungsexperten}\label{E04}
Wird ein selfhosted CI/CD-System nicht durch einen
Automatisierungsexperten umgesetzt und betreut, stehen die CI Tools zwar
@@ -153,12 +153,12 @@ $\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 unternehmensspezifische
Es gibt eine Vielzahl von projekt- und unternehmensspezifischen
Richtlinien, unter denen CI/CD Systeme implementiert und betrieben
werden. Unkenntnis über deren Existenz oder Inhalt führen zu den
folgenden Herausforderungen bei einer Einführung.
\subsubsection{\textbf{E05} -- Sicherheitsrichtlinien widersprechen den Zugriffen durch das Tool\todo{anders formulieren}}\label{E05}
\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
@@ -196,7 +196,7 @@ 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
Signal nicht empfangen kann, würde das operative System die Anwendung
immer wieder neu starten, um eine Selbstreparatur zu ermöglichen. \ref{be:gitlab} \cite{plonski_herausforderungen_Leo_2020}
immer wieder neu starten, um eine Selbstreparatur zu ermöglichen. \cite{plonski_herausforderungen_Leo_2020} \ref{be:gitlab}
~
@@ -207,7 +207,7 @@ $\Rightarrow$ Pipeline zeigt ungewolltes Verhalten -- ist nicht funktionsfähig
Eine häufig anzutreffende Richtlinie im Kubernetik-Umfeld betrifft die
Vorgabe, in einem Cluster jede Anwendung im eigenen Namespace
bereitzustellen. Häufig aber lässt das CI/ CD Tool nur ein Deployment
auf einen fixen Namespace zu. \cite{be:gitlab,plonski_herausforderungen_Leo_2020}
auf einen fixen Namespace zu. \cite{plonski_herausforderungen_Leo_2020} \ref{be:gitlab}
~
@@ -236,7 +236,7 @@ CI/CD Systeme und Plattformen sind in ihrer Anwendung so ausgerichtet,
dass viele Projekte parallel CI/CD betreiben.
Durch den Ansatz, inkrementell kleinste Codeänderungen sofort zu
integrieren, wird bei jeder Codeänderung der Build-Prozess durchlaufen.\ref{be:jx}
integrieren, wird bei jeder Codeänderung der Build-Prozess durchlaufen. \ref{be:jx}
~
@@ -244,12 +244,12 @@ $\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.
Ein Beispiel dieser Problematik unter der Nutzung von Quarkus ist in einer meiner Projekte aufgetreten (\ref{be:jx}). \todo{check me}
Dieser Problematik wurde in meinem Praxisprojekt unter dem Einsatz von Quarkus beobachtet. (\ref{be:jx})
Quarkus ist ein neues für Webentwicklung geeignetes Java Framework (APIs
und Microservices) und verspricht ein „Native Compiling`` von Java Code.
Mit diesem Framework können also sehr performante APIs mit einem
Mit diesem Framework können sehr performante APIs mit einem
minimalen Bedarf an RAM erstellt werden.
Ein Build-Prozess unter Quarkus ist entsprechend aufwendig. Auf einem
@@ -279,9 +279,9 @@ an Artefakten abgelegt wird.
\subsubsection{\text{B03} - fehlende Möglichkeit zum kontrolliertem Stopp der
Pipeline}\label{B03}
Sobald eine gewisse Kette von Prozessen angestoßen ist, kann sie nicht
Sobald eine gewisse Kette von Prozessen in der Pipeline angestoßen wird, kann sie nicht
mehr unterbrochen werden und auf den konsistenten Zustand zuvor
zurückgesetzt werden.
zurückgesetzt werden.
~
@@ -302,39 +302,60 @@ unbeabsichtigt ausgeliefert. \cite{plonski_herausforderungen_Leo_2020,plonski_he
$\Rightarrow$ Nicht gewünschter Code befindet sich in Produktion.
\todo{QUELLE}
Dieses Problem wurde bereits in der Einleitung angerissen. Um hier eine
konkrete Lösungsmöglichkeit zu erarbeiten, erfolgt eine weitere Analyse
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
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.
Hierzu die Darstellung dieses Falls am einem Beispiel unter \gitops (\ref{grund:git}):
Mit Hilfe des Versionsmanagementsystem Git besteht die Möglichkeit, dass
jeder Entwickler in seinem eigenen „Featurebranch`` an seinem Code
weiterentwickelt. Dieser Code wird später im Masterbranch
~
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
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.
~
Wenn der Entwickler unbewusst anstelle eines persönlichen Featurebranch
den Masterbranch für diese Entwicklung nutzt, wird er im weiteren
Verlauf ein Push-Kommando nutzen (da er davon ausgeht, im Featurebranch
zu arbeiten), um seine Änderungen in einer separaten Testumgebung zu
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.
~
Dies führt zum Start der Releasepipeline. Die Codeänderung landet als
neues Softwarerelease im Produktionssystem und nicht, wie gewünscht, in
einer Testumgebung.
\setlength{\leftskip}{0pt}
~
In diesem Fall wäre die Notwendigkeit eines kontrollierten Stopps einer
Pipeline von Relevanz. Würde der Entwickler noch während der Ausführung
der Releasepipeline die Situation erkennen -- wäre dieser „Notstopp``
@@ -366,7 +387,7 @@ Manche Tools melden einen positiven Status und der CI/CD Prozess läuft weiter.
~
$\Rightarrow$ Ungetesteter Code befindet sich in Produktion
$\Rightarrow$ ungetesteter Code befindet sich in Produktion
\subsubsection{\textbf{B07} -- Modultest nur auf Codeabdeckung ausgelegt}
@@ -389,7 +410,7 @@ $\Rightarrow$ Funktional ungetesteter Code befindet sich in Produktion
Datenbankänderungen} \label{B08}
Häufig geht mit Änderungen im Code auch eine Datenbankmigration einher.
Diese Datenbankmigration muss ebenfalls durch \cicd automatisierte werden.
Diese Datenbankmigration muss ebenfalls durch \cicd automatisiert werden.
Treten während der Migration probleme auf, so müssen diese ebenfalls durch das \cicd System abgefangen werden und entsprechende Maßnamen durchgefürt werden.
Sind diese Fallbacks nicht definiert, so entstehen unvorhergesehende Folgeprobleme. \cite{connolly,plonski_herausforderungen_Leo_2020,shahin2017continuous}

2
hdathesis-config.tex
View File

@@ -19,7 +19,7 @@
\newcommand{\myFaculty}{Fachbereich Informatik\xspace}
\newcommand{\myUni}{Hochschule Darmstadt\xspace}
\newcommand{\myLocation}{Darmstadt\xspace}
\newcommand{\myTime}{28. November 2019\xspace}
\newcommand{\myTime}{19. März 2020\xspace}
\newcommand{\myVersion}{version 4.4\xspace}
% ****************************************************************************************************

1
thesis.tex
View File

@@ -98,6 +98,7 @@
\todo{Readthru}
\todo{Grafik}
\todo{svc}
\todo{cicd}
\cleardoublepage
\part{Seminararbeit}\label{pt:thesis}
\include{chapters/Einleitung}