2 AUTOMATISIERUNG IM SOFTWAREENTWICKLUNGSPROZESS

Im diesem Kapitel wird ausgehend von den Phasen des
Softwareentwicklungsprozesses die Funktionsweise von CI/CD 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.

Überschrift: Phasen im Softwareentwicklungsprozess

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.

\hypertarget{anforderungsanalyse}{%
\subsection{\texorpdfstring{\textbf{Anforderungsanalyse}}{Anforderungsanalyse}}\label{anforderungsanalyse}}

\hypertarget{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.}{%
\subsection{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.}\label{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.}}

\textbf{Systemdesign}

\hypertarget{hier-wird-die-architektur-der-module-schnittstellen-und-daten-festgelegt-die-der-spezifikation-aus-der-anforderungsanalyse-genuxfcgen-sollen.}{%
\subsection{Hier wird die Architektur der Module, Schnittstellen und
Daten festgelegt, die der Spezifikation aus der Anforderungsanalyse
genügen
sollen.}\label{hier-wird-die-architektur-der-module-schnittstellen-und-daten-festgelegt-die-der-spezifikation-aus-der-anforderungsanalyse-genuxfcgen-sollen.}}

\textbf{Implementierung}

Die Programmierung mit dem dazugehörigen Modultest sind Bestandteil der
Entwicklungsphase der Implementierung

\hypertarget{softwaretest}{%
\section{\texorpdfstring{Softwaretest
}{Softwaretest }}\label{softwaretest}}

\hypertarget{in-der-testphase-wird-ein-system-oder-eine-komponente-gegen-die-zuvor-spezifizierten-anforderungen-uxfcberpruxfcft.-das-testergebnis-dient-der-behebung-von-softwarefehlern-um-ein-fehlerfreies-system-in-produktion-zu-uxfcbernehmen.}{%
\subsection{\texorpdfstring{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.
}{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. }}\label{in-der-testphase-wird-ein-system-oder-eine-komponente-gegen-die-zuvor-spezifizierten-anforderungen-uxfcberpruxfcft.-das-testergebnis-dient-der-behebung-von-softwarefehlern-um-ein-fehlerfreies-system-in-produktion-zu-uxfcbernehmen.}}

\textbf{Betrieb}

Der Betrieb um fasst die Inbetriebnahme und Wartung der Software

\textbf{Automatisierung im Entwicklungsprozess durch CI/CD}

Die Begriffe Continuous Integration, Continuous Delivery und Continuous
Deployment beschreiben Methoden, 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 Continuous Integration, Continuous Delivery und
Continuous Deployment zusammenhängend ausgeführt, so wird das
betreffende System als CI-CD Pipeline bezeichnet.

In Theorie und Praxis gibt es eine Vielzahl von Definitionen zu CI/CD.

Welche Funktionalitäten aus den Phasen des Entwicklungszyklus dem CI
zugeschrieben werden und welche dem Continuous Delivery/Deployment, kann
variieren. Zusätzlich wird häufig bei der Nennung der Abkürzung CD nicht
deutlich, ob Delivery oder Deployment gemeint ist.

Am Ende zähl doch eigentlich nur, dass dies Funktionen entlang eines
automatisierten und überwachten Prozesses in einer Pipeline durchgeführt
werden, unabhängig von der Zuordnung zu einem sie ordnenden Oberbegriff.

„CI`` (Continuous Integration) bezeichnet eine entwicklerorientierte
Methode, bei der Code durchgängig integriert und getestet wird.

Durch Continuous Integration 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.

Continuous Integration wird meist durch sogenannte Build-Server
betrieben.

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

Die eine Instanz von Continuous Integration wird auch als CI -- Run
bezeichnet.

Ein Beispiel für solche Buildsysteme sind Jenkins, „Drone.io``,
GitLap-CI.

Continuous Delivery / Continuous Integration

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.

Continuous Delivery

Die Aufgabe von Continuous Delivery 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.

Continuous Deployment

Eine weiterführende Automatisierung stellt das Continuous Deployment
dar. Es erweitert die Funktionalität des Continuous Delivery, 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, weil Änderungen in kleinen Schritten
durchgeführt werden und bei jedem CI/CD Run alle Tests wiederholt und am
Ende in den Betrieb gebracht werden.


\textbf{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.

Die Art 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 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.

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
