gundlagen

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