probleme zitiert

chapters/problems.tex

@@ -131,7 +131,7 @@ von Systemstatus, Automatisierung, Speicherverbrauch, Zertifikaten,
 Konfiguration und Architektur.
 
 Die Server müssen angepasst, aufgestockt, beschleunigt und die Balance
-überwacht werden. \cite{shahin2017continuous,plonski_herausforderungen_Leo_2020,article:google}
+überwacht werden. \cite{shahin2017continuous,plonski_herausforderungen_Leo_2020}
 
 ~
 
@@ -153,14 +153,14 @@ 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.
+ein unautorisierter Zugriff auf das Produktionssystem erfolgen könnte.\cite{plonski_herausforderungen_Leo_2020,plonski_herausforderungen_grund_2020}\ref{be:jx}
 
 ~
 
 $\Rightarrow$ Kann zum Scheitern der Systemeinführung führen oder ein Workaround ist
   notwendig
 
-\subsubsection{\textbf{E06} -- Coding-Konvention}
+\subsubsection{\textbf{E06} -- Coding-Konvention\todo{Blödes Problem}}
 
 Unternehmens- oder Projekt-Codingrichtlinien können den Vorgaben des
 gewünschten Tools widersprechen. Ein Workaround ist notwendig.
@@ -185,7 +185,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.
+immer wieder neu starten, um eine Selbstreparatur zu ermöglichen.\ref{be:gitlab} \cite{plonski_herausforderungen_Leo_2020}
 
 ~
 
@@ -196,7 +196,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.
+auf einen fixen Namespace zu.\cite{be:gitlab,plonski_herausforderungen_Leo_2020}
 
 ~
 
@@ -225,7 +225,7 @@ CI/CD Systeme und Plattformen sind in ihrer Anwendung so ausgerichtet,
 dass viele Projekte parallel CI/CD betreiben.
 
 Durch den Ansatz, inkrementell kleinste Codeänderungen sofort zu
-integrieren, wird bei jeder Codeänderung der Build-Prozess durchlaufen.
+integrieren, wird bei jeder Codeänderung der Build-Prozess durchlaufen.\ref{be:jx}
 
 ~
 
@@ -254,7 +254,7 @@ Der Betrieb eines CI / CD 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.
+Software selbst und ihr Containerimage.\cite{plonski_herausforderungen_Leo_2020}
 
 ~
 
@@ -265,9 +265,7 @@ $\Rightarrow$  Manuelles Eingreifen in die Speicherung der Artefakte wird notwen
 Über ein CI/CD System der Telekom wurden entsprechende Probleme
 geschildert: Es entstehen sehr schnell sehr viele Daten und die
 Speichermedien laufen voll, da kontinuierlich bei jeder Änderung alles
-an Artefakten abgelegt wird.
-
-Kollege xxx --
+an Artefakten abgelegt wird. 
 
 \subsubsection{\text{B03} - fehlende Möglichkeit zum kontrolliertem Stopp der
 Pipeline}
@@ -289,7 +287,7 @@ Nutzung des Masterbranch}
 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.
+unbeabsichtigt ausgeliefert.\cite{plonski_herausforderungen_Leo_2020,plonski_herausforderungen_grund_2020,shahin2017continuous}\ref{be:jx}
 
 ~
 
@@ -345,7 +343,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.
+diese Löschung verloren gehen. \cite{plonski_herausforderungen_Leo_2020}
 
 ~
 
@@ -359,7 +357,7 @@ Ordner. Unkenntnis über diese Vorgabe kann dazu führen, dass der Source
 Code in einem anderen Verzeichnis bereitgestellt wird, Das
 Codeanalysetool findet im spezifizierten Verzeichnis keinen Code -
 manche Tools melden einen positiven Status und der CI/CD Prozess läuft
-weiter.
+weiter.\ref{be:jx} \cite{shahin2017continuous}
 
 ~
 
@@ -378,7 +376,7 @@ Zeile des Codes durchlaufen wird, sie dennoch nichts darüber aussagen,
 wie funktionsfähig das Modul oder Gesamtsystem ist.
 
 Der Code passiert den Smoktests mit einer positiven Statusmeldung, aber
-die Funktion des Moduls /Gesamtsystem ist nicht gewährleistet.
+die Funktion des Moduls /Gesamtsystem ist nicht gewährleistet. \cite{connolly,shahin2017continuous} \ref{be:jx}
 
 ~
 
@@ -391,7 +389,7 @@ Datenbankänderungen}
 Häufig geht mit Änderungen im Code auch eine Datenbankmigration einher.
 Das automatisierte Deployment muss in der richtigen Reihenfolge
 ausgeführt werden: Der Codemigration, muss der Systemstopp folgen
-\ldots{} dann sytyotm startxx
+\ldots{} dann sytyotm startxx \cite{connolly,plonski_herausforderungen_Leo_2020,shahin2017continuous}
 
 ~