tada

chapters/Automatisierung.tex

@@ -5,7 +5,7 @@ Um eine größtmögliche Vielzahl verschiedener Modelle abzudecken, abstrahiere
 
 \section{Darstellung des Software-Entwicklungsprozesses}
 \label{sec:auto:show}
-Bei der Herleitung dieser generischen Sichtweise auf den Software-Entwicklungsprozess habe auf Elemente des Wasserfallmodell aus der Publikation von Royce, Winston W: \textit{\citetitle{royce1987managing}} zurückgegriffen. Auch wenn er selbst dieses Modell als ``riskant und fehlerbehaftet''\cite{royce1987managing} beschreibt und heute andere Methoden sich etabliert haben.
+Bei der Herleitung dieser generischen Sichtweise auf den Software-Entwicklungsprozess habe auf Elemente des Wasserfallmodell aus der Publikation von Royce, Winston W: \textit{\citetitle{royce1987managing}}\cite{royce1987managing} zurückgegriffen. Auch wenn er selbst dieses Modell als \\ \textcite{``riskant und fehlerbehaftet''} beschreibt und heute andere Methoden sich etabliert haben.
 Dabei konzentriere ich mich nur auf die Phasen dieses Modells, unabhängig von der Anordnung, Iteration, ihrem Kontext oder Umfang und auch der Philosophie der jeweiligen Methode. Diese einzelnen Schritte lassen sich in ähnlicher Form in vielen anderen Methoden wiederfinden.
 
 \subsection*{Projektphasen}
@@ -32,21 +32,21 @@ Die Projektphasen des Wasserfallmodells werden in Anforderungsanalyse, Systemdes
 \label{sec:auto:auto}
 Es gibt verschiedene weit verbreitete Automatisierungspraktiken. Dazu gehören\cite{bobrovskis2018survey}:
 \begin{itemize}
-    \item CI (Continuous Integration)
-    \item CDE (Continuous Delivery)
-    \item CD (Continuous Deployment)
+    \item CI (\textit{Continuous Integration})
+    \item CDE (\textit{Continuous Delivery})
+    \item CD (\textit{Continuous Deployment})
 \end{itemize}
-Die Idee bei Continuous Integration besteht darin, wiederholt (mehrmals täglich) die Software in einer kontrollierten definierten Umgebung automatisiert zu integrieren und zu testen (automated build). Die Tests können den Modul- Integration- und auch den Abnahmetest umfassen.
+Die Idee bei \textit{Continuous Integration} besteht darin, wiederholt (mehrmals täglich) die Software in einer kontrollierten definierten Umgebung automatisiert zu integrieren und zu testen (automated build). Die Tests können den Modul- Integration- und auch den Abnahmetest umfassen.
 Durch diese Verfahren können Fehler durch Codeänderungen automatisch erkannt werden, die sonst durch aufwendige, manuelle Testverfahren oder sogar erst im Betrieb erkannt worden wären.
 Je nach Umfang kann CI das ganze Volumen von Testszenarien abwickeln und so die Testphase voll automatisiert abdecken.\\
 
 \medskip
 
-Bei dem Continuous Delivery geht es darum, eine neu entwickelte Softwareversion zur Auslieferung bereitzustellen. Die Installation und der Betrieb der Software erfolgt jedoch manuell.\\
+Bei dem \textit{Continuous Delivery} geht es darum, eine neu entwickelte Softwareversion zur Auslieferung bereitzustellen. Die Installation und der Betrieb der Software erfolgt jedoch manuell.\\
 
 \medskip
-Continuous Deployment erweitert das Continuous Delivery um die automatische Installation und Konfiguration auf dem Zielsystem.
-Mit Continuous Deployment werden Komponenten aus der Phase „Betrieb“ automatisiert und das Fehlerrisiko bei der Installation verringert. \\
+\textit{Continuous Deployment} erweitert das \textit{Continuous Delivery} um die automatische Installation und Konfiguration auf dem Zielsystem.
+Mit \textit{Continuous Deploymen}t werden Komponenten aus der Phase „Betrieb“ automatisiert und das Fehlerrisiko bei der Installation verringert. \\
 
 \bigskip
 Diese Grundprinzipien können erweitert werden: so lassen sich z.B. mit Hilfe von statischer Codeanalyse automatisiert Fehler oder Sicherheitsprobleme erkennen (CI). 

chapters/Gliederung.tex

@@ -1,19 +1,9 @@
 
-\chapter{Vorteile/Nachteile von Automatisierung im Entwicklungszyklus}
-\section{Vorteile}
-Vorteile von Automatisierung in der Entwicklung
-  \subsection{Hier Kategorien einsetzen (WIP)}
-  Analyse und Ableitung einer universellen Pipeline für jede Kategorie
-\section{Nachteile}
-Das Gegenteil
-  \subsection{Hier Kategorien einsetzen (WIP)}
-  Analyse und Ableitung einer universellen Pipeline für jede Kategorie
-
 \chapter{Qualitätsmerkmale einer CI/CD Pipeline}
 \dots
 
-\chapter{Implementierung einer CI/CD Pipeline nach diesen Anforderungen}
-Architektur einer CI/CD Pipeline nach diesen Qualitätsmerkmalen an einem Beispiel.
+%\chapter{Implementierung einer CI/CD Pipeline nach diesen Anforderungen}
+%Architektur einer CI/CD Pipeline nach diesen Qualitätsmerkmalen an einem Beispiel.
 
 \chapter{Fazit}
 Schwer weitgreifende Merkmale zu finden, dennoch \dots

chapters/VorNach.tex

@@ -0,0 +1,86 @@
+
+\chapter{Vorteile/Nachteile von Automatisierung im Entwicklungszyklus}
+Dieses Kapitel ist momentan nur eine Ansammlung von einzelnen Vorteilen und Problemen die durch CI/CD auftreten können.
+Die Ansammlung ist noch nicht vollendet, jedoch kann man schon erahnen in welche Richtung die Qualitätsmaßnahmen sich entwickeln.
+\dots Mit der Rechtschreibung in diesem Kapitel hab ich es auch nicht so ernst genommen. 
+\section{Vorteile}
+\begin{verse}
+The 2019 Accelerate State of DevOps report, for which Dora surveyed 3,000 developers, found that, comparing the elite group to poor performers, the former achieved 208 times more frequent code deployments, 106 times faster lead time from committing code to deployment and 2,604 times faster to recover from incidents. 
+https://www.computerweekly.com/feature/Deliver-quality-software-at-speed-with-CI-CD
+
+With CI/CD you get cloud-native things like optimisation, scalability and elasticity, and performance. 
+CI/CD ermöglicht auto cloud deployment.
+https://www.computerweekly.com/feature/Deliver-quality-software-at-speed-with-CI-CD
+
+**Documentation** with Markdown is wonderful.:
+The source is stored alongside the code, and all the DevOps best practices apply. Developers are more invested in documentation because they know what to do with a pull request (versus reviewing and editing in some alien documentation tool). Finally, this encourages teams to write docs at the same time as the source code.
+https://www.cloudbees.com/blog/silos-begone-road-devops-autodesk-and-lessons-learned-along-way
+
+\end{verse}
+
+\section{Nachteile}
+\begin{verse}
+    
+**Lack of experience and skill**:
+Source: Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices
+
+**Unexpected Deployment**
+Ausversehen auf master gepushed.
+Source: Manuel + A4
+
+**Infrastructure**
+Make sure you invest in the underlying infrastructure, the correct tooling.
+https://www.computerweekly.com/feature/Deliver-quality-software-at-speed-with-CI-CD
++ Manuel
+
+**Storage**:
+Durch Automation fallen viele Artefakte an. Werden diese nicht gemanaged wird auch viel Speicher anfallen.
+Source: A4
+
+**Big Red Button**:
+Es sollte einen Stop knopf geben.
+Source: Manuel + A4
+
+
+**DB Migration**:
+Schema Migration können beim deployment in ein envirgoment auftreten. Race condition bei vielen daten.
+https://dzone.com/articles/a-year-of-continuous-deployment-lessons-learned
+
+**POOR Test Coverare TEST**: 
+Durch Falsche Test Coverage Tests die letztendlich nur Smoketests waren, sah es so aus als ob die Tests gut gelaufen sind.
+https://dzone.com/articles/a-year-of-continuous-deployment-lessons-learned
+
+**Missing Documentation**
+“The mistake a lot of people make is they think it is all about building quickly and delivering fast, but they forget to document properly, so nobody knows what they have actually done,” she says.
+“It takes time at the beginning to automate things and write scripts. But once you’ve got that right, you can repeat it as many times as you want,” she says. 
+https://www.computerweekly.com/feature/Deliver-quality-software-at-speed-with-CI-CD
+
+**Speed**(Mental)
+“Teams that go too fast before they are ready just break things faster, and they don't get fixed. It's definitely about going as fast as you can, but no faster. That's the biggest lesson I've learned,” he says.  https://www.computerweekly.com/feature/Deliver-quality-software-at-speed-with-CI-CD
+
+**Dependencymanagement was hard**. Their siloed history meant teams had their own copies of shared binaries, and in some cases had modified the source locally. Finding owners for shared components, and unifying the source code and binaries back into a single GH repo and Artifactory folder continues to be a challenge.
+https://www.cloudbees.com/blog/silos-begone-road-devops-autodesk-and-lessons-learned-along-way
+
+
+**Perspective Shift**
+Schwer die Leute einzuarbeiten. Lieber dinge benutzen mit denen schon gearbeitet wird.
+Source: Awesome Paper\cite{shahin2017continuous}
+
+
+
+**BIG BANG trotz CI**
+Haltet die env so gleich wie in Prod.
+Source: Präsi ... muss link noch finden.
+
+**Desaster Recovery CI/CD System**
+https://www.ideas-engineering.io/blog/2018/07/disaster-recovery-day
+
+\end{verse}
+\section{Reconmendations}
+
+**Separation of services**
+It is critical that you break apart your monolithic app into separate services such that they are isolated and abstracted from each other. 
+https://www.computerweekly.com/feature/Deliver-quality-software-at-speed-with-CI-CD
+
+**DO CI GOOD**
+Before you get to CD, make sure you do CI well. There are some foundational elements such as having consistent tooling, libraries and operating system configurations.  

thesis.tex

@@ -102,6 +102,7 @@
 
 \cleardoublepage
 \part{Work in Progress}\label{pt:wip}
+\include{chapters/VorNach}
 %\part{Gliederung}\label{pt:thesis}
 \include{chapters/Gliederung}
 %\include{chapters/examples/chapter02}