\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, 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. Die dargestellten Maßnahmen beziehen auf die Planung und Implementierung 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 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 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 Entwicklungsprozess werden die Teilprozesse und ihre Abfolge definiert, welche das CI/CD System abbilden soll. Typische Prozesse hierfür sind der \begin{description} \item[Build-Prozess] Compile, ggf, Multimudulcompiling und Containerbau \item[Testprozess] Modul, Integrations- und Systemtest \item[Analyseprozess] statisch oder dynamische Codeanalyse, Dependencyanalyse, Lizenzscan, Containersicherheitsanalyse \item[Delivery oder Deployment] \end{description} 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. Zu diesem Zeitpunkt ist es notwendig, die \textbf{Rahmenbedingungen} für das CI/CD -- 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. Für jeden \textbf{Prozessschritt} muss eine \textbf{detaillierte funktionale Anforderung} erfolgen, beispielsweise könnte für den Analyseprozess die Arten von Checks festgelegt werden, wie der Check auf bestimmte Designpatterns, Variablennamen, der Check gegen vorhandene Regellisten.\\ 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 Softwareentwicklungsprozess vorliegendes Projekt eingeführt, muss eine \textbf{Migration} geplant werden. Hierbei müssen alle zu migrierende Artefakte zu den entsprechenden Prozessschritten bestimmt und 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 Festlegung der Zielumgebung für Artefakte (für Delivery) und im Falle des Deployments die Zielumgebung für die Software. Die Laufzeitumgebung der produktiven Software variiert in Abhängigkeit des Use Case: Beispielsweise kann es sich um ein Autoradio, eine Cloudumgebung, eine App, eine Website, einen Großrechner oder einen Cluster handeln, welcher lokal vorliegt oder über das Internet zugänglich ist. \subsection{Design des CI/CD Systems}\label{mas:m1.3} \subsubsection{Toolauswahl}\label{mas:m1.3.1} In diesem Planungsschritt gilt es, aus den Vorgaben über den Umfang, Inhalt und die Zielumgebung des Use Case die \textbf{Wahl der Toolkonfiguration} und auch die Entscheidung zwischen \textbf{individueller Lösung} oder einer \textbf{All-in-One Lösung} zu treffen. Zunächst muss eine Toolübersicht über Einzel- als auch All-in-One Tools, mit einer genauen Analyse über Funktionalität und Schnittstellen erstellt werden. Ein systematischer Abgleich der Anforderungen aus \ref{mas:m1.1} und \ref{mas:m1.2} gegen die Tooleigenschaften liefert eine potenzielle Toolauswahl, welche gegen die Detailanforderungen und Rahmenbedingungen überprüft wird. Dabei geht es um die Bestimmung der grundlegenden Realisierbarkeit und auch um den Änderungsaufwand im Falle von Konflikten. In die Entscheidung der Konfiguration fließen neben der funktionalen Betrachtung auch der Entwicklungsaufwand für Einführung und Migration, Lizenzkosten, Hardwarekosten und Training ein. Weitere betriebsbedingte Aufwände beispielsweise für das Integrationsteam gehören auch zu dieser Betrachtung. Für den Fall, dass Module zu einer individuellen Lösung konfiguriert werden, muss eine Integrationsanalyse durchgeführt werden. \subsubsection{Design im Toolkontext}\label{mas:m1.3.2} 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 \ref{mas:m3} dargestellt. \subsection{Festlegung der Hardware für das CI/CD System}\label{mas:m1.4} Die Art der Anfragen und die Häufigkeit der Anfragen an das CI/CD System ist ebenfalls vom Use Case vorgegeben und bestimmt die Ausstattung der Hardware mit CPU und RAM. So hat eine pure Webanwendung mit einer CI Anfrage pro Stunde keine besondere Anforderung an die eine Hardware, während ein CI-System, welches 25 CI Anfragen in der Stunde erhält und für die Entwicklung von CPU-oder sogar GPU intensiven Anwendungen gedacht ist, eine viel stärkere Hardware mit höheren Taktraten und Kernen benötigt. Solche hardwareintensiven Anwendungen finden sich häufig unter Machine 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 aus dem Unternehmens- und Projektumfeld. \section{Dokumentation}\label{mas:m2} 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 Automatisierungsteam. Die Dokumentation stellt für den Entwickler Informationen bereit, welche ihm Kenntnisse zu den In- und Output-Schnittstellen vermittelt. Er muss 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 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 verwenden Skripten zum Aufruf der einzelnen CI/CD Schritte). \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 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 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} \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. Auch im \textbf{Speichermanagement} gibt es Möglichkeiten, den \emph{in (\ref{B02} B02 - erschöpfte Speicherkapazität des CI/CD System)} beschriebenen Speicherengpass zu verhindern: Durch ein \emph{geeignetes \textbf{Lifecycle-Management}} könnten gewisse Artefakte nach einiger 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 vorzubeugen. Das \textbf{vier-Augenprinzip} klingt zunächst nach einer organisatorischen Maßnahme und kann für unterschiedliche Prozessschritte als Qualitätssicherungsmaßnahme vorgesehen werden. Die technische 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. \subsection{Beispiel für die Umsetzung von Maßnahmen zur Vermeidung von B04 -- ungewolltes Aktivieren der Pipeline durch unbewusste Nutzung 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 des Push-Kommando im CI/CD 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. Sie besteht aus einer kleinen Pipeline, welche die Funktionen Build und Deploy abdeckt. 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. Die erste Überlegung wäre, gleich zu dem Zeitpunkt, an dem der Entwickler seine „versehentliche`` Programmiertätigkeit auf dem Masterbranch beginnt, eingreifen zu können. An dieser Stelle sind jedoch die Optionen in den weit verbreiteten Tools nicht gegeben und die Möglichkeiten zu intervenieren, können erst später ansetzen. \textbf{Ziel ist es, dass Softwareänderungen nur über das Merge-Kommando in den Masterbranch übertragen werden dürfen.} \textbf{Ein Release darf nur ausgeführt werden, nach dem die Softwareänderung von einer autorisierten Person über das Vieraugenprinzip eine Überprüfung durchlaufen hat.\\ } Diese Richtlinien 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 Maßnahmen: Verhinderung der Push-Operation für Code auf den Masterbranch Code muss über die Merge-Operation auf den Masterbranch übertragen werden Bei der Merge-Operation auf dem Masterbranch muss der Vorgang einer Code- und/oder Testüberprüfung durch eine weitere berechtigte Person nach dem Vieraugenprinzip vor der Release-Ausführung bestätigt werden Im betrachteten Problemfall würde der Entwickler zunächst unbemerkt auf dem Masterbranch arbeiten. Er bestätigt seine Codeänderungen und würde versuchen, sie mit dem Push-Kommando auf das Remote-Git-Repository hochzuladen. In diesem Augenblick erhält er jetzt eine Fehlermeldung aufgrund des Verbotes des Push-Kommandos. Desweitern verhindert der Prüfschritt für das Vieraugenprinzip, dass der Entwickler ein Release 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 von Push-Operationen auf gewissen Branches. Das Versionsmanagementsystem GitLab lässt sich so konfigurieren, dass man auf dem Masterbranch ein Push-Kommando nicht nutzen darf. Beim Auslösen des Push kann eine Fehlermeldung angezeigt werden. Entsprechend können im GitLab die Einstellungen getroffen werden, dass nur die Merge-Operation erlaubt ist. Ebenfalls ist es möglich, im GitLab bei einem Merge-Kommando einen zusätzlichen Validierungsschritt zu implementieren, welcher nur von Usern mit einer speziellen Berechtigung bestätigt werden kann. Dieser Schritt stellt dann die Bestätigung der Vieraugenüberprüfung und Release-Freigabe durch die entsprechend autorisierte Person dar. 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 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. Diese Regel stellt sicher, dass die CI-Pipeline für ein Release gestartet wird, wenn der letzte Commit durch eine berechtigte Person durchgeführt wird. \subsubsection{Dokumentation zur Erläuterung der Funktionalität für den Entwickler} 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. Mit dieser Darstellung zur konkreten Umsetzung der Maßnahme zur Vermeidung der unbewussten Entwicklung auf dem Masterbranch wird dieses Kapitel abgeschlossen. Sobald man sich auf die Ebene von realem Use Case und Toolumgebung begibt entfalten sich die Möglichkeiten der technischen Maßnahmen und die Realisierung kann entsprechend in Abhängigkeit davon variieren.