Schnelle Produktbereitstellung mit GitLab
Bei GitLab-Control-Page handelt es sich um ein Pipeline-Management-System
Bei GitLab-Control-Page handelt es sich um ein Pipeline-Management-System, das benötigte Build Pipelines startet und im Rahmen des Version-Control-Systems GitLab zur Anwendung kommt. Im Gegensatz zum herkömmlichen Start der Pipelines mittels der GitLab GUI oder der Konsole ist mit den im Framework angepassten Formularen ein schnellerer und fehlerfreierer Pipeline-Start möglich.
Variablen und Parameter müssen nicht mehr geschrieben und auf Richtigkeit überprüft werden, sondern können einfach angeklickt werden.
Keine Rechtschreibfehler mehr möglich. Eine unsinnige Zusammenstellung von Parametern und Variablen wird von vornherein ausgeschlossen.
Mitarbeiterinnen und Mitarbeiter, die noch nicht alle Environment-Variablen kennen, die zur Erstellung manueller Pipelines benötig werden, sparen Zeit. An dieser Stelle wird auch die Einarbeitungszeit verkürzt.
Dank intuitiver Bedienung und übersichtlicher Oberflächengestaltung kann sofort mit dem Framework gearbeitet werden.
Wir setzen GitLab als Versionskontrollsystem ein und nutzen GitLab Pipelines, um den Entwicklungs- und Bereitstellungsprozess unserer Anwendungen zu automatisieren und zu vereinfachen.
Die Vielzahl an Feature Requests und Code-Weiterentwicklungen in den Developer-Teams führen zu einem hohen täglichen Aufkommen an Code Builds für den Debugging-, den QA-Test-, den Developer- und den Produktionsbereich. Jede und jeder Developer und die QA-Mitarbeitenden benötigen zahlreiche immer wieder neu gebaute App-Versionen, um sie optimieren und testen zu können.
Auf herkömmliche Weise würde eine bzw. ein Developer den Code im System manuell bauen und gegentesten. Diese Vielzahl an Analysen und Tests sind zeitintensiv und blockieren Ressourcen. Außerdem sind die Gesamtmetriken aller Tests und Durchläufe nirgendwo festgehalten. Mögliche Firmen-, Code- und generell Security-Tests würden nicht zu 100 % berücksichtigt werden.
Daher hat sich das Verwenden von automatisierten Build Pipelines durchgesetzt, um den Teams die komplexen Aufgaben abzunehmen und ihnen fertig gebaute Apps sowie deren Vielzahl an erstellten Reports und Logs zur Verfügung zu stellen.
Diese Pipeline Runner (sog. Agenten), welche mit Hilfe der automatisierten Pipeline Scripte die benötigten Builds bauen, sind skalierbar und können den jeweiligen Ressourcen, den Anforderungen und der Ausfallsicherheit angepasst werden. Da die Aufgabe an eine zentrale IT abgegeben wird, haben die Entwicklerinnen und Entwickler keine weitere lokale Belastung auf ihren Systemen. Auch erhalten sie ihre Ergebnisse auf diese Art wesentlich schneller. Ein weiterer Vorteil ist das zeitliche Planen von wiederkehrenden täglichen Aufgaben, die mit den automatisierten Pipelines bereits in der Nacht geplant und abgearbeitet werden können.
Nicht alle automatisierten Pipelines können ohne die Vorgabe eines Grund-Setups durch die Entwicklungsbereiche einfach gestartet werden. Hierzu sind je nach benötigtem Anwendungsfall zahlreiche und individuelle Parameter nötig, wie z.B. das zu testende Land, die Sprache, der Versionsstand, externe zu testende Anbindungen oder Test-User sowie deren Daten-Sets und vieles mehr. Alle diese Parameter müssen in GitLab im Klartext eingegeben werden. Die Praxis zeigte jedoch, dass dieses Vorgehen zeitaufwendig und enorm fehleranfällig war: Rechtschreibfehler oder Versionskonflikte bzw. Konflikte zwischen den Variablen führten nicht zu den gewünschten Software–Kompilierungen – oder Builds wurden gar nicht erst erstellt. Es kam der Gedanke auf, eine eigene Plattform zu entwickeln, auf der unsere Entwicklerteams schnell und einfach ein Setup definieren oder ggf. ein Pre-Setup auswählen können, um dann eine automatisierte Pipeline zu starten.
Wir benötigten ein einfach und günstig zu wartendes Inhouse-Framework, welches unsere individuellen Bedürfnisse intern abdeckt und benötigte Build Pipelines möglichst ohne Angabe von fehlerhaften Parameter-Settings startet. Es sollte möglich sein, über Formulare in einer Web-Anwendung einen spezifischen Entwicklungszweig (Branch) auszuwählen, für welchen die Pipeline ausgeführt werden soll. Eine Liste aller verfügbaren Branches eines Projekts sollte über einen API-Aufruf vorab befüllt werden. Im Anschluss daran sollten Variablen mittels Auswahllisten und Eingabefeldern zusammengestellt und diese wiederum per API-Aufruf an den GitLab-Server weitergeleitet werden. Das System sollte leicht und schnell erweiterbar sein, sich selbsterklärend in der Bedienung zeigen und ggf. Hinweise zur korrekten Anwendung geben. Falscheingaben sollten gegengeprüft und mit einem Hinweis verwehrt werden. Im Falle des Starts einer Pipeline sollte der Entwicklerin bzw. dem Entwickler die Pipeline genannt werden, um den weiteren Verlauf und den Status der Pipeline selbst einsehen zu können.
Unsere Herangehensweise
Weitere Details zu unserer Lösung und den daraus resultierenden Egebnissen erhalten Sie, indem Sie sich über den Button exklusiven Zugang sichern.
Wir haben uns für ein einfaches Framework mit HTML5 und JavaScript mit der JQuery Bibliothek entschieden. Dies ermöglicht uns, ein breites Spektrum an Inhouse-Entwicklerinnen und -Entwicklern einzubeziehen, welche das Produkt mitgestalten und aktualisieren können. Die jeweiligen zu benutzenden Bereiche wurden in einzelne Websites der jeweiligen Anwenderbereiche klar unterteilt: Android und IOS, QA, Device Registration und Monitoring.
Alle Teammitglieder haben über ein vorgefertigtes Formular die Möglichkeit, durch einfaches Selektieren und Auswählen der benötigten Settings die jeweilige Pipeline starten zu lassen. Im Gegensatz zum herkömmlichen Start der Pipelines mittels der GitLab GUI oder der Konsole ist dank des Frameworks mit den angepassten Formularen ein schnellerer und fehlerfreierer Vorgang möglich. So können Berechnungen zufolge pro Person, die Pipelines in GitLab startet, mit der neuen Plattform ca. 4,5 Stunden pro Monat eingespart werden. Und dass nur, weil Settings und Variablen nicht mehr im Klartext eingegeben werden müssen, sondern vorgebeben und auswählbar sind.
Der eigentliche technische Start der Pipeline wird über einen simplen API Request und den zu übergebenden Parametern an den Gitlab-Server gesendet. Die komplexeren Build Pipelines können dann zusammen mit den übergebenen Parametern den jeweiligen individuellen benötigten Build fertigstellen.
Die Verwendung von GitLab-Pipelines hat unserem Team geholfen, einen automatisierten, zuverlässigen und konsistenten Prozess zur Überprüfung und Bereitstellung von Änderungen an Anwendungen zu implementieren. Dies hat dazu beigetragen, die Anzahl der Fehler in der Produktion zu minimieren und den Entwicklungs- und Bereitstellungsprozess zu beschleunigen.
Doch wenn die Settings der Pipelines, die Build-Versionen und Anwendungsfälle komplexer werden, ist es von Vorteil, statt des klassischen Weges, Pipelines über die mitgelieferte GitLab GUI zu starten, eine gemeinsame Plattform zu nutzen, die das Starten durch vorgegebene Settings und Variablen insgesamt schneller und fehlerfreier ermöglicht. Nach einer kurzen Einführung und Testzeit wurde das Framework von unseren Entwicklerteams schnell angenommen. Neue Teammitglieder haben es wesentlich einfacher, ein komplexes Setup zu starten. Es wurden bereits weitere Wünsche an das Framework geäußert und gemeinsam adaptiert, woraus auch die allgemeine Akzeptanz aller Mitarbeitenden und der Mehrwert in der Zusammenarbeit ersichtlich wird.
GitLab selbst arbeitet weiterhin intensiv an seinem Produkt, um ihre eigenen möglichen Parameter-Eingabemöglichkeiten zu optimieren. An den hohen Grad unseres individualisierten Frameworks und der einhergehenden Zeitersparnis sowie dem Grad der Vereinfachung kommt die Optimierung von GitLab jedoch nicht heran.
Möchten Sie mehr über unsere Arbeitsweise erfahren?
Dann kontaktieren Sie uns, um zu erfahren, wie unsere agilen, innovativen, cross-funktionalen Teams arbeiten und digitale Produkte und Erlebnisse kreiert haben. Wir freuen uns auf den Austausch!