manuel/Seminararbeit_2020
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

wir sind auf dem weg nach finale

Browse Source
This commit is contained in:
Manuel Plonski
2020-03-20 20:28:59 +01:00
parent 1718a31ec5
commit 818bc06dfe
6 changed files with 725 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
chapters/problems.tex
View File

@@ -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}
~