From 2b1e2ca235c83d69eb1e9d44e81244755709589b Mon Sep 17 00:00:00 2001 From: Manuel Plonski Date: Fri, 20 Mar 2020 16:49:40 +0100 Subject: [PATCH] welche --- bibliography.bib | 32 ++++++++++++++++++++++++++++++-- chapters/Automatisierung.tex | 4 ++-- chapters/Einleitung.tex | 6 +++--- chapters/grund.tex | 5 +++-- chapters/problems.tex | 19 ++++++++++++++----- frontbackmatter/Acronyms.tex | 20 ++++++++++---------- frontbackmatter/Bibliography.tex | 2 +- pandoc/problems-temlp.tex | 2 +- thesis.tex | 12 +++++------- 9 files changed, 69 insertions(+), 33 deletions(-) diff --git a/bibliography.bib b/bibliography.bib index 222d306..98c13ac 100644 --- a/bibliography.bib +++ b/bibliography.bib @@ -99,7 +99,8 @@ author = {Nobach, Leonhard}, collaborator = {Plonski, Manuel}, month = march, - year = {2020} + year = {2020}, + note = "Interview mit Fachexperten" } @misc{plonski_herausforderungen_Leo_2020, @@ -107,5 +108,32 @@ author = {Grund, Norbert}, collaborator = {Plonski, Manuel}, month = march, - year = {2020} + year = {2020}, + note = "Interview mit Fachexperten" + +} + +@misc{ws19, + title = {Skript der Vorlesung ``Software Engineering'' im Wintersemester 19/20}, + author = {Prof. Dr. U. Andelfinger, Prof. Dr. R. Hahn, Prof. Dr. S. Ruehl}, + year = {2019-2020} +} + + +@misc{redhat, + title = {Was versteht man unter {CI}/{CD}?}, + url = {https://www.redhat.com/de/topics/devops/what-is-ci-cd}, + abstract = {CI/CD (Continuous Integration / Continuous Delivery) sorgt für eine kontinuierliche Automatisierung und Überwachung über alle Phasen des App-Lifecycles hinweg.}, + language = {de}, + urldate = {2020-03-20} +} + +@misc{info_aktu, + title = {Von {Continuous} {Integration} zu {Continuous} {Delivery} mit {Jenkins}}, + url = {https://www.informatik-aktuell.de/entwicklung/methoden/von-continuous-integration-zu-continuous-delivery-mit-jenkins-workflow.html, https://www.informatik-aktuell.de/entwicklung/methoden/von-continuous-integration-zu-continuous-delivery-mit-jenkins-workflow.html}, + abstract = {Wie Entwicklungsteams von Continuous Integration (CI) zu Continuous Delivery (CD) gelangen können, indem sie die Workflow-Funktionalität in Jenkins nutzen.}, + language = {de}, + urldate = {2020-03-20}, + journal = {Informatik Aktuell}, + author = {Cygan, Bernhard } } \ No newline at end of file diff --git a/chapters/Automatisierung.tex b/chapters/Automatisierung.tex index 62cc792..2734967 100644 --- a/chapters/Automatisierung.tex +++ b/chapters/Automatisierung.tex @@ -16,7 +16,7 @@ Die Projektphasen des Wasserfallmodells werden in Anforderungsanalyse, Systemdes In diese Phase geht es darum, Anforderungen zu sammeln und zu analysieren. Dies geschieht in Form von Texten oder Modellen, die der Strukturierung und Klassifizierung dienen. \item[Systemdesign] - Hier wird die Architektur der Module, Schnittstellen und Daten festgelegt, die der Spezifikation aus der Anforderungsanalyse genügen sollen. + Hier wird die Architektur der Module, Schnittstellen und Daten festgelegt, welche der Spezifikation aus der Anforderungsanalyse genügen sollen. \item[Implementierung] Die Programmierung mit dem dazugehörige Modultest sind Bestandteil der Entwicklungsphase der Implementierung. @@ -37,7 +37,7 @@ Es gibt verschiedene weit verbreitete Automatisierungspraktiken. Dazu gehören\c \item CD (\textit{Continuous Deployment}) \end{itemize} 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. +Durch diese Verfahren können Fehler durch Codeänderungen automatisch erkannt werden, welche 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 diff --git a/chapters/Einleitung.tex b/chapters/Einleitung.tex index ad53d1d..61adbb9 100644 --- a/chapters/Einleitung.tex +++ b/chapters/Einleitung.tex @@ -76,11 +76,11 @@ entsprechende Empfehlungen abgeleitet. \section{Aufbau} \todo{Fix name Ref} -Im Kapitel \nameref{automatisierung-im-softwareentwicklungsprozess} werden Grundlagen für die Phasen der Softwareentwicklung und deren Automatisierung unter CI/CD aufgezeigt, welche um eine Darstellung über das Branchkonzept unter Git ergänzt wird. +Im Kapitel \ref{automatisierung-im-softwareentwicklungsprozess} werden Grundlagen für die Phasen der Softwareentwicklung und deren Automatisierung unter CI/CD aufgezeigt, welche um eine Darstellung über das Branchkonzept unter Git ergänzt wird. -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. +Diese Grundlagen dienen dem Verständnis der im Anschluss in Kapitel \ref{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 \ref{mas} Lösungsansätze und Empfehlungen formuliert und auch eine konkrete Umsetzungsempfehlung für das Eingangsproblem entwickelt. \section{Abgrenzung} diff --git a/chapters/grund.tex b/chapters/grund.tex index b0d2b59..aa322c2 100644 --- a/chapters/grund.tex +++ b/chapters/grund.tex @@ -82,7 +82,7 @@ In Theorie und Praxis gibt es eine Vielzahl von Definitionen zu \cicd. Es gibt Funktionalitäten, welche dem \cil zugeschrieben werden und an anderer Stelle in einer Darstellung von \cicd dem \cdel zu geordnet wird. Zusätzlich wird häufig bei der Nennung der Abkürzung \cd -nicht deutlich, ob \cdel oder \cdl gemeint ist. +nicht deutlich, ob \cdel oder \cdl gemeint ist.\cite{ws19,redhat,info_aktu} ~ @@ -91,6 +91,7 @@ automatisierten und überwachten Prozesses in einer Pipeline durchgeführt werden, unabhängig von der Zuordnung zu einem Oberbegriff. ~ + \subsection{Continuous Integration}\label{ci} \textbf{„CI``} (\textbf{Continuous Integration}) bezeichnet eine entwicklerorientierte Methode, bei der Code durchgängig integriert und getestet wird. @@ -184,7 +185,7 @@ Das Risiko für Fehler im Betrieb ist geringer, da Änderungen in kleinen Schrit \section{Git und die Bedeutung von 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. +Die \scm Git besitzt im Zusammenhang mit CI/CD die Möglichkeit 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 diff --git a/chapters/problems.tex b/chapters/problems.tex index fdb6dae..708ae0d 100644 --- a/chapters/problems.tex +++ b/chapters/problems.tex @@ -6,6 +6,8 @@ die einfache Automatisierung bestehender Prozesse. Sie birgt tiefgreifende Änderungen für die Softwareentwicklung im Prozess als auch im mentalen Wandel bezüglich Methode und Tools. +~ + So läuft die Einführung und der Betrieb eines CI/CD Systems nicht immer reibungslos. Im Folgenden werden häufig anzutreffende Probleme skizziert, welche zum Teil typisch und häufig im Umfeld von CI/CD sind, @@ -14,18 +16,26 @@ Problembeschreibungen basieren auf Experteninterviews, Literaturrecherchen und Beobachtungen bei verschiedenen Praxisprojekten. +~ + Die Interviews wurden mit Softwareentwicklern sowie Automatisierungs- und Integrationsexperten geführt. (CI/CD Systeme für 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. \ref{be:gitlab} \ref{be:jx} +~ + Eine weitere Quelle sind Fachartikel, Paper und Erfahrungsberichte zu verschiedenen CI/CD Systemen in ihrer Anwendung. +~ + Die Probleme wurden erfasst und in Hinblick auf den Zeitpunkt, zu dem das Problem sichtbar wird (Einführung oder Betrieb), Problemdarstellung, Ursache und Folge analysiert. Neben dem Zeitpunkt der Problemerscheinung @@ -161,17 +171,16 @@ ein unautorisierter Zugriff auf das Produktionssystem erfolgen könnte.\cite{plo $\Rightarrow$ Kann zum Scheitern der Systemeinführung führen oder ein Workaround ist notwendig -\subsubsection{\textbf{E06} -- Coding-Konvention\todo{Blödes Problem}}\label{E06} +\subsubsection{\textbf{E06} -- Coding-Konvention}\label{E06} -Unternehmens- oder Projekt-Codingrichtlinien können den Vorgaben des -gewünschten Tools widersprechen. Ein Workaround ist notwendig. +Unternehmens- oder Projekt Coding Conventions können den Vorgaben des +gewünschten Tools widersprechen. Ein Workaround ist notwendig. \cite{plonski_herausforderungen_Leo_2020} ~ $\Rightarrow$ Kann zum Scheitern der Systemeinführung führen oder ein Workaround ist notwendig - \subsubsection{\textbf{E07} -- Nicht übereinstimmende Portvorgaben zwischen der Anwendungssoftware und dem Tool} \label{E07} @@ -331,7 +340,7 @@ Pipeline von Relevanz. Würde der Entwickler noch während der Ausführung der Releasepipeline die Situation erkennen -- wäre dieser „Notstopp`` eine Möglichkeit, das Deployment noch zu verhindern. -(siehe B03 - fehlende Möglichkeit zum kontrolliertem Stopp der Pipeline) +(siehe \ref{B03} \nameref{B03}) \subsubsection{\textbf{B05} -- unbewusste Einbindung von Software, welche durch Löschungsroutinen nicht permanent zur Verfügung steht} \label{B05} diff --git a/frontbackmatter/Acronyms.tex b/frontbackmatter/Acronyms.tex index dbfff42..8655e6c 100644 --- a/frontbackmatter/Acronyms.tex +++ b/frontbackmatter/Acronyms.tex @@ -3,17 +3,17 @@ %******************************************************* \automark[section]{chapter} \renewcommand{\chaptermark}[1]{\markboth{\spacedlowsmallcaps{#1}}{\spacedlowsmallcaps{#1}}} -\renewcommand{\sectionmark}[1]{\markright{\thesection\enspace\spacedlowsmallcaps{#1}}} -\refstepcounter{dummy} -\pdfbookmark[1]{Abk\"{u}rzungsverzeichnis}{abk\"{u}rzungsverzeichnis} -\markboth{\spacedlowsmallcaps{Abk\"{u}rzungsverzeichnis}}{\spacedlowsmallcaps{Abk\"{u}rzungsverzeichnis}} -\chapter*{Abk\"{u}rzungsverzeichnis} +%\renewcommand{\sectionmark}[1]{\markright{\thesection\enspace\spacedlowsmallcaps{#1}}} +%\refstepcounter{dummy} +%\pdfbookmark[1]{Abk\"{u}rzungsverzeichnis}{abk\"{u}rzungsverzeichnis} +%\markboth{\spacedlowsmallcaps{Abk\"{u}rzungsverzeichnis}}{\spacedlowsmallcaps{Abk\"{u}rzungsverzeichnis}} +%\chapter*{Abk\"{u}rzungsverzeichnis} % Insert your acronyms here -\begin{acronym}[UML] - \acro{DRY}{Don't Repeat Yourself} - \acro{API}{Application Programming Interface} - \acro{UML}{Unified Modeling Language} -\end{acronym} +%\begin{acronym}[UML] +% \acro{DRY}{Don't Repeat Yourself} +% \acro{API}{Application Programming Interface} +% \acro{UML}{Unified Modeling Language} +%\end{acronym} \cleardoublepage diff --git a/frontbackmatter/Bibliography.tex b/frontbackmatter/Bibliography.tex index 7252cf4..91f9bd4 100644 --- a/frontbackmatter/Bibliography.tex +++ b/frontbackmatter/Bibliography.tex @@ -12,5 +12,5 @@ \addcontentsline{toc}{chapter}{\tocEntry{#1}}% \chapter*{#1}% } -\nocite{*} +%\nocite{*} \printbibliography[heading=bibintoc] diff --git a/pandoc/problems-temlp.tex b/pandoc/problems-temlp.tex index 76e9c9f..0e15ad5 100644 --- a/pandoc/problems-temlp.tex +++ b/pandoc/problems-temlp.tex @@ -344,7 +344,7 @@ Pipeline von Relevanz. Würde der Entwickler noch während der Ausführung der Releasepipeline die Situation erkennen -- wäre dieser „Notstopp`` eine Möglichkeit, das Deployment noch zu verhindern. -(siehe B03 - fehlende Möglichkeit zum kontrolliertem Stopp der Pipeline) +(siehe \ref{B03} \nameref{B03}) \textbf{B05 -- unbewusste Einbindung von Software, welche durch Löschungsroutinen nicht permanent zur Verfügung steht} diff --git a/thesis.tex b/thesis.tex index 2e5366b..aa1e3f7 100644 --- a/thesis.tex +++ b/thesis.tex @@ -83,11 +83,10 @@ %\cleardoublepage\include{frontbackmatter/Figures} %\cleardoublepage\include{frontbackmatter/Tables} %\cleardoublepage\include{frontbackmatter/Listings} -%cleardoublepage\include{frontbackmatter/Acronyms} +\cleardoublepage\include{frontbackmatter/Acronyms} %************************************************************************* % Mainmatter %************************************************************************* -\todo{Seitenbeschriftung und Seitenzahlen stimmen noch nicht ganz} \cleardoublepage \pagestyle{scrheadings} \pagenumbering{arabic} @@ -97,11 +96,10 @@ \part{Seminararbeit}\label{pt:thesis} \include{chapters/Einleitung} -\cleardoublepage -\include{chapters/grund} -\include{chapters/problems} -\include{chapters/mass} -\include{chapters/fazit} +\cleardoublepage\include{chapters/grund} +\cleardoublepage\include{chapters/problems} +\cleardoublepage\include{chapters/mass} +\cleardoublepage\include{chapters/fazit} \cleardoublepage %\part{Work in Progress}\label{pt:wip}