wir sind auf dem weg nach finale
This commit is contained in:
+1
-1
@@ -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}
|
||||
}
|
||||
|
||||
|
||||
+2
-2
@@ -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
|
||||
|
||||
+10
-10
@@ -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}
|
||||
|
||||
~
|
||||
|
||||
|
||||
@@ -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.
|
||||
+477
@@ -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}
|
||||
|
||||
@@ -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}
|
||||
%*************************************************************************
|
||||
|
||||
Reference in New Issue
Block a user