gundlagen

chapters/Einleitung.tex

@@ -17,14 +17,14 @@ Softwareentwicklungsprozess zu beschleunigen \cite{article:google}.
 \section{Motivation}
 
 Auf den ersten Blick erscheinen die Konzepte einfach und schnell
-umsetzbar zu sein und die Umstellung auf CI/CD wird schnell gestartet,
+umsetzbar zu sein und die Umstellung auf \cicd wird schnell gestartet,
 um die Vorteile zu nutzen.
 
 \medskip
-Mit CI/CD wird jedoch nicht nur eine einfache Automatisierung
-bestehender Prozesse eingeführt. CI/CD besitzt eine zentrale Rolle,
+Mit \cicd wird jedoch nicht nur eine einfache Automatisierung
+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, und schon während der
+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.
 
@@ -34,7 +34,7 @@ ist die unabsichtliche Auslieferung eines nicht produktionsbereiten
 Codes in den Betrieb.
 
 \medskip
-Eine falsche Handhabung in der Versionsverwaltung kann in einem CI/CD
+Eine falsche Handhabung in der \scm kann in einem \cicd 
 Umfeld zu diesem ungewollten Deployment führen und so eine fehlerhafte
 Funktionalität der Software oder sogar einen Systemausfall bewirken.
 
@@ -44,7 +44,7 @@ Funktionalität der Software oder sogar einen Systemausfall bewirken.
 \textbf{
   \noindent 
   Das Auftreten eines ungewollten Deployments und weiterer häufig
-  anzutreffender Probleme innerhalb eines CI/CD - Systems kann bereits bei
+  anzutreffender Probleme innerhalb eines \cicd - Systems kann bereits bei
   der Einführung durch geeignete Planung und technische Maßnahmen
   verhindert werden.
 }
@@ -67,27 +67,26 @@ Für das dargestellte Problem des ungewollten Deployment eines nicht
 produktionsreifen Codes wird für eine konkrete Einsatzumgebung und
 Toolsituation aufgezeigt, wie sich das Problem durch entsprechende
 Planung und technische Maßnahmen verhindern lässt.
-\newpage
 
-
-\section{Vorgehen}
-Zur Erhebung relevanter Probleme wurden Experteninterviews geführt,
+\medskip
+\section{Methode}
+Zur Erhebung relevanter Probleme wurden Experteninterviews geführt\todo{ürgent was stimmt noch nicht},
 wissenschaftliche Arbeiten, Erfahrungsberichte sowie eigene
-Beobachtungen im CI/CD Umfeld herangezogen.
+Beobachtungen im \cicd Umfeld herangezogen.
 
 \medskip
 Aus der Problemanalyse wurden die Ursachen identifiziert und
 entsprechende Empfehlungen abgeleitet.
-
+\section{Vorgehen}
 \medskip
 In einem ersten Schritt betrachte ich den Softwareentwicklungsprozess
-und die Automatisierungsmöglichkeiten im Allgemeinen, um dann Ideexx von \todo{Ausschreiben}
-CI/CD aufzuzeigen.
+und die Automatisierungsmöglichkeiten im Allgemeinen, um dann Ideexx \todo{Ausschreiben} von
+\cicd aufzuzeigen.
 
 \medskip
 Die Problemrecherche und Analyse kann nicht den Anspruch der
 Vollständigkeit erfüllen. Sie berücksichtigt typische- und häufig
 anzutreffende Probleme. Dabei sind die Empfehlungen unabhängig von einem
 konkreten Anwendungsfall und der Toolsituation formuliert. Probleme zur
-Thematik des mentalen Wandels bei der Einführung von CI/CD werden nicht
+Thematik des mentalen Wandels bei der Einführung von \cicd werden nicht
 betrachtet.

chapters/fazit.tex

@@ -0,0 +1,56 @@
+\hypertarget{fazit}{%
+\chapter{Fazit}\label{fazit}}
+
+In dieser Seminararbeit wurden typische und häufig anzutreffende
+Probleme bei der Einführung und dem Betrieb von \cicd aufgezeigt.
+
+Zu diesen Problemen wurde Maßnahmen erarbeitet, welche sich vor allem in
+der Planungsphase niederschlagen.
+Diese Maßnahmen sind eher generisch formuliert und skizzieren mögliche
+Ansätze zur Problemlösung.
+
+~
+
+Es ist schwer, eine detaillierte und direkt umsetzbare Vorgehensweise
+aufzuzeigen, da sich ein großes Spektrum der Integrations- und
+Automatisierungsmöglichkeiten durch die Kombinationen aus Use Case und
+Tool ergibt.
+Jedes Tool eines \cicd - Systems hat andere Interfaces, Funktionen und
+Möglichkeiten, Informationen an andere Systeme weiterzuleiten.
+Ebenfalls sind die spezifischen Eigenschaften der Use Cases vielfältig. 
+Die Einsatzumgebung und auch die Automatisierungsanforderungen
+variieren.
+
+~
+
+Bei der Planung eines \cicd Systems ist notwendig, diese generische
+Ebene zu verlassen und detaillierte Analyse der Anforderungen des Use
+Cases als auch der Funktionen der potenziellen Tools vorzunehmen.
+
+Erst wenn man sich in einem konkreten Use Case und auch in einer
+konkreten Toolumgebung befindet, werden aus dem generischen Maßnahmen
+für die Planung und das Design diejenige Detailtiefen entwickelt, die
+dann zu einer konkreten Umsetzungsmöglichkeit führen.
+
+~
+
+Am Problem xxx -- ssssss \todo{Problem tag hinzugfügen} wurde dieses Vorgehensweise aufgezeigt und die
+Problemlösung bestätigt.
+
+~
+
+Der Inhalt dieser Seminararbeit beschränkte sich auf Probleme, die sich
+vorwiegend durch Planung und technische Maßnahmen beheben lassen.
+
+Ein weiteres Problemfeld, welches nicht in dieser Arbeit betrachtet
+wurde, ist der notwendige mentale Wandel bei einer Umstellung auf \cicd.
+Ohne Akzeptanz, Verständnis und Kenntnis über Methode und Tools bei den
+Entwicklern, und den Mitgliedern des Test-, Sicherheits- und
+Betriebsteams kann eine Vielzahl von Herausforderungen für ein
+\cicd-Projekt entstehen.
+
+Dieses Bereich liefert weitere Ansatzpunkte zur Forschung, um auch für
+den mentalen Wandel Lösungsansätze zu erarbeiten und die Effekte von
+\cicd bestmöglich nutzen zu können.
+
+~

chapters/grund.tex

@@ -0,0 +1,279 @@
+\hypertarget{automatisierung-im-softwareentwicklungsprozess}{%
+\chapter{Automatisierung im Softwareentwicklungsprozess}\label{automatisierung-im-softwareentwicklungsprozess}}
+
+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.
+
+
+
+~
+
+\section{Phasen im Softwareentwicklungsprozess}\label{soft-phasen}
+
+In der gibt es eine Vielzahl von Modellen zur Unterstützung des
+Softwareentwicklungsprozesses.
+
+Zur Betrachtung der Automatisierungsmöglichkeiten können Komponenten
+eines Phasenmodells herangezogen werden. Dabei werden die Phasen selbst
+betrachtet, unabhängig von der Anordnung, Iteration, ihrem Kontext oder
+Umfang und auch der Philosophie der jeweiligen Methode. Diese einzelnen
+Schritte lassen sich in ähnlicher Form in vielen anderen Methoden
+wiederfinden.
+
+Typische Softwareentwicklungsphasen sind die Anforderungsanalyse, das
+Systemdesign, die Programmierung, der Test sowie der Betrieb.
+
+
+\begin{description}
+
+    \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, die der
+    Strukturierung und Klassifizierung dienen.
+
+    \item[Systemdesign]\label{phase-sys}
+    Hier wird die Architektur der Module, Schnittstellen und Daten
+    festgelegt, die der Spezifikation aus der Anforderungsanalyse genügen
+    sollen.
+
+    \item[Implementierung]\label{phase-code}
+    Die Programmierung mit dem dazugehörigen Modultest sind Bestandteil der
+    Entwicklungsphase der Implementierung
+
+    \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}
+    Der Betrieb um fasst die Inbetriebnahme und Wartung der Software.
+\end{description}
+
+\newpage
+
+\section{Automatisierung im Entwicklungsprozess durch CI/CD}\label{auto-in-dev}
+
+Die Begriffe \cil, \cdel und \cdl beschreiben weit verbreitete Methoden \cite{bobrovskis2018survey}, mit denen Phasen aus dem
+Softwareentwicklungsprozess automatisiert werden.
+
+~
+
+Definierte Ereignisse lösen eine Vielzahl von Einzelschritten aus,
+welche eine kontinuierliche Automatisierung und Überwachung von
+Integration, Test und Auslieferung umsetzen. Auf diese Weise wird die
+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.
+
+~
+
+In Theorie und Praxis gibt es eine Vielzahl von Definitionen zu \cicd.
+Es gibt Funktionalitäten, die 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
+nicht deutlich, ob \cdel oder \cdl gemeint ist.
+
+~
+
+Am Ende zähl nur, dass dies Funktionen entlang eines
+automatisierten und überwachten Prozesses in einer Pipeline durchgeführt
+werden, unabhängig von der Zuordnung zu einem Oberbegriff.
+
+~
+\subsection{Continuous Integration}\label{ci}
+\textbf{„CI``} (\textbf{Continuous Integration}) bezeichnet eine entwicklerorientierte
+Methode, bei der Code durchgängig integriert und getestet wird.
+
+~
+
+Durch \cil werden verschiedene Entwicklungs- und
+Codeversionen, an denen parallel gearbeitet wurde, automatisch
+zusammengeführt und gebaut, um Mergekonflikte und Syntaxfehler
+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
+werden.
+
+~
+
+Je nach Umfang kann \ci das ganze Volumen von Testszenarien abwickeln und
+so die Testphase voll automatisiert abdecken und aufwendige, manuelle
+Testverfahren ersetzen.
+
+~
+
+Zusätzlich können neben den Tests auch andere Prüfungen, wie z.B.
+statischen Codeanalysen durchgeführt werden. So ist es möglich, auch
+nicht funktionale Anforderungen durchzusetzen, Sicherheitsprobleme
+aufzudecken oder auch auf schlecht wartbaren Code hinzuweisen.
+
+~
+
+\cil wird meist durch sogenannte \textbf{\textit{Build-Server}}
+betrieben. Ein \textit{Build-Server} ist eine Software, die darauf spezialisiert ist, auf Anfrage
+Automatisierungen durchzuführen wie z.B. eine Integration. Diese
+automatische Integration wird in einer sterilen Umgebung ausgeführt.
+Eine solche Umgebung ist frei von umgebungsspezifischen Konfigurationen,
+Passwörtern sowie anderen Dateien.
+
+~
+
+Nach der erfolgreichen Integration, dem Test und weiteren Prüfungen
+werden die erzeugten Dateien oder auch Artefakte versioniert und
+archiviert.
+
+~
+
+Ein \cil durchlauf wird auch als \textbf{CI -- Run}
+bezeichnet.
+Ein Beispiel für solche \textit{Build-Server} sind \textit{Jenkins, „drone.io``,
+GitLab-CI}.
+
+~
+
+\subsection*{Continuous Delivery / Continuous Deployment}
+
+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.
+\todo{the fuck}
+
+\subsection{Continuous Delivery}\label{cde}
+
+Die Aufgabe von \textbf{\cdel} ist die automatische Bereitstellung
+der Software in der Zielumgebung (Test, Staging oder auch Produktion),
+nachdem sie zuvor durch \ci integriert, versioniert und archiviert
+abgelegt wurde. Eine automatische Installation in dieser Zielumgebung
+findet nicht statt.
+
+\subsection{Continuous Deployment}\label{cd}
+Eine weiterführende Automatisierung stellt das \textbf{\cdl}
+dar. Es erweitert die Funktionalität des \cdel, in dem es
+die bereitgestellte Software im Zielsystem installiert und in Betrieb
+nimmt.
+
+~
+
+Für den Entwicklungsalltag bedeutet diesen Praktiken, dass kleinste
+Codeänderungen innerhalb von wenigen Minuten produktiv werden können.
+
+~
+
+Das Risiko ist geringer\todo{welches risiko}, weil Änderungen in kleinen Schritten
+durchgeführt werden und bei jedem \textit{CI -- Run} alle Tests wiederholt und am
+Ende in den Betrieb gebracht werden.
+
+
+
+\section{Git und die Bedeutung von Branches}
+
+Das Versionmanagementsystem Git basiert auf dem Konzept der Branches,
+welches verschiedene Codeversionen enthalten kann. Ein Branch ist ein
+Entwicklungszweig, auf dem die Änderungen innerhalb eines
+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. Je nach Art der Änderung \todo{kleine veränderung}auf einem Branch,
+wird sie auf die gewünschte Weise vom CI/CD System verwaltet, integriert
+und in den Betrieb gebracht.
+
+~
+
+Ein weit verbreitetes Branchpattern besteht aus zwei permanente 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
+dem die Codeänderungen aus den temporären Branches zusammengeführt
+werden. Dieser Branch lässt sich in Testumgebungen (Staging-Umgebungen)
+finden.
+
+~
+
+Bei einem Release einer neuen Software, wird der Developmentbranch mit
+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
+ist für sie eine schnelle und häufige Integration vorgesehen.
+
+
+\newpage
+
+\subsection*{Darstellung eines typischen Szenarios unter Nutzung von Git:}
+
+\begin{enumerate}
+\def\labelenumi{(\arabic{enumi})}
+\item
+  \textbf{Entwicklung im Featurebranch}
+\end{enumerate}
+
+Für eine Codeänderung zieht der Entwickler den zuletzt gültigen
+Developmentbranch und erstellt einen neuen Zweig, also einen temporären
+sogenannten „Featurebranch``, unter dem er seine Änderung entwickelt.
+
+~
+
+Auf diesem Branch bestätigt (commitet) er einen ersten Teil der
+Codeänderungen und übt die Push-Operation aus. In Git liegt jetzt ein
+neuer temporärer Featurebranch mit der Spiegelung der Änderungen vor.
+
+\begin{enumerate}
+\def\labelenumi{(\arabic{enumi})}
+\setcounter{enumi}{1}
+\item
+  \textbf{Build und Test in individueller Testumgebung}
+\end{enumerate}
+
+CI/CD wird von Git angestoßen: CI/CD erkennt die neue Software Version
+und startet einen Development-Build auf dem temporäreren Featurebranch,
+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
+\item
+  Eine nur für den Entwickler vorgesehene Softwareversion in einer
+  Testumgebung wird erstellt (bzw. für weiteres Testing)
+\end{itemize}
+
+\begin{enumerate}
+\def\labelenumi{(\arabic{enumi})}
+\setcounter{enumi}{2}
+\item
+  \textbf{Übertragung und Test in der Developmentumgebung xx}
+\end{enumerate}
+
+Sind die Entwicklungsaktivitäten auf dem Featurebranch erfolgreich
+beendet, wird mit der Merge-Operation auf dem Developmentbranch diese
+Änderung integriert.
+
+\begin{enumerate}
+\def\labelenumi{(\arabic{enumi})}
+\setcounter{enumi}{3}
+\item
+  \textbf{Merge des Developmentbranches auf den Masterbranch}
+\end{enumerate}
+
+Zur Releasefreigabe wird der Developmentbranch auf den Masterbranch mit
+der Merge-Operation integriert und produktiv gesetzt