Seminararbeit_2020/pandoc/mass.tex

4. Empfehlungen für die Planung und Implementierung von CI/CD

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.

4.1Planung eines CI/CD Systems

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.

4.1.1 Frage nach dem Umfang der Automatisierung und den Objekten der
Automatisierung

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

\textbf{Build-Prozess} (Compile, ggf, Multimudulcompiling und
Containerbau),

\textbf{Testprozess} (Modul, Integrations- und Systemtest),

\textbf{Analyseprozess} (statisch oder dynamische Codeanalyse,
Dependencyanalyse, Lizenzscan, Containersicherheitsanalyse)

\textbf{Delivery} oder \textbf{Deployment}

Die detaillierte Definition der \textbf{Inputschnittstelle} für das
CI/CD System (z.B. xxxx ) 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.

\textbf{4.1.2 Definition der Zielumgebung für Artefakte oder Software}

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.

\textbf{4.1.3 Design des CI/CD Systems}

4.1.3.1 Toolauswahl

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 4.1.1 und 4.1.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.

4.1.3.2 Design im Toolkontext

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 4./3xx
dargestellt.

4.1.4 Festlegung der Hardware für das CI/CD System

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.

4.2 Dokumentation

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 Integrations-(xxx oben definieren) und Automatisierungsteam(xxxoben
definiern).

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 den CI/CD Engine,
(xxx bei der automatisierung -- vielleicht auch tools und ) eingesetzte
Tools und deren Interfaces und über die Konfiguration des aktuellen
Systems, um den Betrieb und die Wartung für das Automatisierungsteam zu
ermöglichen.

Bei Störungen im CI/CD System kann diese Dokumentation helfen, das
System wiederherzustellen bzw. sogar extern als Workaround zu betreiben
(durch Verfassung der einzelnen CI/CD Schritte in Einzelscripten).

4.3 technische Maßnahmen

4.3.1 Lösungsansätze zur Umsetzung der Maßnahmen

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
Policies 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{(B06 -- unzureichende Tests -- ungetesteter Code in Produktion)}

Weitere Beispiele sind die Verhinderung einer ungewollten Ausführung
eines Releases \emph{(B04 -- ungewolltes Aktivieren der Pipeline durch
unbewusste Nutzung des Masterbranch),} deren Umsetzung im
Anschlusskapitel an einer konkreten Systemumgebung aufgezeigt wird.

Die ungewollte Ausführung eines unorchestrierten Containers ist ein
Problem, welches ebenfalls durch technische Maßnahmen vermieden werden
kann.(einbisschen andeuten wieexxx)

Auch im \textbf{Speichermanagement} gibt es Möglichkeiten, den \emph{in
(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.

So können auch \textbf{Konflikte}, welche durch eine \textbf{parallele
Ausführung} zweier Pipelines entstehen, mit Hilfe von technischen
Vorkehrungen erkannt werden und zum Stopp der Pipeline führen. (andeuten
wie xx)

\textbf{4.3.2 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.

\textbf{4.3.2.1 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.

\textbf{4.3.2.1 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.

\textbf{4.3.2.1 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.