diff --git a/chapters/problems.tex b/chapters/problems.tex index 2ce791b..65908e1 100644 --- a/chapters/problems.tex +++ b/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} ~ diff --git a/thesis.tex b/thesis.tex index a376083..a11f936 100644 --- a/thesis.tex +++ b/thesis.tex @@ -118,7 +118,7 @@ \cleardoublepage \part{Appendix} \include{chapters/experience} -\include{chapters/examples/appendix01} +%\include{chapters/examples/appendix01} %\include{chapters/examples/appendix02} %************************************************************************* % Other Stuff in the Back