wir sind auf dem weg nach finale

bibliography.bib

@@ -115,7 +115,7 @@
 
 @misc{ws19,
 	title = {Skript der Vorlesung ``Software Engineering'' im Wintersemester 19/20},
-	author = {Prof. Dr. U. Andelfinger, Prof. Dr. R. Hahn, Prof. Dr. S. Ruehl},
+	author = {Prof. Dr. U. Andelfinger , Prof. Dr. R. Hahn , Prof. Dr. S. Ruehl},
   year = {2019-2020}
 }
 

chapters/mass.tex

@@ -174,7 +174,7 @@ Richtlinien genutzt werden.
 
 Beispielsweise kann durch technische Maßnahme verhindert werden, dass
 eine ungetestete Softwareversion in einer Produktionsumgebung ungewollt
-verwendet wird: Mit Hilfe eines Artefakt-Archivierungssystems können
+verwIO-et wird: Mit Hilfe eines Artefakt-Archivierungssystems können
 passende Einstellungen vorgenommen werden, welche gewährleisten, dass
 nur getestete Softwareversionen in die Produktion übertragen werden.
 \emph{(\ref{B06} \nameref{B06})}
@@ -195,7 +195,7 @@ Weitere Maßnahmen könnten die Einführung einer \textbf{Hardwarequote} um
 für eine ungewollte Hardwarebeanspruchung für einzelne Nutzer
 vorzubeugen.
 
-Das \textbf{vier-Augenprinzip} klingt zunächst nach einer
+Das \textbf{vier-Augenprinzip} klingt zunächst nach einer \todo{rewrite}
 organisatorischen Maßnahme und kann für unterschiedliche Prozessschritte
 als Qualitätssicherungsmaßnahme vorgesehen werden. Die technische
 Komponente dieser Maßnahme wäre die Dokumentation und

chapters/problems.tex

@@ -79,7 +79,7 @@ Softwareentwicklungsprojekts}\label{E01}
 Insbesondere bei der Wahl eines All-in-One Tool kann es passieren, dass
 der Use Case nicht darstellbar ist. Beispielsweise könnte der Use Case
 einer Softwareentwicklung für ein Autoradio nicht mit einem All-in-One
-Tool für Cloud- und Webanwendung umgesetzt werden.\cite{shahin2017continuous,plonski_herausforderungen_Leo_2020}
+Tool für Cloud- und Webanwendung umgesetzt werden. \cite{shahin2017continuous,plonski_herausforderungen_Leo_2020}
 
 ~
 
@@ -94,7 +94,7 @@ Gerade bei einem All-in-One Tool ist die Einführung besonders
 herausfordernd. Während bei einer individuellen Lösung häufig bereits
 existierende, dem Nutzer bekannte Tools im CI/CD -- System implementiert
 werden, ist bei dem All-in-One Tool häufig mehr an Umstellung zu leisten
-in Bezug auf Tool und Methode.\cite{plonski_herausforderungen_grund_2020,plonski_herausforderungen_Leo_2020}
+in Bezug auf Tool und Methode. \cite{plonski_herausforderungen_grund_2020,plonski_herausforderungen_Leo_2020}
 
 ~
 
@@ -113,7 +113,7 @@ Die problemlose Umstellung auf ein All-in-One Tool hängt stark vom Use
 Case ab. Es gibt Anwendungen, deren Integration ohne große Umstellungen
 funktionieren kann, vor allem bei Neuentwicklungen. Aber es gibt
 entsprechende Gegenbeispiele, welche in dieser Umstellungsphase zu
-Problemen oder Verzögerungen führen können.\cite{plonski_herausforderungen_grund_2020,swan_silos,clark_deliver}
+Problemen oder Verzögerungen führen können. \cite{plonski_herausforderungen_grund_2020,swan_silos,clark_deliver}
 
 ~
 
@@ -164,7 +164,7 @@ Dazu gehören Sicherheitsrichtlinien im Unternehmen, beispielsweise
 könnte das Ausführen eines privilegierten Containers in einem CI/CD
 System nicht zugelassen sein, wenn die CI/CD Systeme Zugriffe auf
 Produktivsysteme besitzen und so durch ein modifiziertes CI/CD Script
-ein unautorisierter Zugriff auf das Produktionssystem erfolgen könnte.\cite{plonski_herausforderungen_Leo_2020,plonski_herausforderungen_grund_2020}\ref{be:jx}
+ein unautorisierter Zugriff auf das Produktionssystem erfolgen könnte. \cite{plonski_herausforderungen_Leo_2020,plonski_herausforderungen_grund_2020} \ref{be:jx}
 
 ~
 
@@ -196,7 +196,7 @@ Kubernetes so konfigurieren, dass es auf einen Lifeness Check(
 Lebenszeichen über den Bereitschaftsstatus der Software) genau über
 diesen Port erhält. Solange die Software nicht angepasst ist und dieses
 Signal nicht empfangen kann, würde das operative System die Anwendung
-immer wieder neu starten, um eine Selbstreparatur zu ermöglichen.\ref{be:gitlab} \cite{plonski_herausforderungen_Leo_2020}
+immer wieder neu starten, um eine Selbstreparatur zu ermöglichen. \ref{be:gitlab} \cite{plonski_herausforderungen_Leo_2020}
 
 ~
 
@@ -207,7 +207,7 @@ $\Rightarrow$ Pipeline zeigt ungewolltes Verhalten -- ist nicht funktionsfähig
 Eine häufig anzutreffende Richtlinie im Kubernetik-Umfeld betrifft die
 Vorgabe, in einem Cluster jede Anwendung im eigenen Namespace
 bereitzustellen. Häufig aber lässt das CI/ CD Tool nur ein Deployment
-auf einen fixen Namespace zu.\cite{be:gitlab,plonski_herausforderungen_Leo_2020}
+auf einen fixen Namespace zu. \cite{be:gitlab,plonski_herausforderungen_Leo_2020}
 
 ~
 
@@ -263,7 +263,7 @@ Der Betrieb eines \cicd Systems kann auch in Bezug auf Speicherplatz
 zu Engpässen führen. Für jede kleineste Codeänderung wird das ganze Set
 von Artefakten generiert und abgespeichert. Dazu gehören der z.B. der
 Code, die Testprotokolle, Reports zur Codeanalyse, Compilerlogs, die
-Software selbst und ihr Containerimage.\cite{plonski_herausforderungen_Leo_2020}
+Software selbst und ihr Containerimage.\cite{plonski_herausforderungen_Leo_2020} \ref{be:jx}
 
 ~
 
@@ -296,7 +296,7 @@ Nutzung des Masterbranch} \label{B04}
 Wird versehentlich direkt auf dem Masterbranch gearbeitet und diese
 Änderung im Source Code Managementsystem freigegeben, kann es zur
 Ausführung der Release-Pipeline kommen und die Softwareversion wird
-unbeabsichtigt ausgeliefert.\cite{plonski_herausforderungen_Leo_2020,plonski_herausforderungen_grund_2020,shahin2017continuous}\ref{be:jx}
+unbeabsichtigt ausgeliefert. \cite{plonski_herausforderungen_Leo_2020,plonski_herausforderungen_grund_2020,shahin2017continuous} \ref{be:jx}
 
 ~
 
@@ -349,7 +349,7 @@ Häufig gibt es Richtlinien, welche die Löschung von Artefakten einer
 Software nach einem vorgegebenen Zeitraum veranlassen, solange sie
 keinem offiziellem Release zugeordnet sind. Bei Unkenntnis über eine
 solche Richtlinie kann der Zugriff auf die Version der Software durch
-diese Löschung verloren gehen. \cite{plonski_herausforderungen_Leo_2020}
+diese Löschung verloren gehen. \cite{plonski_herausforderungen_Leo_2020,shahin2017continuous}
 
 ~
 
@@ -362,7 +362,7 @@ Die statische Codeanalyse erwartet den Source Code in einem spezifischen
 Ordner. Unkenntnis über diese Vorgabe kann dazu führen, dass der Source
 Code in einem anderen Verzeichnis bereitgestellt wird und das
 Analysetool findet im spezifizierten Verzeichnis keinen Code. 
-Manche Tools melden einen positiven Status und der CI/CD Prozess läuft weiter.\ref{be:jx} \cite{shahin2017continuous}
+Manche Tools melden einen positiven Status und der CI/CD Prozess läuft weiter. \ref{be:jx} \cite{shahin2017continuous}
 
 ~
 

pandoc/DemoDoku.md

@@ -0,0 +1,233 @@
+# CI/CD Dokumentation
+
+Dies ist die Dokumentation für die CI/CD Pipeline von dem <RANDOM JAVA WEBSERVICE>
+
+
+## Was wird Automatisiert ?
+Durch das CI/CD System werden Folgende Prozesse Automatisiert durchgeführt :
+
+- **Build**: Build Prozess der Software
+  -	 Automatische Generierung von API-Server Boilercode
+  -	 Kompilierung und Verpacken der Software in eine **.jar*
+- **Test**: Automatisierte Tests
+  - Modul-Test mit angebundenen externen Test Datenbank
+  - Code-Coverage Report
+- **Analyse**: Analyse von Sourcecode und Test Reports
+  - Statische Code Analyse durch SonarQube mit Qualitätsprofil **Sonar-Way**
+  - Analyse des Code-Coverage Reports
+  - Analyse des Modul-Test Ergebnisses
+- **Package**: Cloudgerechte Verpackung des Software
+  - Containerisierung in einem Container-Image für die Cloudnutzung
+  - Linting des Helm-Charts für Kubernetes
+- **Deploy**: Deployment der Software
+  - Deployment auf einem Kubernetes Cluster durch Helm
+
+## Welche Komponenten/Tools werden verwendet
+
+Folgende Komponenten/Tools werden im CI/CD Prozess verwendet: 
+
+ - **Build**
+   	- OpenAPI Codegenerator
+    - Maven
+- **Test**
+  - JUnit-5
+  - JaCoCo
+- **Analyse**
+  - Static Code Analysis
+    - SonarQube 7
+- **Package**
+    - Kaniko
+    - Helm
+- **Deploy**
+    - Helm
+    - Kubernetes
+
+**CI/CD Engine**: Serverless Jenkins X
+
+# CI/CD In-,Outputs
+
+
+
+## Trigger
+Jenkins X erhält verschiedene Inputs,Trigger und Signale durch einen Webhook-Server namens *Lighthouse*. An ihn werden Eventbenachichtigungen durch GitLab gesendet um anschließend ein **CI-Run** zu starten.
+
+Dabei wird ein **CI-Run** durch folgende Trigger und Konditionen gestartet:
+
+- Push auf den **master** branch auf GitLab
+- Push auf einen branch mit offenen *Merge Request*
+- Ausführen des Befehlt ``jx start pipeline``
+
+## Inputs und Kontexte Daten
+
+Diese Daten fliesen und beeinflussen den **CI-Build**:
+
+- Source-Code
+- Branch von den die Pipeline getriggert wurde
+- User, der die Pipeline ausgelöst hat.
+- Offene Mergerequests
+- Prow-Konfiguration
+- Jenkins X Projekt Konfiguration
+- HMAC Secret des Webhookrequestes
+# Pipeline Definitionen
+
+Es existieren zwei verschiedene Pipelines die durch die Trigger ausgelöst werden können:
+
+- Release
+- Preview
+
+## Release
+
+Diese Pipeline kompeliert, testet, analysiert, verpackt und bereitet die Software zum Deployment vor.
+
+Sie deployed jedoch die Anwendung nicht, sondern erstellt/modifiziert lediglich verschiedene Umgebungskonfigurationen, bei denen das automatische Deployment vorgesehen ist.
+
+**Trigger**: Push oder Merge auf den **master** Branch.
+
+### Stage: Setup (Buildpack Maven)
+
+In dieser Stage wird der Buildprozess vorbereitet und eingeleitet.
+
+Befehle:
+
+-  `echo \$(jx-release-version) > VERSION`
+Schreiben der neuen Software Version in eine Temporäre `VERSION` Datei um diese in späteren Schritten wieder abrufen zu können
+-  `mvn versions:set -DnewVersion=\$(cat VERSION)`
+Setzen der Software Version in Maven um die neuen Software-Artefakte direkt mit richtigen namen und Tags zu versehen.
+-  `jx step tag --version \$(cat VERSION)`
+Setzen der Software Version in Jenkins X und in Git als Tag.
+
+### Stage: Build (Buildpack Maven)
+
+In dieser Stage werden alle zum Build dazugehörigen komponenten und Tools ausgeführt. Bei einigen befehlen werden mehrere Tools und Komponenten gleichzeitig ausgeführt um den Buildprozess erfolgreich abzuschließen.
+
+**Befehle**:
+
+- ` mvn clean deploy` 
+Durch diesen Befehl wird die eigentliche Software gebaut. Der Bauprozess in Maven ist in verschiedene Phasen aufgeteilt, die in einer festen Reinfolge abgearbeitet werden.
+In jedem dieser Phasen wird ein anderes Tool/Plugin/Komponente aufgerufen. Nach dem Abschluss jeder Phase wird überprüft, ob die Phase erfolgreich abgeschlossen wurde.
+  **Phasen**:
+  
+  - `clean`
+    Bereinigt den Projekt Ordner von überresten eines vorherigen buildprozesses.
+  
+  - `generate-sources`
+    Erstellt mithilfe von **openapi-generator.tech** Serverboilercode und API Schnittstellendefinitionen aus einer *OpenAPI-Definitions Datei*.
+    Diese liegt unter `src/main/resources/api.yaml` und ist in *OpenAPI v3* formatiert.
+  
+    Der generierte Code ist unter `target/generated-sources/openapi` abgelegt und wird automatisch in den *Classpath* eingebunden.
+  
+  - `compile`
+    Erhebt alle Dependencys und stellt diese zu den entsprechenden Phasen des Buildvorgangs zuverfügung. Anschließend werden alle Sourcen die sich in dem Sourcepath befinden kompeliert.
+  
+  - `test`
+    Führt UnitTests mithilfe von *JUnit 5* aus. *JUnit* scannt nach Aktivierten und Relevanten Tests und führt diese aus. Die Ergebnisse werden in Form eines XML-Reports in den `target` Ordner abgelegt. Bei der Ausführung der Tests wird zusätzlich die Code Coverage durch *JaCoCo* erhoben und ebenfals ein Report unter `target` abgelegt. 
+  
+  - `package`
+  Erzeugt eine ausführbare `.jar` Datei mit allen benötigten Dependencys um diese zu Containerisieren. 
+  
+- `skaffold build -f skaffold.yaml`
+  Wird durch Jenkins X zu Kaniko build umformatiert.
+  Baut Container Image mit Parameter aus Jenkins X und veröffentlich diese in einem Container Registry
+  
+- Sonarqube Analyse (Custom addition)
+
+  ```bash
+  mvn --batch-mode sonar:sonar \
+   -Dsonar.projectKey=<sonarqube projekt key> \
+   -Dsonar.host.url=<sonarqube host> \
+   -Dsonar.login=<sonarqube login key> \
+   -Dsonar.gitlab.commit_sha=$(git rev-parse HEAD) \
+   -Dsonar.gitlab.ref_name=$(git rev-parse --abbrev-ref HEAD) \
+   -Dsonar.gitlab.project_id=<project id> \
+   -Dsonar.branch.name=$BRANCH_NAME \
+   -Dsonar.gitlab.user_token=<gitlab access toekn>\
+  ```
+
+  Analysiert Projekt mit Hilfe von SonarQube und bricht die Pipeline ab wenn Qualitätsprobleme gefunden wurden.
+
+
+
+### Stage: Promote (Buildpack Maven)
+
+In dieser Stage werden die erzeugten Artefakte in die zugehörigen Artefaktarchivierungssysteme hochgeladen und die verschiedenen Umgebungskonfigurationen modifiziert um den *CD-Prozess* zu starten.
+
+**Befehle:**
+
+- `jx step changelog --version v\$(cat ../../VERSION)`
+Fügt dem Tag und dem Release in GitLab Changelogs aus den Commitnachichten hinzu. 
+- ` jx step helm release`
+Veröffentlich das Helmchat aus dem `charts` Ordner unter einer neuen Version im Chartmuseum.
+- `jx promote -b --all-auto --timeout 1h --version \$(cat ../../VERSION)`
+Modifiziert oder Erstellt die Umgebunskonfigurationen bei denen in Jenkins X *Autodeploy* aktiviert wurde.
+
+## Preview
+
+Diese Pipeline kompeliert, testet, analysiert, verpackt und bereitet die Software zum deployment in eine temporäre Previewenvirgonment.
+
+Diese Pipeline ist nicht zum Bau einer Realease Version gedacht und bereitet die Software nur für ein themporäres Preview vor.
+
+**Trigger**: Push oder Merge auf einen Branch, der Quelle eines offenen *Merge-Request* ist. 
+
+### Stage: Build (Buildpack Maven)
+
+In dieser Stage werden alle zum Build dazugehörigen komponenten und Tools ausgeführt. Bei einigen befehlen werden mehrere Tools und Komponenten gleichzeitig ausgeführt um den Buildprozess erfolgreich abzuschließen.
+
+**Befehle**:
+
+- ` mvn clean install` 
+Durch diesen Befehl wird die eigentliche Software gebaut. Der Bauprozess in Maven ist in verschiedene Phasen aufgeteilt, die in einer festen Reinfolge abgearbeitet werden.
+In jedem dieser Phasen wird ein anderes Tool/Plugin/Komponente aufgerufen. Nach dem Abschluss jeder Phase wird überprüft, ob die Phase erfolgreich abgeschlossen wurde.
+  **Phasen**:
+  
+  - `clean`
+    Bereinigt den Projekt Ordner von überresten eines vorherigen buildprozesses.
+  
+  - `generate-sources`
+    Erstellt mithilfe von **openapi-generator.tech** Serverboilercode und API Schnittstellendefinitionen aus einer *OpenAPI-Definitions Datei*.
+    Diese liegt unter `src/main/resources/api.yaml` und ist in *OpenAPI v3* formatiert.
+  
+    Der generierte Code ist unter `target/generated-sources/openapi` abgelegt und wird automatisch in den *Classpath* eingebunden.
+  
+  - `compile`
+    Erhebt alle Dependencys und stellt diese zu den entsprechenden Phasen des Buildvorgangs zuverfügung. Anschließend werden alle Sourcen die sich in dem Sourcepath befinden kompeliert.
+  
+  - `test`
+    Führt UnitTests mithilfe von *JUnit 5* aus. *JUnit* scannt nach Aktivierten und Relevanten Tests und führt diese aus. Die Ergebnisse werden in Form eines XML-Reports in den `target` Ordner abgelegt. Bei der Ausführung der Tests wird zusätzlich die Code Coverage durch *JaCoCo* erhoben und ebenfals ein Report unter `target` abgelegt. 
+  
+  - `package`
+  Erzeugt eine ausführbare `.jar` Datei mit allen benötigten Dependencys um diese zu Containerisieren. 
+  
+- `skaffold build -f skaffold.yaml`
+  Wird durch Jenkins X zu Kaniko build umformatiert.
+  Baut Container Image mit Parameter aus Jenkins X und veröffentlich diese in einem Container Registry
+  
+- Sonarqube Analyse (Custom addition)
+
+  ```bash
+  mvn --batch-mode sonar:sonar \
+   -Dsonar.projectKey=<sonarqube projekt key> \
+   -Dsonar.host.url=<sonarqube host> \
+   -Dsonar.login=<sonarqube login key> \
+   -Dsonar.gitlab.commit_sha=$(echo $PULL_REFS | cut -d':' -f3) \
+   -Dsonar.gitlab.ref_name=$(git rev-parse --abbrev-ref HEAD) \
+   -Dsonar.gitlab.project_id=<project id> \
+   -Dsonar.branch.name=$BRANCH_NAME \
+   -Dsonar.gitlab.user_token=<gitlab access toekn>\
+  ```
+
+  Analysiert Projekt mit Hilfe von SonarQube.
+
+
+
+### Stage: Promote (Buildpack Maven)
+
+In dieser Stage werden die erzeugten Artefakte in die zugehörigen Artefaktarchivierungssysteme hochgeladen und eine temporäre Previewumgebung erstellt um die Anwendung kurzzeitig zu testen.
+
+**Befehle:**
+
+- `jx step changelog --version v\$(cat ../../VERSION)`
+Fügt dem Tag und dem Release in GitLab Changelogs aus den Commitnachichten hinzu. 
+- ` jx step helm release`
+Veröffentlich das Helmchat aus dem `charts` Ordner unter einer neuen Version im Chartmuseum.
+- `jx promote -b --all-auto --timeout 1h --version \$(cat ../../VERSION)`
+Modifiziert oder Erstellt die Umgebunskonfigurationen bei denen in Jenkins X *Autodeploy* aktiviert wurde.

pandoc/doku.tex

@@ -0,0 +1,477 @@
+\newcommand{\VerbBar}{|}
+\newcommand{\VERB}{\Verb[commandchars=\\\{\}]}
+\DefineVerbatimEnvironment{Highlighting}{Verbatim}{commandchars=\\\{\}}
+% Add ',fontsize=\small' for more characters per line
+\newenvironment{Shaded}{}{}
+\newcommand{\AlertTok}[1]{\textcolor[rgb]{1.00,0.00,0.00}{\textbf{#1}}}
+\newcommand{\AnnotationTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}}
+\newcommand{\AttributeTok}[1]{\textcolor[rgb]{0.49,0.56,0.16}{#1}}
+\newcommand{\BaseNTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}}
+\newcommand{\BuiltInTok}[1]{#1}
+\newcommand{\CharTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}}
+\newcommand{\CommentTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textit{#1}}}
+\newcommand{\CommentVarTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}}
+\newcommand{\ConstantTok}[1]{\textcolor[rgb]{0.53,0.00,0.00}{#1}}
+\newcommand{\ControlFlowTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{\textbf{#1}}}
+\newcommand{\DataTypeTok}[1]{\textcolor[rgb]{0.56,0.13,0.00}{#1}}
+\newcommand{\DecValTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}}
+\newcommand{\DocumentationTok}[1]{\textcolor[rgb]{0.73,0.13,0.13}{\textit{#1}}}
+\newcommand{\ErrorTok}[1]{\textcolor[rgb]{1.00,0.00,0.00}{\textbf{#1}}}
+\newcommand{\ExtensionTok}[1]{#1}
+\newcommand{\FloatTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}}
+\newcommand{\FunctionTok}[1]{\textcolor[rgb]{0.02,0.16,0.49}{#1}}
+\newcommand{\ImportTok}[1]{#1}
+\newcommand{\InformationTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}}
+\newcommand{\KeywordTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{\textbf{#1}}}
+\newcommand{\NormalTok}[1]{#1}
+\newcommand{\OperatorTok}[1]{\textcolor[rgb]{0.40,0.40,0.40}{#1}}
+\newcommand{\OtherTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{#1}}
+\newcommand{\PreprocessorTok}[1]{\textcolor[rgb]{0.74,0.48,0.00}{#1}}
+\newcommand{\RegionMarkerTok}[1]{#1}
+\newcommand{\SpecialCharTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}}
+\newcommand{\SpecialStringTok}[1]{\textcolor[rgb]{0.73,0.40,0.53}{#1}}
+\newcommand{\StringTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}}
+\newcommand{\VariableTok}[1]{\textcolor[rgb]{0.10,0.09,0.49}{#1}}
+\newcommand{\VerbatimStringTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}}
+\newcommand{\WarningTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}}
+\setlength{\emergencystretch}{3em} % prevent overfull lines
+\providecommand{\tightlist}{%
+  \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}}
+\setcounter{secnumdepth}{-\maxdimen} % remove section numbering
+
+\hypertarget{cicd-dokumentation}{%
+\section{CI/CD Dokumentation}\label{cicd-dokumentation}}
+
+Dies ist die Dokumentation für die CI/CD Pipeline von dem
+
+\hypertarget{was-wird-automatisiert}{%
+\subsection{Was wird Automatisiert ?}\label{was-wird-automatisiert}}
+
+Durch das CI/CD System werden Folgende Prozesse Automatisiert
+durchgeführt :
+
+\begin{itemize}
+\tightlist
+\item
+  \textbf{Build}: Build Prozess der Software
+
+  \begin{itemize}
+  \tightlist
+  \item
+    Automatische Generierung von API-Server Boilercode
+  \item
+    Kompilierung und Verpacken der Software in eine **.jar*
+  \end{itemize}
+\item
+  \textbf{Test}: Automatisierte Tests
+
+  \begin{itemize}
+  \tightlist
+  \item
+    Modul-Test mit angebundenen externen Test Datenbank
+  \item
+    Code-Coverage Report
+  \end{itemize}
+\item
+  \textbf{Analyse}: Analyse von Sourcecode und Test Reports
+
+  \begin{itemize}
+  \tightlist
+  \item
+    Statische Code Analyse durch SonarQube mit Qualitätsprofil
+    \textbf{Sonar-Way}
+  \item
+    Analyse des Code-Coverage Reports
+  \item
+    Analyse des Modul-Test Ergebnisses
+  \end{itemize}
+\item
+  \textbf{Package}: Cloudgerechte Verpackung des Software
+
+  \begin{itemize}
+  \tightlist
+  \item
+    Containerisierung in einem Container-Image für die Cloudnutzung
+  \item
+    Linting des Helm-Charts für Kubernetes
+  \end{itemize}
+\item
+  \textbf{Deploy}: Deployment der Software
+
+  \begin{itemize}
+  \tightlist
+  \item
+    Deployment auf einem Kubernetes Cluster durch Helm
+  \end{itemize}
+\end{itemize}
+
+\hypertarget{welche-komponententools-werden-verwendet}{%
+\subsection{Welche Komponenten/Tools werden
+verwendet}\label{welche-komponententools-werden-verwendet}}
+
+Folgende Komponenten/Tools werden im CI/CD Prozess verwendet:
+
+\begin{itemize}
+\tightlist
+\item
+  \textbf{Build}
+
+  \begin{itemize}
+  \tightlist
+  \item
+    OpenAPI Codegenerator
+  \item
+    Maven
+  \end{itemize}
+\item
+  \textbf{Test}
+
+  \begin{itemize}
+  \tightlist
+  \item
+    JUnit-5
+  \item
+    JaCoCo
+  \end{itemize}
+\item
+  \textbf{Analyse}
+
+  \begin{itemize}
+  \tightlist
+  \item
+    Static Code Analysis
+
+    \begin{itemize}
+    \tightlist
+    \item
+      SonarQube 7
+    \end{itemize}
+  \end{itemize}
+\item
+  \textbf{Package}
+
+  \begin{itemize}
+  \tightlist
+  \item
+    Kaniko
+  \item
+    Helm
+  \end{itemize}
+\item
+  \textbf{Deploy}
+
+  \begin{itemize}
+  \tightlist
+  \item
+    Helm
+  \item
+    Kubernetes
+  \end{itemize}
+\end{itemize}
+
+\textbf{CI/CD Engine}: Serverless Jenkins X
+
+\hypertarget{cicd-in-outputs}{%
+\section{CI/CD In-,Outputs}\label{cicd-in-outputs}}
+
+\hypertarget{trigger}{%
+\subsection{Trigger}\label{trigger}}
+
+Jenkins X erhält verschiedene Inputs,Trigger und Signale durch einen
+Webhook-Server namens \emph{Lighthouse}. An ihn werden
+Eventbenachichtigungen durch GitLab gesendet um anschließend ein
+\textbf{CI-Run} zu starten.
+
+Dabei wird ein \textbf{CI-Run} durch folgende Trigger und Konditionen
+gestartet:
+
+\begin{itemize}
+\tightlist
+\item
+  Push auf den \textbf{master} branch auf GitLab
+\item
+  Push auf einen branch mit offenen \emph{Merge Request}
+\item
+  Ausführen des Befehlt \texttt{jx\ start\ pipeline}
+\end{itemize}
+
+\hypertarget{inputs-und-kontexte-daten}{%
+\subsection{Inputs und Kontexte Daten}\label{inputs-und-kontexte-daten}}
+
+Diese Daten fliesen und beeinflussen den \textbf{CI-Build}:
+
+\begin{itemize}
+\tightlist
+\item
+  Source-Code
+\item
+  Branch von den die Pipeline getriggert wurde
+\item
+  User, der die Pipeline ausgelöst hat.
+\item
+  Offene Mergerequests
+\item
+  Prow-Konfiguration
+\item
+  Jenkins X Projekt Konfiguration
+\item
+  HMAC Secret des Webhookrequestes \# Pipeline Definitionen
+\end{itemize}
+
+Es existieren zwei verschiedene Pipelines die durch die Trigger
+ausgelöst werden können:
+
+\begin{itemize}
+\tightlist
+\item
+  Release
+\item
+  Preview
+\end{itemize}
+
+\hypertarget{release}{%
+\subsection{Release}\label{release}}
+
+Diese Pipeline kompeliert, testet, analysiert, verpackt und bereitet die
+Software zum Deployment vor.
+
+Sie deployed jedoch die Anwendung nicht, sondern erstellt/modifiziert
+lediglich verschiedene Umgebungskonfigurationen, bei denen das
+automatische Deployment vorgesehen ist.
+
+\textbf{Trigger}: Push oder Merge auf den \textbf{master} Branch.
+
+\hypertarget{stage-setup-buildpack-maven}{%
+\subsubsection{Stage: Setup (Buildpack
+Maven)}\label{stage-setup-buildpack-maven}}
+
+In dieser Stage wird der Buildprozess vorbereitet und eingeleitet.
+
+Befehle:
+
+\begin{itemize}
+\tightlist
+\item
+  \texttt{echo\ \textbackslash{}\$(jx-release-version)\ \textgreater{}\ VERSION}
+  Schreiben der neuen Software Version in eine Temporäre
+  \texttt{VERSION} Datei um diese in späteren Schritten wieder abrufen
+  zu können
+\item
+  \texttt{mvn\ versions:set\ -DnewVersion=\textbackslash{}\$(cat\ VERSION)}
+  Setzen der Software Version in Maven um die neuen Software-Artefakte
+  direkt mit richtigen namen und Tags zu versehen.
+\item
+  \texttt{jx\ step\ tag\ -\/-version\ \textbackslash{}\$(cat\ VERSION)}
+  Setzen der Software Version in Jenkins X und in Git als Tag.
+\end{itemize}
+
+\hypertarget{stage-build-buildpack-maven}{%
+\subsubsection{Stage: Build (Buildpack
+Maven)}\label{stage-build-buildpack-maven}}
+
+In dieser Stage werden alle zum Build dazugehörigen komponenten und
+Tools ausgeführt. Bei einigen befehlen werden mehrere Tools und
+Komponenten gleichzeitig ausgeführt um den Buildprozess erfolgreich
+abzuschließen.
+
+\textbf{Befehle}:
+
+\begin{itemize}
+\item
+  \texttt{mvn\ clean\ deploy} Durch diesen Befehl wird die eigentliche
+  Software gebaut. Der Bauprozess in Maven ist in verschiedene Phasen
+  aufgeteilt, die in einer festen Reinfolge abgearbeitet werden. In
+  jedem dieser Phasen wird ein anderes Tool/Plugin/Komponente
+  aufgerufen. Nach dem Abschluss jeder Phase wird überprüft, ob die
+  Phase erfolgreich abgeschlossen wurde. \textbf{Phasen}:
+
+  \begin{itemize}
+  \item
+    \texttt{clean} Bereinigt den Projekt Ordner von überresten eines
+    vorherigen buildprozesses.
+  \item
+    \texttt{generate-sources} Erstellt mithilfe von
+    \textbf{openapi-generator.tech} Serverboilercode und API
+    Schnittstellendefinitionen aus einer \emph{OpenAPI-Definitions
+    Datei}. Diese liegt unter \texttt{src/main/resources/api.yaml} und
+    ist in \emph{OpenAPI v3} formatiert.
+
+    Der generierte Code ist unter
+    \texttt{target/generated-sources/openapi} abgelegt und wird
+    automatisch in den \emph{Classpath} eingebunden.
+  \item
+    \texttt{compile} Erhebt alle Dependencys und stellt diese zu den
+    entsprechenden Phasen des Buildvorgangs zuverfügung. Anschließend
+    werden alle Sourcen die sich in dem Sourcepath befinden kompeliert.
+  \item
+    \texttt{test} Führt UnitTests mithilfe von \emph{JUnit 5} aus.
+    \emph{JUnit} scannt nach Aktivierten und Relevanten Tests und führt
+    diese aus. Die Ergebnisse werden in Form eines XML-Reports in den
+    \texttt{target} Ordner abgelegt. Bei der Ausführung der Tests wird
+    zusätzlich die Code Coverage durch \emph{JaCoCo} erhoben und
+    ebenfals ein Report unter \texttt{target} abgelegt.
+  \item
+    \texttt{package} Erzeugt eine ausführbare \texttt{.jar} Datei mit
+    allen benötigten Dependencys um diese zu Containerisieren.
+  \end{itemize}
+\item
+  \texttt{skaffold\ build\ -f\ skaffold.yaml} Wird durch Jenkins X zu
+  Kaniko build umformatiert. Baut Container Image mit Parameter aus
+  Jenkins X und veröffentlich diese in einem Container Registry
+\item
+  Sonarqube Analyse (Custom addition)
+
+\begin{Shaded}
+\begin{Highlighting}[]
+\ExtensionTok{mvn}\NormalTok{ {-}{-}batch{-}mode sonar:sonar \textbackslash{}}
+\NormalTok{ {-}Dsonar.projectKey=}\OperatorTok{\textless{}}\NormalTok{sonarqube projekt key}\OperatorTok{\textgreater{}}\NormalTok{ \textbackslash{}}
+\NormalTok{ {-}Dsonar.host.url=}\OperatorTok{\textless{}}\NormalTok{sonarqube host}\OperatorTok{\textgreater{}}\NormalTok{ \textbackslash{}}
+\NormalTok{ {-}Dsonar.login=}\OperatorTok{\textless{}}\NormalTok{sonarqube login key}\OperatorTok{\textgreater{}}\NormalTok{ \textbackslash{}}
+\NormalTok{ {-}Dsonar.gitlab.commit\_sha=}\VariableTok{$(}\FunctionTok{git}\NormalTok{ rev{-}parse HEAD}\VariableTok{)}\NormalTok{ \textbackslash{}}
+\NormalTok{ {-}Dsonar.gitlab.ref\_name=}\VariableTok{$(}\FunctionTok{git}\NormalTok{ rev{-}parse {-}{-}abbrev{-}ref HEAD}\VariableTok{)}\NormalTok{ \textbackslash{}}
+\NormalTok{ {-}Dsonar.gitlab.project\_id=}\OperatorTok{\textless{}}\NormalTok{project id}\OperatorTok{\textgreater{}}\NormalTok{ \textbackslash{}}
+\NormalTok{ {-}Dsonar.branch.name=}\VariableTok{$BRANCH\_NAME}\NormalTok{ \textbackslash{}}
+\NormalTok{ {-}Dsonar.gitlab.user\_token=}\OperatorTok{\textless{}}\NormalTok{gitlab access toekn}\OperatorTok{\textgreater{}}\NormalTok{\textbackslash{}}
+\end{Highlighting}
+\end{Shaded}
+
+  Analysiert Projekt mit Hilfe von SonarQube und bricht die Pipeline ab
+  wenn Qualitätsprobleme gefunden wurden.
+\end{itemize}
+
+\hypertarget{stage-promote-buildpack-maven}{%
+\subsubsection{Stage: Promote (Buildpack
+Maven)}\label{stage-promote-buildpack-maven}}
+
+In dieser Stage werden die erzeugten Artefakte in die zugehörigen
+Artefaktarchivierungssysteme hochgeladen und die verschiedenen
+Umgebungskonfigurationen modifiziert um den \emph{CD-Prozess} zu
+starten.
+
+\textbf{Befehle:}
+
+\begin{itemize}
+\tightlist
+\item
+  \texttt{jx\ step\ changelog\ -\/-version\ v\textbackslash{}\$(cat\ ../../VERSION)}
+  Fügt dem Tag und dem Release in GitLab Changelogs aus den
+  Commitnachichten hinzu.
+\item
+  \texttt{jx\ step\ helm\ release} Veröffentlich das Helmchat aus dem
+  \texttt{charts} Ordner unter einer neuen Version im Chartmuseum.
+\item
+  \texttt{jx\ promote\ -b\ -\/-all-auto\ -\/-timeout\ 1h\ -\/-version\ \textbackslash{}\$(cat\ ../../VERSION)}
+  Modifiziert oder Erstellt die Umgebunskonfigurationen bei denen in
+  Jenkins X \emph{Autodeploy} aktiviert wurde.
+\end{itemize}
+
+\hypertarget{preview}{%
+\subsection{Preview}\label{preview}}
+
+Diese Pipeline kompeliert, testet, analysiert, verpackt und bereitet die
+Software zum deployment in eine temporäre Previewenvirgonment.
+
+Diese Pipeline ist nicht zum Bau einer Realease Version gedacht und
+bereitet die Software nur für ein themporäres Preview vor.
+
+\textbf{Trigger}: Push oder Merge auf einen Branch, der Quelle eines
+offenen \emph{Merge-Request} ist.
+
+\hypertarget{stage-build-buildpack-maven-1}{%
+\subsubsection{Stage: Build (Buildpack
+Maven)}\label{stage-build-buildpack-maven-1}}
+
+In dieser Stage werden alle zum Build dazugehörigen komponenten und
+Tools ausgeführt. Bei einigen befehlen werden mehrere Tools und
+Komponenten gleichzeitig ausgeführt um den Buildprozess erfolgreich
+abzuschließen.
+
+\textbf{Befehle}:
+
+\begin{itemize}
+\item
+  \texttt{mvn\ clean\ install} Durch diesen Befehl wird die eigentliche
+  Software gebaut. Der Bauprozess in Maven ist in verschiedene Phasen
+  aufgeteilt, die in einer festen Reinfolge abgearbeitet werden. In
+  jedem dieser Phasen wird ein anderes Tool/Plugin/Komponente
+  aufgerufen. Nach dem Abschluss jeder Phase wird überprüft, ob die
+  Phase erfolgreich abgeschlossen wurde. \textbf{Phasen}:
+
+  \begin{itemize}
+  \item
+    \texttt{clean} Bereinigt den Projekt Ordner von überresten eines
+    vorherigen buildprozesses.
+  \item
+    \texttt{generate-sources} Erstellt mithilfe von
+    \textbf{openapi-generator.tech} Serverboilercode und API
+    Schnittstellendefinitionen aus einer \emph{OpenAPI-Definitions
+    Datei}. Diese liegt unter \texttt{src/main/resources/api.yaml} und
+    ist in \emph{OpenAPI v3} formatiert.
+
+    Der generierte Code ist unter
+    \texttt{target/generated-sources/openapi} abgelegt und wird
+    automatisch in den \emph{Classpath} eingebunden.
+  \item
+    \texttt{compile} Erhebt alle Dependencys und stellt diese zu den
+    entsprechenden Phasen des Buildvorgangs zuverfügung. Anschließend
+    werden alle Sourcen die sich in dem Sourcepath befinden kompeliert.
+  \item
+    \texttt{test} Führt UnitTests mithilfe von \emph{JUnit 5} aus.
+    \emph{JUnit} scannt nach Aktivierten und Relevanten Tests und führt
+    diese aus. Die Ergebnisse werden in Form eines XML-Reports in den
+    \texttt{target} Ordner abgelegt. Bei der Ausführung der Tests wird
+    zusätzlich die Code Coverage durch \emph{JaCoCo} erhoben und
+    ebenfals ein Report unter \texttt{target} abgelegt.
+  \item
+    \texttt{package} Erzeugt eine ausführbare \texttt{.jar} Datei mit
+    allen benötigten Dependencys um diese zu Containerisieren.
+  \end{itemize}
+\item
+  \texttt{skaffold\ build\ -f\ skaffold.yaml} Wird durch Jenkins X zu
+  Kaniko build umformatiert. Baut Container Image mit Parameter aus
+  Jenkins X und veröffentlich diese in einem Container Registry
+\item
+  Sonarqube Analyse (Custom addition)
+
+\begin{Shaded}
+\begin{Highlighting}[]
+\ExtensionTok{mvn}\NormalTok{ {-}{-}batch{-}mode sonar:sonar \textbackslash{}}
+\NormalTok{ {-}Dsonar.projectKey=}\OperatorTok{\textless{}}\NormalTok{sonarqube projekt key}\OperatorTok{\textgreater{}}\NormalTok{ \textbackslash{}}
+\NormalTok{ {-}Dsonar.host.url=}\OperatorTok{\textless{}}\NormalTok{sonarqube host}\OperatorTok{\textgreater{}}\NormalTok{ \textbackslash{}}
+\NormalTok{ {-}Dsonar.login=}\OperatorTok{\textless{}}\NormalTok{sonarqube login key}\OperatorTok{\textgreater{}}\NormalTok{ \textbackslash{}}
+\NormalTok{ {-}Dsonar.gitlab.commit\_sha=}\VariableTok{$(}\BuiltInTok{echo} \VariableTok{$PULL\_REFS} \KeywordTok{|} \FunctionTok{cut}\NormalTok{ {-}d}\StringTok{\textquotesingle{}:\textquotesingle{}}\NormalTok{ {-}f3}\VariableTok{)}\NormalTok{ \textbackslash{}}
+\NormalTok{ {-}Dsonar.gitlab.ref\_name=}\VariableTok{$(}\FunctionTok{git}\NormalTok{ rev{-}parse {-}{-}abbrev{-}ref HEAD}\VariableTok{)}\NormalTok{ \textbackslash{}}
+\NormalTok{ {-}Dsonar.gitlab.project\_id=}\OperatorTok{\textless{}}\NormalTok{project id}\OperatorTok{\textgreater{}}\NormalTok{ \textbackslash{}}
+\NormalTok{ {-}Dsonar.branch.name=}\VariableTok{$BRANCH\_NAME}\NormalTok{ \textbackslash{}}
+\NormalTok{ {-}Dsonar.gitlab.user\_token=}\OperatorTok{\textless{}}\NormalTok{gitlab access toekn}\OperatorTok{\textgreater{}}\NormalTok{\textbackslash{}}
+\end{Highlighting}
+\end{Shaded}
+
+  Analysiert Projekt mit Hilfe von SonarQube.
+\end{itemize}
+
+\hypertarget{stage-promote-buildpack-maven-1}{%
+\subsubsection{Stage: Promote (Buildpack
+Maven)}\label{stage-promote-buildpack-maven-1}}
+
+In dieser Stage werden die erzeugten Artefakte in die zugehörigen
+Artefaktarchivierungssysteme hochgeladen und eine temporäre
+Previewumgebung erstellt um die Anwendung kurzzeitig zu testen.
+
+\textbf{Befehle:}
+
+\begin{itemize}
+\tightlist
+\item
+  \texttt{jx\ step\ changelog\ -\/-version\ v\textbackslash{}\$(cat\ ../../VERSION)}
+  Fügt dem Tag und dem Release in GitLab Changelogs aus den
+  Commitnachichten hinzu.
+\item
+  \texttt{jx\ step\ helm\ release} Veröffentlich das Helmchat aus dem
+  \texttt{charts} Ordner unter einer neuen Version im Chartmuseum.
+\item
+  \texttt{jx\ promote\ -b\ -\/-all-auto\ -\/-timeout\ 1h\ -\/-version\ \textbackslash{}\$(cat\ ../../VERSION)}
+  Modifiziert oder Erstellt die Umgebunskonfigurationen bei denen in
+  Jenkins X \emph{Autodeploy} aktiviert wurde.
+\end{itemize}
+

thesis.tex

@@ -45,6 +45,7 @@
 \input{classicthesis-config}
 \input{begriffe}
 \usepackage{todonotes}
+\usepackage{fancyvrb}
 %\usepackage{cite}
 %*************************************************************************
 % Bibliographies
@@ -122,6 +123,7 @@
 \cleardoublepage
 \part{Appendix}
 \include{chapters/experience}
+%\include{pandoc/doku}
 %\include{chapters/examples/appendix01}
 %\include{chapters/examples/appendix02}
 %*************************************************************************