\hypertarget{automatisierung-im-softwareentwicklungsprozess}{% \chapter{Automatisierung im Softwareentwicklungsprozess} \label{automatisierung-im-softwareentwicklungsprozess}} \todo{Quellen} 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 der im Kapitel \ref{heraus} geschilderten Problemdarstellungen. ~ \section{Phasen im Softwareentwicklungsprozess}\label{soft-phasen} Es existiert 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, welche der Strukturierung und Klassifizierung dienen. \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} 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 \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 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} ~ 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``} (\textit{\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 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, welche 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`` und GitLab-CI}. ~ \subsection*{Continuous Delivery / Continuous Deployment} Die Abkürzung CD kann sowohl für \cdel als auch für \cdl stehen. Sie unterscheiden sich im Ausmaß der Automatisierung innerhalb der Pipeline. \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. \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. \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. \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 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 \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, 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 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 und in den Betrieb gebracht. ~ 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 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 gedacht -- und so 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 \end{description} \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 mögliche Mergekonflikte werden aufgedeckt \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 der Ergebnisse in die Developmentbranch} \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.