spellcheck 4 und cicd und scm
This commit is contained in:
@@ -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}
|
||||
|
||||
~
|
||||
|
||||
|
||||
Reference in New Issue
Block a user