fix part 1
This commit is contained in:
@@ -26,10 +26,10 @@ 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. Schon während der
|
||||
Einführung oder später im Betrieb treten unerwartete Herausforderungen
|
||||
zu Tage.
|
||||
zu Tage, vom gravierenden Fehler in Produktion bis zum Systemstillstand.
|
||||
|
||||
\medskip
|
||||
Eine dieser Herausforderungen, welche erst im Betrieb deutlich werden,
|
||||
Eine typische Herausforderungen, welche erst im Betrieb deutlich werden,
|
||||
ist die unabsichtliche Auslieferung eines nicht produktionsbereiten
|
||||
Codes in den Betrieb.
|
||||
|
||||
@@ -41,16 +41,12 @@ Funktionalität der Software oder sogar einen Systemausfall bewirken.
|
||||
\medskip
|
||||
\section{Ziel der Arbeit}
|
||||
|
||||
\textbf{
|
||||
\noindent
|
||||
Das Auftreten eines ungewollten Deployments und weiterer häufig
|
||||
anzutreffender Probleme innerhalb eines \cicd - Systems kann bereits bei
|
||||
der Einführung durch geeignete Planung und technische Maßnahmen
|
||||
verhindert werden.
|
||||
}
|
||||
\textbf{Mit dieser Seminararbeit soll untersucht werden, inwieweit sich solche und weitere typische und häufige Komplikationen bei der Einführung und dem Betrieb von CI/CD verhindern lassen.}
|
||||
|
||||
\textbf{Sie stellt dar, wie das Auftreten eines ungewollten Deployments und weiterer Probleme sowohl in der Einführung als auch im Betrieb eines CI/CD Systems durch geeignete Planung und technische Maßnahmen verhindert werden können.}
|
||||
|
||||
Anhand einer Problemrecherche und Analyse werden Empfehlungen
|
||||
entwickelt, die bei der Planung und Einführung eines Systems
|
||||
entwickelt, welche bei der Planung und Einführung eines Systems
|
||||
herangezogen werden können.
|
||||
|
||||
\medskip
|
||||
@@ -89,4 +85,12 @@ 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 \cicd werden nicht
|
||||
betrachtet.
|
||||
betrachtet.
|
||||
|
||||
\section{Aufbau}
|
||||
\todo{Fix name Ref}
|
||||
Im Kapitel \nameref{automatisierung-im-softwareentwicklungsprozess} werden Grundlagen für die Phasen der Softwareentwicklung und deren Automatisierung unter CI/CD aufgezeigt, welche um eine Darstellung über das Branchkonzept unter Git ergänzt wird.
|
||||
|
||||
Diese Grundlagen dienen dem Verständnis der im Anschluss in Kapitel \nameref{heraus} dargestellten Ergebnisse der Erhebung und Analyse von Problemen bei der Einführung und im Betrieb von \cicd. Hierbei wird das in der Einleitung angerissene Problem vertieft und erläutert.
|
||||
|
||||
Aus der Problemanalyse werden im Kapitel \nameref{mas} Lösungsansätze und Empfehlungen formuliert und auch eine konkrete Umsetzungsempfehlung für das Eingangsproblem entwickelt.
|
||||
@@ -1,5 +1,6 @@
|
||||
\hypertarget{automatisierung-im-softwareentwicklungsprozess}{%
|
||||
\chapter{Automatisierung im Softwareentwicklungsprozess}\label{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.
|
||||
@@ -14,7 +15,7 @@ Problemdarstellungen.
|
||||
|
||||
\section{Phasen im Softwareentwicklungsprozess}\label{soft-phasen}
|
||||
|
||||
In der gibt es eine Vielzahl von Modellen zur Unterstützung des
|
||||
Es existiert eine Vielzahl von Modellen zur Unterstützung des
|
||||
Softwareentwicklungsprozesses.
|
||||
|
||||
Zur Betrachtung der Automatisierungsmöglichkeiten können Komponenten
|
||||
@@ -32,12 +33,12 @@ Systemdesign, die Programmierung, der Test sowie der Betrieb.
|
||||
|
||||
\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
|
||||
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, die der Spezifikation aus der Anforderungsanalyse genügen
|
||||
festgelegt, welche der Spezifikation aus der Anforderungsanalyse genügen
|
||||
sollen.
|
||||
|
||||
\item[Implementierung]\label{phase-code}
|
||||
@@ -215,6 +216,16 @@ 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.
|
||||
|
||||
~
|
||||
|
||||
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
|
||||
|
||||
@@ -261,7 +272,7 @@ da es im Branchpattern entsprechend definiert wurde.
|
||||
\def\labelenumi{(\arabic{enumi})}
|
||||
\setcounter{enumi}{2}
|
||||
\item
|
||||
\textbf{Übertragung und Test in der Developmentumgebung xx\todo{xx}}
|
||||
\textbf{Übertragung der Ergebnisse in die Developmentbranch}
|
||||
\end{enumerate}
|
||||
|
||||
Sind die Entwicklungsaktivitäten auf dem Featurebranch erfolgreich
|
||||
@@ -276,4 +287,4 @@ beendet, wird mit der Merge-Operation auf dem Developmentbranch diese
|
||||
\end{enumerate}
|
||||
|
||||
Zur Releasefreigabe wird der Developmentbranch auf den Masterbranch mit
|
||||
der Merge-Operation integriert und produktiv gesetzt
|
||||
der Merge-Operation integriert und produktiv gesetzt.
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
\chapter{Empfehlungen für die Planung und Implementierung von CI/CD}
|
||||
\label{mas}
|
||||
|
||||
Im Folgenden werden Empfehlungen aufgezeigt, welche das Auftreten der
|
||||
oben geschilderten Probleme verhindern können.
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
\chapter[Herausforderungen von CI/CD]{Herausforderungen bei der Einführung und im Betrieb von CI/CD}
|
||||
\label{heraus}
|
||||
|
||||
Die Umsetzung und Einführung eines CI/CD System beinhaltet weit mehr als
|
||||
die einfache Automatisierung bestehender Prozesse. Sie birgt
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
% ****************************************************************************************************
|
||||
% 1. Personal data and user ad-hoc commands
|
||||
% ****************************************************************************************************
|
||||
\newcommand{\myTitle}{Anforderungen und Eigenschaften einer qualitativen CI/CD Pipeline\xspace}
|
||||
\newcommand{\myTitle}{Die Konzeption komplikationsreduzierter CI/CD Systeme\xspace}
|
||||
%\newcommand{\mySubtitle}{An Homage to The Elements of Typographic Style\xspace}
|
||||
\newcommand{\myDegree}{asdf\xspace}
|
||||
%\newcommand{\myDegree}{Bachelor of Arts (B.A.)\xspace}
|
||||
|
||||
Reference in New Issue
Block a user