xx wurde ge x

begriffe.tex

@@ -5,4 +5,5 @@
 \newcommand{\cdl}{\textit{Continuous Deployment} }
 \newcommand{\cd}{\textit{CD} }
 \newcommand{\cdel}{\textit{Continuous Delivery} }
-\newcommand{\cde}{\textit{CDE} }
+\newcommand{\cde}{\textit{CDE} }
+\newcommand{\gitops}{\textit{GitOps} }

chapters/Einleitung.tex

@@ -66,26 +66,13 @@ Planung und technische Maßnahmen verhindern lässt.
 
 \medskip
 \section{Methode}
-Zur Erhebung relevanter Probleme wurden Experteninterviews geführt\todo{ürgent was stimmt noch nicht},
+Zur Erhebung relevanter Probleme wurden Experteninterviews,
 wissenschaftliche Arbeiten, Erfahrungsberichte sowie eigene
 Beobachtungen im \cicd Umfeld herangezogen.
 
 \medskip
 Aus der Problemanalyse wurden die Ursachen identifiziert und
 entsprechende Empfehlungen abgeleitet.
-\section{Vorgehen}
-\medskip
-In einem ersten Schritt betrachte ich den Softwareentwicklungsprozess
-und die Automatisierungsmöglichkeiten im Allgemeinen, um dann Ideexx \todo{Ausschreiben} von
-\cicd aufzuzeigen.
-
-\medskip
-Die Problemrecherche und Analyse kann nicht den Anspruch der
-Vollständigkeit erfüllen. Sie berücksichtigt typische- und häufig
-anzutreffende Probleme. Dabei sind die Empfehlungen unabhängig von einem
-konkreten Anwendungsfall und der Toolsituation formuliert. Probleme zur
-Thematik des mentalen Wandels bei der Einführung von \cicd werden nicht
-betrachtet.
 
 \section{Aufbau}
 \todo{Fix name Ref}
@@ -93,4 +80,13 @@ Im Kapitel \nameref{automatisierung-im-softwareentwicklungsprozess} werden Grund
 
 Diese Grundlagen dienen dem Verständnis der im Anschluss in Kapitel \nameref{heraus} dargestellten Ergebnisse der Erhebung und Analyse von Problemen bei der Einführung und im Betrieb von \cicd. Hierbei wird das in der Einleitung angerissene Problem vertieft und erläutert.
 
-Aus der Problemanalyse werden im Kapitel \nameref{mas} Lösungsansätze und Empfehlungen formuliert und auch eine konkrete Umsetzungsempfehlung für das Eingangsproblem entwickelt.
+Aus der Problemanalyse werden im Kapitel \nameref{mas} Lösungsansätze und Empfehlungen formuliert und auch eine konkrete Umsetzungsempfehlung für das Eingangsproblem entwickelt.
+
+\section{Abgrenzung}
+
+Die Problemrecherche und Analyse kann nicht den Anspruch der
+Vollständigkeit erfüllen. Sie berücksichtigt typische- und häufig
+anzutreffende Probleme. Dabei sind die Empfehlungen unabhängig von einem
+konkreten Anwendungsfall und der Toolsituation formuliert. Probleme zur
+Thematik des mentalen Wandels bei der Einführung von \cicd werden nicht
+betrachtet.

chapters/experience.tex

@@ -1,4 +1,6 @@
 \chapter{Beobachtungen durch Projekte xxx}\label{beobachtung}
 
 \section{CI/CD GitLab xx}\label{be:gitlab}
-\section{CI/CD auf Jenkins X}\label{be:jx}
+\section{CI/CD auf Jenkins X}\label{be:jx}
+\section{CI/CD in PFS}\label{be:pfs}
+\section{CI/CD in A4}\label{be:a4}

chapters/fazit.tex

@@ -34,7 +34,7 @@ dann zu einer konkreten Umsetzungsmöglichkeit führen.
 
 ~
 
-Am Problem xxx -- ssssss \todo{Problem tag hinzugfügen} wurde dieses Vorgehensweise aufgezeigt und die
+Am Problem \ref{B04} \nameref{B04}  wurde dieses Vorgehensweise aufgezeigt und die
 Problemlösung bestätigt.
 
 ~

chapters/grund.tex

@@ -1,6 +1,7 @@
 \hypertarget{automatisierung-im-softwareentwicklungsprozess}{%
 \chapter{Automatisierung im Softwareentwicklungsprozess}
 \label{automatisierung-im-softwareentwicklungsprozess}}
+\todo{Quellen}
 
 Im diesem Kapitel wird ausgehend von den Phasen des
 Softwareentwicklungsprozesses die Funktionsweise von \cicd aufgezeigt.
@@ -147,11 +148,8 @@ GitLab-CI}.
 ~
 
 \subsection*{Continuous Delivery / Continuous Deployment}
-\todo{Mehr zu CDE und CD schreiben}
-Die Abkürzung CD kann sowohl für Continuous Delivery als auch für
-Continuous Deployment stehen und bezeichnen die weitere Automatisierung
-in der Pipeline und stehen für das Ausmaß der Automatisierung.
-\todo{the fuck}
+Die Abkürzung CD kann sowohl für \cdel als auch für
+\cdl stehen. Sie unterscheiden sich im Ausmaß der Automatisierung innerhalb der Pipeline.
 
 \subsection{Continuous Delivery}\label{cde}
 
@@ -161,6 +159,13 @@ nachdem sie zuvor durch \ci integriert, versioniert und archiviert
 abgelegt wurde. Eine automatische Installation in dieser Zielumgebung
 findet nicht statt.
 
+\subsubsection*{Beispiel für eine cloudähnliche Container-Zielumgebung:} 
+In dieser Umgebung können die Container-Images nur von einem lokalen Image-Registry bezogen werden.
+Continuous Delivery spielt die Artefakte eines erfolgreichen Release-CI-Run automatisch in das lokale Image-Registry der Zielumgebung.
+Das Container-Image steht nun bereit, wurde jedoch noch nicht installiert.
+
+ 
+
 \subsection{Continuous Deployment}\label{cd}
 Eine weiterführende Automatisierung stellt das \textbf{\cdl}
 dar. Es erweitert die Funktionalität des \cdel, in dem es
@@ -174,24 +179,22 @@ Codeänderungen innerhalb von wenigen Minuten produktiv werden können.
 
 ~
 
-Das Risiko ist geringer\todo{welches risiko}, weil Änderungen in kleinen Schritten
-durchgeführt werden und bei jedem \textit{CI -- Run} alle Tests wiederholt und am
-Ende in den Betrieb gebracht werden.
-
+Das Risiko für Fehler im Betrieb ist geringer, da Änderungen in kleinen Schritten mit jedem CI/CD Run integriert, getestet werden.
 
 
 \section{Git und die Bedeutung von Branches}
-
-Das Versionmanagementsystem Git basiert auf dem Konzept der Branches,
+\label{grund:git}
+Die \scm Git besitzt im Zusammenhang mit CI/CD die Möglichkeit, die operativen Systeme versioniert zu steuern. Dies wird auch als \textbf{GitOps} bezeichnet und ist eine weit verbreitete CI/CD Methode.
+Git basiert auf dem Konzept von Branches,
 welches verschiedene Codeversionen enthalten kann. Ein Branch ist ein
 Entwicklungszweig, auf dem die Änderungen innerhalb eines
 Projekt-Repository sequenziell fortgeschrieben werden.
 
 ~
-\todo{GitOps noch ürgentwo als kleinen Merker einbaue}
+
 Der Name des Branches ist dafür ausschlaggebend, welcher Pfad in der
 Pipeline durchlaufen wird. Das Branch-Pattern beschreibt die Funktion,
-welche dem Branch zukommt. Je nach Art der Änderung \todo{kleine veränderung}auf einem Branch,
+welche dem Branch zukommt. Wird eine Änderung auf einem Branch,
 wird sie auf die gewünschte Weise vom CI/CD System verwaltet, integriert
 und in den Betrieb gebracht.
 

chapters/mass.tex

@@ -1,7 +1,9 @@
 \chapter{Empfehlungen für die Planung und Implementierung von CI/CD}
 \label{mas}
-Auch wenn ein CI/CD System nach der Einführung als Gesamtkomplex vorliegt, der schnell und einfach den Softwareentwicklungsprozess beschleunigt, ist es unumgänglich, sich bei der Einführung auf die Detailebene des Use Cases als auch der Tools zu begeben. Nur so besteht die Chance, später im Betrieb des Systems die Vorteile von CI/CD nutzen zu können.
-Während der xxx\todo{xx}Admin sehr viel dieses Detailkenntnisse besitzen wird, muss der Softwareentwickler nur das für ihn relevanten Wissen in Form von xx und xx vorliegen haben.
+Auch wenn ein \cicd System nach der Einführung als Gesamtkomplex vorliegt, der schnell und einfach den Softwareentwicklungsprozess beschleunigt, ist es unumgänglich, sich bei der Einführung auf die Detailebene des Use Cases als auch der Tools zu begeben. Nur so besteht die Chance, später im Betrieb des Systems die Vorteile von CI/CD nutzen zu können.
+
+\todo{Aufschlüsseln der Rolle von Automatisierungs teams und Entwickler benzüglich Doku}
+Während das automatisierungs Team eine sehr viel umfangreichere Detailkenntnisse besitzen wird, muss der Softwareentwickler nur das für ihn relevanten Wissen in Form von Dokumentation vorliegen haben.
 
 Im Folgenden werden Empfehlungen aufgezeigt, welche das Auftreten der
 oben geschilderten Probleme verhindern können.
@@ -11,6 +13,7 @@ eines CI/CD Systems, die Dokumentation und auch konkrete technische
 Maßnahmen.
 
 \section{Planung eines CI/CD Systems}
+\label{mas:m1}
 
 Die Einführung eines CI/CD Systems beinhaltet nicht nur eine einfache
 Automatisierung bestehender Prozesse, es handelt sich um eine komplexe
@@ -38,7 +41,7 @@ Typische Prozesse hierfür sind der
 \end{description}
 
 Die detaillierte Definition der \textbf{Inputschnittstelle} für das
-CI/CD System (z.B. xxxx ) muss ebenfalls erstellt werden. Dazu gehört
+\cicd System (z.B. Webhooks oder Dateiformate ) muss ebenfalls erstellt werden. Dazu gehört
 das Format, die Art, der Ort (Übergabeordner oder Repository) und der
 Kontext (z.B. Release-Erstellung oder Snapshot-Version) unter dem das
 CI/CD System aufgerufen wird.
@@ -112,7 +115,7 @@ Nach der Toolentscheidung erfolgt die Detailplanung des Designs für die
 getroffene Toolauswahl.
 
 Hierzu gehört das Design der Toolintegration, die Migration, aber auch
-das Design von möglichen technischen Maßnahmen wie in 4./3xx
+das Design von möglichen technischen Maßnahmen wie in \ref{mas:m3}
 dargestellt.
 
 \subsection{Festlegung der Hardware für das CI/CD System}\label{mas:m1.4}
@@ -141,8 +144,7 @@ aus dem Unternehmens- und Projektumfeld.
 Ein CI/CD System wird zum zentralen Element des
 Softwareentwicklungsprozesses. Die starke Integration und Komplexität
 erfordert eine umfangreiche Dokumentation für Entwickler, als auch für
-das Integrations-(xxx oben definieren) und Automatisierungsteam(xxxoben
-definiern).
+das Automatisierungsteam.
 
 Die Dokumentation stellt für den Entwickler Informationen bereit, welche
 ihm Kenntnisse zu den In- und Output-Schnittstellen vermittelt. Er muss
@@ -150,15 +152,12 @@ für sein individuelles Projekt Information darüber haben, wie und welche
 Schritte durchlaufen werden und wie die Inputschnittstellen diesen
 Ablauf durch die Pipeline beeinflussen können.
 
-Das Automatisierungsteam benötigt Informationen über den CI/CD Engine,
-(xxx bei der automatisierung -- vielleicht auch tools und ) eingesetzte
-Tools und deren Interfaces und über die Konfiguration des aktuellen
-Systems, um den Betrieb und die Wartung für das Automatisierungsteam zu
-ermöglichen.
+Das Automatisierungsteam benötigt Informationen über sowohl die CI/CD Engine, eingesetzte
+Tools und deren Interfaces als auch die aktuelle Konfiguration der Systeme.
 
 Bei Störungen im CI/CD System kann diese Dokumentation helfen, das
 System wiederherzustellen bzw. sogar extern als Workaround zu betreiben
-(durch Verfassung der einzelnen CI/CD Schritte in Einzelscripten).
+(durch verwenden Skripten zum Aufruf der einzelnen CI/CD Schritte).
 
 \section{technische Maßnahmen}\label{mas:m3}
 
@@ -168,23 +167,20 @@ Bei der Einführung eines CI/CD System können mit Hilfe von technischen
 Maßnahmen einige Probleme vermieden werden, welche durch Unkenntnis der
 Entwickler über die Funktionsweise des Systems verursacht werden.
 Zusätzlich können technische Maßnahmen auch für die Einhaltung von
-Policies genutzt werden.
+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
 passende Einstellungen vorgenommen werden, welche gewährleisten, dass
 nur getestete Softwareversionen in die Produktion übertragen werden.
-\emph{(\ref{B06} B06 -- unzureichende Tests -- ungetesteter Code in Produktion)}
+\emph{(\ref{B06} \nameref{B06})}
 
 Weitere Beispiele sind die Verhinderung einer ungewollten Ausführung
 eines Releases \emph{(\ref{B04} B04 -- ungewolltes Aktivieren der Pipeline durch
 unbewusste Nutzung des Masterbranch),} deren Umsetzung im
 Anschlusskapitel an einer konkreten Systemumgebung aufgezeigt wird.
 
-Die ungewollte Ausführung eines unorchestrierten Containers ist ein
-Problem, welches ebenfalls durch technische Maßnahmen vermieden werden
-kann.(einbisschen andeuten wieexxx)
 
 Auch im \textbf{Speichermanagement} gibt es Möglichkeiten, den \emph{in
 (\ref{B02} B02 - erschöpfte Speicherkapazität des CI/CD System)} beschriebenen
@@ -203,10 +199,6 @@ Komponente dieser Maßnahme wäre die Dokumentation und
 Ausführungsbestätigung dieser Schritte, welche als Voraussetzung für die
 Fortsetzung des spezifischen Entwicklungsprozesses implementiert wird.
 
-So können auch \textbf{Konflikte}, welche durch eine \textbf{parallele
-Ausführung} zweier Pipelines entstehen, mit Hilfe von technischen
-Vorkehrungen erkannt werden und zum Stopp der Pipeline führen. (andeuten
-wie xx)
 
 \subsection{Beispiel für die Umsetzung von Maßnahmen zur Vermeidung
 von B04 -- ungewolltes Aktivieren der Pipeline durch unbewusste Nutzung

chapters/problems.tex

@@ -11,17 +11,17 @@ reibungslos. Im Folgenden werden häufig anzutreffende Probleme
 skizziert, welche zum Teil typisch und häufig im Umfeld von CI/CD sind,
 oder durch die starke Integration besonders zum Tragen kommen. Die
 Problembeschreibungen basieren auf Experteninterviews,
-Literaturrecherchen und Beobachtungen an/inxx \todo{xx} verschiedenen
+Literaturrecherchen und Beobachtungen bei verschiedenen
 Praxisprojekten.
 
-Die Interviews wurden mit Softwareentwicklern unter CI/CD sowie
+Die Interviews wurden mit Softwareentwicklern sowie
 Automatisierungs- und Integrationsexperten geführt. (CI/CD Systeme für
-VM-Images (xxx\todo{xx})und Microservices in einer Vielzahl komplexer
-Zielumgebungen) (xxx genauer beschreiben???)\todo{genau... genauer beschreiben}
+VM-Images und Microservices in einer Vielzahl komplexer
+Zielumgebungen) \ref{be:pfs} \ref{be:a4}
 
 Meine Praxiserfahrungen basieren auf der Einführung eines CI/CD Systems
 unter GitLab-CI sowie dem Aufbau einer Serverless - CI/CD Plattform
-unter Jenkins X auf Kubernetes.
+unter Jenkins X auf Kubernetes. \ref{be:gitlab} \ref{be:jx}
 
 Eine weitere Quelle sind Fachartikel, Paper und Erfahrungsberichte zu
 verschiedenen CI/CD Systemen in ihrer Anwendung.
@@ -54,7 +54,7 @@ dem automatisierten System (\textit{Build-Server}) das CI/CD System.
 
 In diesem Zusammenhang wird der Use Case definiert als eine konkrete
 Anwendung eines CI/CD Systems für ein Softwareentwicklungsprojekt mit
-allen Anforderungen des Projektes. (beispiel einfügenXxxx und xxxx\todo{xx}
+allen Anforderungen des Projektes. (siehe \ref{mas:m1} \nameref{mas:m1})
 
 \subsection[aufgrund nicht ausreichender Planungstiefe]{Probleme aufgrund nicht ausreichender Planungstiefe}
 
@@ -173,7 +173,8 @@ $\Rightarrow$ Kann zum Scheitern der Systemeinführung führen oder ein Workarou
 
 
 \subsubsection{\textbf{E07} -- Nicht übereinstimmende Portvorgaben zwischen der
-Anwendungssoftware und dem Tool}\label{E07}
+Anwendungssoftware und dem Tool}
+\label{E07}
 
 Der Portmissmatch ist ein typisches Problem bei All-in-One Lösungen. Das
 CI/CD System geht davon aus, dass die Software ihren Service über einen
@@ -181,7 +182,7 @@ spezifischen Port zu Verfügung stellen kann (z.B. Port 3000). Die zu
 migrierende Software nutzt einen anderen Port oder vielleicht überhaupt
 keinen Port, wenn sie z.B. einen Message-Bus anwendet.
 
-Darüber hinaus könnte das CI/CD System das operativexx System, z.B.
+Darüber hinaus könnte das CI/CD System das operative Zielsystem, z.B.
 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
@@ -234,24 +235,22 @@ $\Rightarrow$ Dieses Vorgehen kann zu einer hohen Belastung der CPU führen, den
   Parallelbetrieb mit anderen Projekten kann es zu enormen Laufzeiten
   beim Build-Prozess kommen.
 
-Ein Beispiel dieser Problematik unter der Nutzung von Quarkus ist in
-x(xxx intenetquelle)
+Ein Beispiel dieser Problematik unter der Nutzung von Quarkus ist in einer meiner Projekte aufgetreten (\ref{be:jx}). \todo{check me}
 
-xx zu finden:
 
 Quarkus ist ein neues für Webentwicklung geeignetes Java Framework (APIs
 und Microservices) und verspricht ein „Native Compiling`` von Java Code.
-Mit diesem Framework können also sehr performante Aps mit einem
+Mit diesem Framework können also sehr performante APIs mit einem
 minimalen Bedarf an RAM erstellt werden.
 
 Ein Build-Prozess unter Quarkus ist entsprechend aufwendig. Auf einem
 Entwicklungs-PC lasst sich ein Build-Prozess in etwa 5 bis 10 Minuten
 abbilden, während er auf einem CI/CD System mit einer etwas älteren
-Hardware bis zu eineinhalb Stunden dauern kann
+Hardware bis zu eineinhalb Stunden dauern kann. 
 
 \subsubsection{\textbf{B02} erschöpfte Speicherkapazität des CI/CD System}\label{B02}
 
-Der Betrieb eines CI / CD Systems kann auch in Bezug auf Speicherplatz
+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
@@ -292,24 +291,21 @@ unbeabsichtigt ausgeliefert.\cite{plonski_herausforderungen_Leo_2020,plonski_her
 
 ~
 
-$\Rightarrow$  xxxIm Falle von Konflkten geht code verlorenxx.
-  Nicht gewünschter Code befindet sich in Produktion
+$\Rightarrow$  Nicht gewünschter Code befindet sich in Produktion.
 
-\begin{quote}
-\url{https://code.i-harness.com/de/q/6d10a0}
-\end{quote}
+\todo{QUELLE}
 
 Dieses Problem wurde bereits in der Einleitung angerissen. Um hier eine
 konkrete Lösungsmöglichkeit zu erarbeiten, erfolgt eine weitere Analyse
 innerhalb einer konkreten Systemumgebung.
 
 Das versehentliche Arbeiten auf dem Masterbranch ist zunächst ein
-typisches Problem im GitObs (xx) Umfeld. In einem CI/CD Umfeld hat es
+typisches Problem im Git und GitOps (\ref{grund:git}) Umfeld. In einem CI/CD Umfeld hat es
 noch viel weitreichendere Folgen, denn durch die durchgängige
 Automatisierung besteht das Problem nicht nur aus der ungewollten
 Branchüberschreibung -- es weitet sich bis in die Produktion aus.
 
-Hierzu die Darstellung dieses Falls am einem Beispiel unter Gitobs(xx):
+Hierzu die Darstellung dieses Falls am einem Beispiel unter \gitops (\ref{grund:git}):
 Mit Hilfe des Versionsmanagementsystem Git besteht die Möglichkeit, dass
 jeder Entwickler in seinem eigenen „Featurebranch`` an seinem Code
 weiterentwickelt. Dieser Code wird später im Masterbranch
@@ -365,18 +361,15 @@ weiter.\ref{be:jx} \cite{shahin2017continuous}
 $\Rightarrow$  Ungetesteter Code befindet sich in Produktion
 
 
-\subsubsection{\textbf{B07} -- Modultest nur auf Codeabdeckung ausgelegt}\label{B07}
+\subsubsection{\textbf{B07} -- Modultest nur auf Codeabdeckung ausgelegt}
+\label{B07}
 
-Unkenntnis über Test/ und Tool (Automatisierungs- und
-Produktionsrelevanz) Tests durchlaufen alle Codezeilen, ohne die
-Funktion zu testen -- Smoketestsxx erklären
-
-Werden Tests nicht tief genug in Bezug auf die Funktionalität
+Werden Modultests nicht tief genug in Bezug auf die Funktionalität
 formuliert, kann es zwar sein, dass sie so verfasst sind, dass jede
 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
+Der Code passiert die Tests mit einer positiven Statusmeldung, aber
 die Funktion des Moduls /Gesamtsystem ist nicht gewährleistet. \cite{connolly,shahin2017continuous} \ref{be:jx}
 
 ~
@@ -388,9 +381,9 @@ $\Rightarrow$  Funktional ungetesteter Code befindet sich in Produktion
 Datenbankänderungen} \label{B08}
 
 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 \cite{connolly,plonski_herausforderungen_Leo_2020,shahin2017continuous}
+Diese Datenbankmigration muss ebenfalls durch \cicd automatisierte werden.
+Treten während der Migration probleme auf, so müssen diese ebenfalls durch das \cicd System abgefangen werden und entsprechende Maßnamen durchgefürt werden.
+Sind diese Fallbacks nicht definiert, so entstehen unvorhergesehende Folgeprobleme. \cite{connolly,plonski_herausforderungen_Leo_2020,shahin2017continuous}
 
 ~