From 1ed037280be101a6f60841593114da137cbcc7f4 Mon Sep 17 00:00:00 2001 From: Manuel Plonski Date: Sat, 21 Mar 2020 10:06:36 +0100 Subject: [PATCH] spellcheck 4 und cicd und scm --- chapters/Einleitung.tex | 6 +-- chapters/experience.tex | 22 ++++++--- chapters/grund.tex | 22 ++++----- chapters/mass.tex | 72 +++++++++++++-------------- chapters/problems.tex | 105 +++++++++++++++++++++------------------- pandoc/einleitung.tex | 2 +- thesis.tex | 7 ++- 7 files changed, 124 insertions(+), 112 deletions(-) diff --git a/chapters/Einleitung.tex b/chapters/Einleitung.tex index 8906361..e50f57e 100644 --- a/chapters/Einleitung.tex +++ b/chapters/Einleitung.tex @@ -41,9 +41,9 @@ Funktionalität der Software oder sogar einen Systemausfall bewirken. \medskip \section{Ziel der Arbeit} -\textbf{Mit dieser Seminararbeit soll untersucht werden, inwieweit sich solche und weitere typische und häufige Komplikationen bei der Einführung und dem Betrieb von CI/CD verhindern lassen.} +\textbf{Mit dieser Seminararbeit soll untersucht werden, inwieweit sich solche und weitere typische und häufige Komplikationen bei der Einführung und dem Betrieb von \cicd verhindern lassen.} -\textbf{Sie stellt dar, wie das Auftreten eines ungewollten Deployments und weiterer Probleme sowohl in der Einführung als auch im Betrieb eines CI/CD Systems durch geeignete Planung und technische Maßnahmen verhindert werden können.} +\textbf{Sie stellt dar, wie das Auftreten eines ungewollten Deployments und weiterer Probleme sowohl in der Einführung als auch im Betrieb eines \cicd Systems durch geeignete Planung und technische Maßnahmen verhindert werden können.} Anhand einer Problemrecherche und Analyse werden Empfehlungen entwickelt, welche bei der Planung und Einführung eines Systems @@ -75,7 +75,7 @@ entsprechende Empfehlungen abgeleitet. \section{Aufbau} \todo{Fix name Ref} -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. +Im Kapitel \ref{automatisierung-im-softwareentwicklungsprozess} werden Grundlagen für die Phasen der Softwareentwicklung und deren Automatisierung unter \cicd aufgezeigt, welche um eine Darstellung über das Branchkonzept unter Git ergänzt wird. 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. diff --git a/chapters/experience.tex b/chapters/experience.tex index f444141..912fe7c 100644 --- a/chapters/experience.tex +++ b/chapters/experience.tex @@ -1,28 +1,36 @@ \chapter{Persönliche Beobachtungen aus der Praxis mit CI/CD}\label{beobachtung} -\section{CI/CD auf GitLab-CI basis für ein privates Projekt}\label{be:gitlab} -Migration von vorhandener Legacy-Software in die All-in-One Lösung von GitLab-CI. +\section{CI/CD auf Basis von GitLab-CI für ein privates Projekt}\label{be:gitlab} +Durchführung einer Migration von vorhandener Legacy-Software in die All-in-One Lösung von GitLab-CI. ~ -Incident-Reporting Software basierend auf Java wurde: +Dabei wurde Incident-Reporting Software basierend auf Java: \begin{itemize} - \item containerisiert + \item containerisiert. \item durch die Migration auf CI/CD automatisiert gebaut und ausgeliefert. \end{itemize} %\Rightarrow% Probleme bei der Migration, aufgrund von Toolrequirments \section{CI/CD auf Jenkins X}\label{be:jx} + +~ + Praxissemesterprojekt: Erforschung von Datafeedback in GitLab unter Jenkins X. -Aufbau einer serverlosen Jenkins X CI/CD Plattform zur Erforschung von Datafeedbackmöglichkeiten zu GitLab ohne GitLab CI + +~ + +%\Rightarrow% Aufbau einer serverlosen Jenkins X CI/CD Plattform zur Erforschung von Datafeedbackmöglichkeiten zu GitLab ohne GitLab CI + +~ %\Rightarrow% Betrieb und Erhalt einer selfhosted CI/CD Variante benötigt Detailplanung \chapter*{Projekte, auf die sich die Experteninterviews beziehen} \section[CI/CD bei PFS]{CI/CD in der Plattformsteuerung}\label{be:pfs} -Einführung von CI/CD zum automatisiertem Bau, Test und Istallation von Systemen als VM-Images. +Einführung von CI/CD zum automatisierten Bau, Test und Istallation von Systemen als VM-Images. -\section{CI/CD in ``Access 4.0''}\label{be:a4} +\section[CI/CD in Access 4.0]{CI/CD in ``Access 4.0''}\label{be:a4} CI/CD Automatisierung von Microservices mit Kubernetes als Zielumgebung. Kubernetes Cluster läuft auf Bare--Metall-Switches und nicht auf virtuellen Maschinen. \ No newline at end of file diff --git a/chapters/grund.tex b/chapters/grund.tex index 1ed77ac..ba64abb 100644 --- a/chapters/grund.tex +++ b/chapters/grund.tex @@ -29,27 +29,27 @@ Systemdesign, die Programmierung, der Test sowie der Betrieb. \begin{description} - \item[Anforderungsanalyse]\label{phase-anford} + \item[Anforderungsanalyse:]\label{phase-anford} In diese Phase geht es darum, Anforderungen zu sammeln und zu analysieren. Dies geschieht in Form von Texten oder Modellen, welche der Strukturierung und Klassifizierung dienen. - \item[Systemdesign]\label{phase-sys} + \item[Systemdesign:]\label{phase-sys} Hier wird die Architektur der Module, Schnittstellen und Daten festgelegt, welche der Spezifikation aus der Anforderungsanalyse genügen sollen. - \item[Implementierung]\label{phase-code} + \item[Implementierung:]\label{phase-code} Die Programmierung mit dem dazugehörigen Modultest sind Bestandteil der - Entwicklungsphase der Implementierung + Entwicklungsphase der Implementierung. - \item[Softwaretest]\label{phase-test} + \item[Softwaretest:]\label{phase-test} In der Testphase wird ein System oder eine Komponente gegen die zuvor spezifizierten Anforderungen überprüft. Das Testergebnis dient der Behebung von Softwarefehlern, um ein fehlerfreies System in Produktion zu übernehmen. - \item[Betrieb]\label{phase-ops} + \item[Betrieb:]\label{phase-ops} Der Betrieb um fasst die Inbetriebnahme und Wartung der Software. \end{description} @@ -83,7 +83,7 @@ nicht deutlich, ob \cdel oder \cdl gemeint ist.\cite{ws19,redhat,info_aktu} ~ -Am Ende zähl nur, dass dies Funktionen entlang eines +Am Ende zählt nur, dass dies Funktionen entlang eines automatisierten und überwachten Prozesses in einer Pipeline durchgeführt werden, unabhängig von der Zuordnung zu einem Oberbegriff. @@ -181,7 +181,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, operative Systeme versioniert zu steuern. Dies wird auch als \textbf{GitOps} bezeichnet und ist eine weit verbreitete CI/CD Methode\todo{quelle}. +Die \scm Git besitzt im Zusammenhang mit \cicd die Möglichkeit, operative Systeme versioniert zu steuern. Dies wird auch als \textbf{GitOps} bezeichnet und ist eine weit verbreitete \cicd Methode\todo{quelle}. ~ @@ -195,12 +195,12 @@ Projekt-Repository sequenziell fortgeschrieben werden. 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. Wird eine Änderung auf einem Branch, -wird sie auf die gewünschte Weise vom CI/CD System verwaltet, integriert +wird sie auf die gewünschte Weise vom \cicd System verwaltet, integriert und in den Betrieb gebracht. ~ -Typisches Branchpattern besteht aus zwei permanenten Branches +Ein typisches Branchpattern besteht aus zwei permanenten Branches und mehreren temporären. Der Masterbranch repräsentiert die stabilste Softwareversion - diese Version lässt sich auch in der Produktion vorfinden - häufig gibt es noch den permanenten Developmentbranch, auf @@ -257,7 +257,7 @@ neuer temporärer Featurebranch mit der Spiegelung der Änderungen vor. \textbf{Build und Test in individueller Testumgebung} \end{enumerate} -CI/CD wird von Git angestoßen: CI/CD erkennt die neue Software Version +\cicd wird von Git angestoßen: \cicd erkennt die neue Software Version und startet einen Development-Build auf dem temporäreren Featurebranch, da es im Branchpattern entsprechend definiert wurde. diff --git a/chapters/mass.tex b/chapters/mass.tex index 53cfe20..672ebb8 100644 --- a/chapters/mass.tex +++ b/chapters/mass.tex @@ -1,6 +1,6 @@ \chapter{Empfehlungen für die Planung und Implementierung von CI/CD} \label{mas} -Auch wenn ein \cicd System nach der Einführung als Gesamtkomplex vorliegt, welcher 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. +Auch wenn ein \cicd System nach der Einführung als Gesamtkomplex vorliegt, 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 Automatisierungsteam sehr viel umfangreichere Detailkenntnisse besitzen wird, muss der Softwareentwickler nur das für ihn relevanten Wissen in Form von Dokumentation vorliegen haben. @@ -9,23 +9,23 @@ Im Folgenden werden Empfehlungen aufgezeigt, welche das Auftreten der oben geschilderten Probleme verhindern können. Die dargestellten Maßnahmen beziehen sich auf die Planung und Implementierung -eines CI/CD Systems, Dokumentation und auch konkrete technische +eines \cicd Systems, 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 +Die Einführung eines \cicd Systems beinhaltet nicht nur eine einfache Automatisierung bestehender Prozesse, es handelt sich um eine komplexe Automatisierung mit einem hohen Grad an Integration. Aus diesem Grund stellt die sorgfältige Planung des Systems die Basis für eine -erfolgreiche Einführung von CI/CD. Hierbei müssen Fragen zu den +erfolgreiche Einführung von \cicd. Hierbei müssen Fragen zu den Anforderungen und dem Design beantwortet werden. \subsection{Frage nach dem Umfang der Automatisierung und den Objekten der Automatisierung}\label{mas:m1.1} Entsprechend des individuell vorliegenden Entwicklungsprozesses werden die -Teilprozesse und ihre Abfolge definiert, welche das CI/CD System +Teilprozesse und ihre Abfolge definiert, welche das \cicd System abbilden soll. Typische Prozesse hierfür sind der @@ -44,10 +44,10 @@ Die detaillierte Definition der \textbf{Inputschnittstelle} für das \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. +\cicd System aufgerufen wird. Zu diesem Zeitpunkt ist es notwendig, die \textbf{Rahmenbedingungen} für -das CI/CD -- System festzulegen. Dazu gehören alle Arten von +das \cicd -- System festzulegen. Dazu gehören alle Arten von unternehmens- oder projektspezifischen Konventionen und Richtlinien beispielsweise zu Security, Code oder Systemarchitektur. Auch die vorliegende Hardware könnte als Rahmenbedingung vorgegeben sein. @@ -64,7 +64,7 @@ Für den Prozessschritt des Delivery gilt es zu entscheiden, ob die Softwareartefakte in einem einfachen Dateisystem bereitgestellt werden oder in einem Artefakt-Managementsystem. -Wird das CI/CD-System für ein bereits sich im +Wird das \cicd-System für ein bereits sich im Softwareentwicklungsprozess vorliegendes Projekt eingeführt, ist die Planung einer \textbf{Migration} notwendig. Hierbei müssen alle zu migrierende Artefakte zu den entsprechenden Prozessschritten bestimmt und @@ -72,7 +72,7 @@ beschrieben werden. \subsection{Definition der Zielumgebung für Artefakte oder Software}\label{mas:m1.2} -Eine relevante Vorgabe in der Planung eines CI/CD-Systems ist die +Eine relevante Vorgabe in der Planung eines \cicd-Systems ist die Festlegung der Zielumgebung für Artefakte (für Delivery) und im Falle des Deployments die Zielumgebung für die Software. @@ -123,7 +123,7 @@ dargestellt. \subsection{Festlegung der Hardware für das CI/CD System}\label{mas:m1.4} -Die Art und Häufigkeit der Anfragen an das CI/CD System +Die Art und Häufigkeit der Anfragen an das \cicd System ist ebenfalls vom Use Case vorgegeben und bestimmt die Ausstattung der Hardware mit CPU und RAM. @@ -139,12 +139,12 @@ Learning Anwendungen und auch bei Quarkus- Native-Compiles. Der Speicherbedarf muss ermittelt werden, entsprechend des Speicherkonzepts und passend zu den gewählten Tools. Auch die Vorgaben zur Spiegelung für die redundante Verwaltung der Datenserver können bei -der Konfigurationsentscheidung eine Rolle spielen, so wie Konventionen +der Konfigurationsentscheidung eine Rolle spielen, sowie Konventionen aus dem Unternehmens- und Projektumfeld. \section{Dokumentation}\label{mas:m2} -Ein CI/CD System wird zum zentralen Element des +Ein \cicd 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 Automatisierungsteam. @@ -157,25 +157,25 @@ Ablauf durch die Pipeline beeinflussen können. ~ -Das Automatisierungsteam benötigt Informationen über sowohl die CI/CD Engine, eingesetzte +Das Automatisierungsteam benötigt Informationen über sowohl die \cicd Engine, eingesetzte Tools und deren Interfaces als auch über die aktuelle Konfiguration der Systeme. -Bei Störungen im CI/CD System kann diese Dokumentation helfen, das +Bei Störungen im \cicd System kann diese Dokumentation helfen, das System wiederherzustellen bzw. sogar extern als Workaround zu betreiben -(durch den Einsatz von Skripten zum Aufruf der einzelnen CI/CD Schritte). +(durch den Einsatz von Skripten zum Aufruf der einzelnen \cicd Schritte). ~ -Im Anhang befindet sich das Bespiel einer Entwicklerdokumentation für die CI/CD Implementierung eines Softwareentwicklungsprojektes. -Die Dokumentation gehört zu einem Projekt, welches einen einfachen Java-Webservice durch CI/CD automatisch integriert und ausgeliefert. +Im Anhang befindet sich das Bespiel einer Entwicklerdokumentation für die \cicd Implementierung eines Softwareentwicklungsprojektes. +Die Dokumentation gehört zu einem Projekt, welches einen einfachen Java-Webservice durch \cicd automatisch integriert und ausliefert. \todo{ref zu doku} \section{technische Maßnahmen}\label{mas:m3} \subsection{Lösungsansätze zur Umsetzung der Maßnahmen}\label{mas:m3.1} -Bei der Einführung eines CI/CD System können mit Hilfe von technischen -Maßnahmen einige Probleme\todo{Synonym} vermieden werden, welche durch Unkenntnis der +Bei der Einführung eines \cicd System können mit Hilfe von technischen +Maßnahmen einige Probleme\todo{Synonym} vermieden werden, welche durch fehlendes Know-How der Entwickler über die Funktionsweise des Systems verursacht werden. Zusätzlich können technische Maßnahmen auch für die Einhaltung von Richtlinien genutzt werden. @@ -207,8 +207,8 @@ Zeit gelöscht werden. ~ -Weitere Maßnahmen könnten die Einführung einer \textbf{Hardwarequote} um -für eine ungewollte Hardwarebeanspruchung für einzelne Nutzer +Weitere Maßnahmen könnten die Einführung einer \textbf{Hardwarequote} sein, um +eine ungewollte Hardwarebeanspruchung für einzelne Nutzer vorzubeugen. ~ @@ -230,13 +230,13 @@ des Masterbranch} Die in B04 dargestellte Problemstellung besteht nicht nur aus der versehentlichen Nutzung des Masterbranchs als Featurebranch. Die Brisanz -entsteht durch die Folgen bei der Ausführung der Push-Operation im CI/CD +entsteht durch die Folgen bei der Ausführung der Push-Operation im \cicd Umfeld. Der Build-Prozess wird gestartet und endet mit dem Deployment in der produktiven Umgebung. ~ -Das Szenario wird mit Hilfe einer einfachen CI/CD Umgebung dargestellt. +Das Szenario wird mit Hilfe einer einfachen \cicd Umgebung dargestellt. Sie besteht aus einer kleinen Pipeline, welche die Funktionen Build und Deploy abdeckt. @@ -245,7 +245,7 @@ Das Branchpattern besteht aus einem Master-, Develop- und Featurebranch. \subsubsection{Anforderungen für Branchmanagement/Deployment} Im Folgenden werden die Anforderungen definiert, welche mit Hilfe der -CI/CD Tools oder des Versionsmanagementsystem umgesetzt werden müssen. +\cicd Tools oder die \scm umgesetzt werden müssen. ~ @@ -269,7 +269,7 @@ Möglichkeiten zu intervenieren, können erst später ansetzen. -Diese Richtlinien stellen somit die Grundlage, dass kein Code durch das +Diese Anforderungen stellen somit die Grundlage, dass kein Code durch das unbewusste Arbeiten auf dem Masterbranch in Produktion gelangt. Hieraus ergeben sich die folgenden Einzelanforderungen für technische @@ -294,13 +294,14 @@ durch Merge ausführen kann. \subsubsection{Umsetzung im Versionsmanagmenttool oder in den CI Tools} -Es gibt eine Vielzahl von Versionsmanagementsystemen, welche in der Lage -sind, gewisse Operationen regulieren können. Zum Beispiel das Verhindern +Es gibt eine Vielzahl von \textit{Quellcodeverwaltungen}, welche in der Lage +sind, gewisse Operationen zu regulieren. Zum Beispiel das Verhindern von Push-Operationen auf gewissen Branches. ~ + \setlength{\leftskip}{3em} -Das Versionsmanagementsystem GitLab lässt sich so konfigurieren, dass +\noindent Die \scm GitLab lässt sich so konfigurieren, dass man auf dem Masterbranch die Push-Operation nicht nutzen darf. Beim Auslösen des Push kann eine Fehlermeldung angezeigt werden. @@ -319,22 +320,22 @@ Release-Freigabe durch die entsprechend autorisierte Person dar. ~ +\setlength{\leftskip}{0px} + Sind diese Möglichkeiten der Regulierung von Operationen mit dem vorhandenen Versionshaltungstool nicht gegeben, gibt es noch die Möglichkeit über das CI-Tool einzugreifen: ~ -Ein CI-Tool kann bei der Aktivierung nicht nachvollziehen, ob sich die +\setlength{\leftskip}{3em} +\noindent Ein CI-Tool kann bei der Aktivierung nicht nachvollziehen, ob sich die Anfrage aus einem Push- oder Merge-Aufruf ergeben hat. ~ Aber es gibt die Möglichkeit der Überprüfung des letzten Commits aus dem Versionshaltungstool. - -~ - Die eine vorgegebene Berechtigung des Users kann überprüft werden, welche z.B. mit Hilfe von digitalen Signaturen umgesetzt werden könnte. @@ -353,11 +354,12 @@ Auch in der Projektdokumentation sollte auf dieses Regelwerk hingewiesen werden. Neben der Darstellung der Branchpattern sollten die vorhandenen Branches mit den erlaubten Operationen aufgeführt sein. -Eine Übersicht der möglichen Fehlermeldungen mit dem Verweis der -umgesetzten technischen Maßnahmen ergänzt die Darstellung. +Eine Übersicht der möglichen Fehlermeldungen mit dem Hinweis auf die +umgesetzten technischen Maßnahmen ergänzt die Beschreibung. Mit dieser Darstellung zur konkreten Umsetzung der Maßnahme zur Vermeidung der unbewussten Entwicklung auf dem Masterbranch wird dieses Kapitel abgeschlossen. -Das Bespiel verdeutlicht, wie umfangreich sich die Möglichkeiten der technischen Maßnahmen entfalten , sobald man die Ebene von realem UseCase und Toolumgebung verlässt. +Das Bespiel verdeutlicht, wie umfangreich sich die Möglichkeiten der technischen Maßnahmen entfalten, +sobald man die Ebene von realem Use Case und Toolumgebung betritt. diff --git a/chapters/problems.tex b/chapters/problems.tex index 81c93ec..f1a062e 100644 --- a/chapters/problems.tex +++ b/chapters/problems.tex @@ -1,16 +1,16 @@ \chapter[Herausforderungen von CI/CD]{Herausforderungen bei der Einführung und im Betrieb von CI/CD} \label{heraus} -Die Umsetzung und Einführung eines CI/CD System beinhaltet weit mehr als +Die Umsetzung und Einführung eines \cicd System beinhaltet weit mehr als 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 +So läuft die Einführung und der Betrieb eines \cicd 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, +skizziert, welche zum Teil typisch und häufig im Umfeld von \cicd sind, oder durch die starke Integration besonders zum Tragen kommen. Die Problembeschreibungen basieren auf Experteninterviews, Literaturrecherchen und Beobachtungen bei verschiedenen @@ -19,20 +19,20 @@ Praxisprojekten. ~ Die Interviews wurden mit Softwareentwicklern sowie -Automatisierungs- und Integrationsexperten geführt. (CI/CD Systeme für +Automatisierungs- und Integrationsexperten geführt. (\cicd 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 +Meine Praxiserfahrungen basieren auf der Einführung eines \cicd Systems +unter GitLab-CI sowie dem Aufbau einer Serverless - \cicd 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. +verschiedenen \cicd Systemen in ihrer Anwendung. ~ @@ -44,46 +44,46 @@ wird in der Darstellung nach Problemursache gruppiert. \section[Herausforderungen während der Einführung]{Probleme während der Einführung eines CI/CD System} In diesem Kapitel werden Probleme dargestellt, welche während der -Planungs- und Einführungsphasen von CI/CD in Erscheinung treten, dabei +Planungs- und Einführungsphasen von \cicd in Erscheinung treten, dabei können sie zu Verzögerungen im Einführungsprozess fuhren oder sogar eine Einführung verhindern. Eine wesentliche Entscheidung in dieser Phase ist die Toolauswahl. Die Nutzung einer All-in-One Lösung verspricht eine schnelle -Implementierung und Verfügbarkeit von CI/CD, vor allem wenn sie durch +Implementierung und Verfügbarkeit von \cicd, vor allem wenn sie durch die firmeninternen Compliance - Vorgaben zugelassen ist (All-in-One Tool). -Das individuelle CI/CD System wird auf die konkrete Projekt- und +Das individuelle \cicd System wird auf die konkrete Projekt- und Systemumgebung (Quellcodeverwaltung, Tools zur Codeüberprüfung, Dependency-Management) ausgelegt. Häufig finden sich in dieser Lösung Tools, welche bereits im Einsatz sind und so für den Entwickler weniger Umstellung bedeuten. Unterschiedliche Einzeltools bilden zusammen mit -dem automatisierten System (\textit{Build-Server}) das CI/CD System. +dem automatisierten System (\textit{Build-Server}) das \cicd System. In diesem Zusammenhang wird der Use Case definiert als eine konkrete -Anwendung eines CI/CD Systems für ein Softwareentwicklungsprojekt mit +Anwendung eines \cicd Systems für ein Softwareentwicklungsprojekt mit allen Anforderungen des Projektes. (siehe \ref{mas:m1} \nameref{mas:m1}) \subsection[aufgrund nicht ausreichender Planungstiefe]{Probleme aufgrund nicht ausreichender Planungstiefe} Die im Anschluss dargestellten Herausforderungen bei einer Einführung -von CI/CD können entstehen, wenn bei der Planung Details über den Use -Case sowie die potentiellen Tools nicht tief analysiert werden. +von \cicd können entstehen, wenn bei der Planung Details über den Use +Case sowie die potenziellen Tools unzureichend analysiert werden. \subsubsection[E01]{\textbf{E01} - Toolauswahl deckt nicht die Anforderungen des Softwareentwicklungsprojekts}\label{E01} Insbesondere bei der Wahl eines All-in-One Tool kann es passieren, dass -der Use Case nicht darstellbar ist. Beispielsweise könnte der Use Case +der Use Case nicht darstellbar ist. Beispielsweise kann der Use Case einer Softwareentwicklung für ein Autoradio nicht mit einem All-in-One Tool für Cloud- und Webanwendung umgesetzt werden. \cite{shahin2017continuous,plonski_herausforderungen_Leo_2020} ~ -$\Rightarrow$ Das CI/CD System ist nicht funktionsfähig für diese Anwendung und die +$\Rightarrow$ Das \cicd System ist nicht funktionsfähig für diese Anwendung und die Toolauswahl muss wiederholt werden @@ -92,7 +92,7 @@ Toolauswahl muss wiederholt werden Gerade bei einem All-in-One Tool ist die Einführung besonders herausfordernd. Während bei einer individuellen Lösung häufig bereits -existierende, dem Nutzer bekannte Tools im CI/CD -- System implementiert +existierende, dem Nutzer bekannte Tools im \cicd -- System implementiert werden, ist bei dem All-in-One Tool häufig mehr an Umstellung zu leisten in Bezug auf Tool und Methode. \cite{plonski_herausforderungen_grund_2020,plonski_herausforderungen_Leo_2020} @@ -104,7 +104,7 @@ $\Rightarrow$ Notwendigkeit von zusätzlichem Training für Methode und Tool \subsubsection{\textbf{E03} - Migrationsaufwand}\label{E03} Für ein bereits existierendes Projekt muss die Migration aus der alten -Umgebung in das neue CI/CD System vorgesehen werden. +Umgebung in das neue \cicd System vorgesehen werden. Code-, Test- und Deploymentscripte sowie die Zielumgebung müssen angepasst werden (Server, Software, Internetanbindung, Security). @@ -119,24 +119,24 @@ Problemen oder Verzögerungen führen können. \cite{plonski_herausforderungen_g $\Rightarrow$ Je nach Tool erheblicher Migrationsaufwand -\subsubsection{\textbf{E04} - Fehlender Automatisierungsexperten}\label{E04} +\subsubsection{\textbf{E04} - Fehlende Automatisierungsexperten}\label{E04} -Wird ein selfhosted CI/CD-System nicht durch einen +Wird ein selfhosted \cicd-System nicht durch einen Automatisierungsexperten umgesetzt und betreut, stehen die CI Tools zwar zur Automatisierung bereit, sind aber noch nicht integriert. Der Entwickler muss die Integration der Tools für sein Projekt nach eigenem Ermessen selbst vornehmen. Das führt zu einer Vielzahl unterschiedlicher -Setups eines CI/CD - Systems. +Setups eines \cicd - Systems. Diese unterschiedlichen Setups gehen zu Lasten von Wartbarkeit, Übersichtlichkeit und Fehleranfälligkeit. -Bei unsachgemäßer Nutzung eines CI/CD Systems können z.B. -Integrationsfehler erst im Deployment zu Tage treten, ob wohl die Tests +Bei unsachgemäßer Nutzung eines \cicd Systems können z.B. +Integrationsfehler erst im Deployment zu Tage treten, obwohl die Tests erfolgreich durchlaufen wurden. -Die Wartung des CI/CD Systems ist auch Aufgabe des -Automatisierungsexperten. Ein CI/CD System benötigt kontinuierliche +Die Wartung des \cicd Systems ist auch Aufgabe des +Automatisierungsexperten. Ein \cicd System benötigt kontinuierliche Wartung im laufenden Betrieb. Dazu gehört die Überwachung und Anpassung von Systemstatus, Automatisierung, Speicherverbrauch, Zertifikaten, Konfiguration und Architektur. @@ -146,7 +146,7 @@ Die Server müssen angepasst, aufgestockt, beschleunigt und die Balance ~ -$\Rightarrow$ Im individuellen CI/CD-System muss diese Aufgabe geplant werden, +$\Rightarrow$ Im individuellen \cicd-System muss diese Aufgabe geplant werden, während bei der All-in-One Lösung der Provider diese Aufgabe wahrnimmt @@ -154,16 +154,16 @@ $\Rightarrow$ Im individuellen CI/CD-System muss diese Aufgabe geplant werden, \subsection[im Umfeld von Richtlinien und Standards]{Probleme im Umfeld von Richtlinien und Standards} Es gibt eine Vielzahl von projekt- und unternehmensspezifischen -Richtlinien, unter denen CI/CD Systeme implementiert und betrieben +Richtlinien, unter denen \cicd Systeme implementiert und betrieben werden. Unkenntnis über deren Existenz oder Inhalt führen zu den folgenden Herausforderungen bei einer Einführung. \subsubsection{\textbf{E05} -- Konflikt zwischen Sicherheitsrichtlinien und Funktionsweise des Tools}\label{E05} 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 +könnte das Ausführen eines privilegierten Containers in einem \cicd +System nicht zugelassen sein, wenn die \cicd Systeme Zugriffe auf +Produktivsysteme besitzen und so durch ein modifiziertes \cicd Script ein unautorisierter Zugriff auf das Produktionssystem erfolgen könnte. \cite{plonski_herausforderungen_Leo_2020,plonski_herausforderungen_grund_2020} \ref{be:jx} ~ @@ -173,8 +173,8 @@ $\Rightarrow$ Kann zum Scheitern der Systemeinführung führen oder ein Workarou \subsubsection{\textbf{E06} -- Coding-Konvention}\label{E06} -Unternehmens- oder Projekt Coding Conventions können den Vorgaben des -gewünschten Tools widersprechen. Ein Workaround ist notwendig. \cite{plonski_herausforderungen_Leo_2020} +Unternehmens- oder Projekt Coding Konventionen können den Vorgaben des +gewünschten Tools widersprechen. \cite{plonski_herausforderungen_Leo_2020} ~ @@ -186,12 +186,12 @@ 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 +\cicd System geht davon aus, dass die Software ihren Service über einen 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 operative Zielsystem, z.B. +Darüber hinaus könnte das \cicd 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 @@ -216,8 +216,8 @@ $\Rightarrow$ Ein Workaround ist notwendig \section[Herausforderungen im Betrieb]{Probleme, welche im Betrieb eines CI/CD Systems entstehen können.} -Viele Herausforderungen in einer Umstellung auf CI/CD werden erst nach -der Einführung einer CI/CD Pipeline sichtbar und Probleme entstehen aus +Viele Herausforderungen in einer Umstellung auf \cicd werden erst nach +der Einführung einer \cicd Pipeline sichtbar und Probleme entstehen aus Unkenntnis über spezifische Anforderungen des Tools - der gewünschte Prozessdurchlauf funktioniert nicht und es müssen Workarounds gefunden werden - die Betriebskosten des Tools erhöhen sich. @@ -227,13 +227,13 @@ werden - die Betriebskosten des Tools erhöhen sich. Eine wesentliche Änderung ist die Umstellung auf eine Softwareentwicklung durch kleine inkrementelle Änderungen, welche kontinuierlich implementiert und integriert werden. Daraus ergeben sich -besondere Anforderungen an die Hardware, auf der ein CI/CD System +besondere Anforderungen an die Hardware, auf der ein \cicd System installiert wird. \subsubsection{\textbf{B01} extreme Laufzeiten im Build-Prozess}\label{B01} -CI/CD Systeme und Plattformen sind in ihrer Anwendung so ausgerichtet, -dass viele Projekte parallel CI/CD betreiben. +\cicd Systeme und Plattformen sind in ihrer Anwendung so ausgerichtet, +dass viele Projekte parallel \cicd betreiben. Durch den Ansatz, inkrementell kleinste Codeänderungen sofort zu integrieren, wird bei jeder Codeänderung der Build-Prozess durchlaufen. \ref{be:jx} @@ -244,6 +244,8 @@ $\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. +~ + Dieser Problematik wurde in meinem Praxisprojekt unter dem Einsatz von Quarkus beobachtet. (\ref{be:jx}) @@ -254,7 +256,7 @@ 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 +abbilden, während er auf einem \cicd System mit einer etwas älteren Hardware bis zu eineinhalb Stunden dauern kann. \subsubsection{\textbf{B02} erschöpfte Speicherkapazität des CI/CD System}\label{B02} @@ -270,8 +272,9 @@ Software selbst und ihr Containerimage.\cite{plonski_herausforderungen_Leo_2020} $\Rightarrow$ Manuelles Eingreifen in die Speicherung der Artefakte wird notwendig und ist zudem fehleranfällig. +~ -Über ein CI/CD System der Telekom wurden entsprechende Probleme +Über ein \cicd 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. @@ -294,7 +297,7 @@ $\Rightarrow$ Lange Wartezeiten für eine nicht mehr benötigte Pipelineausfüh Nutzung des Masterbranch} \label{B04} Wird versehentlich direkt auf dem Masterbranch gearbeitet und diese -Änderung im Source Code Managementsystem freigegeben, kann es zur +Änderung in der \scm freigegeben, kann es zur Ausführung der Release-Pipeline kommen und die Softwareversion wird unbeabsichtigt ausgeliefert. \cite{plonski_herausforderungen_Leo_2020,plonski_herausforderungen_grund_2020,shahin2017continuous} \ref{be:jx} @@ -302,7 +305,7 @@ unbeabsichtigt ausgeliefert. \cite{plonski_herausforderungen_Leo_2020,plonski_he $\Rightarrow$ Nicht gewünschter Code befindet sich in Produktion. - +~ Dieses Problem wurde bereits in der Einleitung angerissen. Um hier eine konkrete Lösungsmöglichkeit zu erarbeiten, erfolgt eine weitere Analyse @@ -311,7 +314,7 @@ innerhalb einer konkreten Systemumgebung. ~ Das versehentliche Arbeiten auf dem Masterbranch ist zunächst ein -typisches Problem im Git und GitOps (\ref{grund:git}) Umfeld. In einem CI/CD Umfeld hat es +typisches Problem im Git und GitOps (\ref{grund:git}) Umfeld. In einem \cicd 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. @@ -325,7 +328,7 @@ Hierzu die Darstellung des Falls an einem Beispiel unter \gitops (\ref{grund:git \setlength{\leftskip}{3em} -\noindent Mit Hilfe des Versionsmanagementsystem Git besteht die Möglichkeit, dass +\noindent Mit Hilfe der \scm Git besteht die Möglichkeit, dass jeder Entwickler im eigenen „Featurebranch`` an seinem Code entwickelt. Dieser Code wird später im Masterbranch zusammengeführt, um die Codeänderung dem Programm zuzuführen. @@ -344,12 +347,12 @@ validieren. In diesem Fall wird die Push-Operation jedoch nicht auf dem Featurebranch, sondern auf dem Masterbranch ausgeführt. Anstelle eine temporäre Testversion zu erhalten, bewirkt der Push auf dem Masterbranch -die Ausführung von CI/CD für ein Release. +die Ausführung von \cicd für ein Release. ~ -Dies führt zum Start der Releasepipeline. Die Codeänderung landet als -neues Softwarerelease im Produktionssystem und nicht, wie gewünscht, in +Dies führt zum Start der Releasepipeline. Die Codeänderung wird als +neues Softwarerelease im Produktionssystem ausgerollt und nicht, wie gewünscht, in einer Testumgebung. \setlength{\leftskip}{0pt} @@ -383,7 +386,7 @@ Die statische Codeanalyse erwartet den Source Code in einem spezifischen Ordner. Unkenntnis über diese Vorgabe kann dazu führen, dass der Source Code in einem anderen Verzeichnis bereitgestellt wird und das Analysetool findet im spezifizierten Verzeichnis keinen Code. -Manche Tools melden einen positiven Status und der CI/CD Prozess läuft weiter. \ref{be:jx} \cite{shahin2017continuous} +Manche Tools melden einen positiven Status und der \cicd Prozess läuft weiter. \ref{be:jx} \cite{shahin2017continuous} ~ @@ -398,8 +401,8 @@ 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 die Tests mit einer positiven Statusmeldung, aber -die Funktion des Moduls /Gesamtsystem ist nicht gewährleistet. \cite{connolly,shahin2017continuous} \ref{be:jx} +Der Code passiert die Tests mit einer positiven Statusmeldung, jedoch ist +die Funktion des Moduls/Gesamtsystems nicht gewährleistet. \cite{connolly,shahin2017continuous} \ref{be:jx} ~ diff --git a/pandoc/einleitung.tex b/pandoc/einleitung.tex index 994e1ae..f382b05 100644 --- a/pandoc/einleitung.tex +++ b/pandoc/einleitung.tex @@ -27,7 +27,7 @@ Eine dieser Herausforderungen, welche erst im Betrieb deutlich werden, ist die unabsichtliche Auslieferung eines nicht produktionsbereiten Codes in den Betrieb. -Eine falsche Handhabung im Sourcecodemanagementtool kann in einem CI/CD +Eine falsche Handhabung in der \scm kann in einem CI/CD Umfeld zu diesem ungewollten Deployment führen und so eine fehlerhafte Funktionalität der Software oder sogar einen Systemausfall bewirken. diff --git a/thesis.tex b/thesis.tex index 5c2cef5..c18c081 100644 --- a/thesis.tex +++ b/thesis.tex @@ -94,12 +94,11 @@ % Alwas use \cleardoublepage before \part{...}. \todo{Einfügen Doku} \todo{Tabelle} -\todo{Quelle backwords} -\todo{Readthru} -\todo{Grafik} +\todo{märz} \todo{svc} \todo{cicd} -\todo{märtz} +\todo{Grafik} + \cleardoublepage \part{Seminararbeit}\label{pt:thesis} \include{chapters/Einleitung}