246 lines
11 KiB
TeX
246 lines
11 KiB
TeX
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
|