Ja ok, in DevOps unterscheiden wir zwischen deployen und releasen. Der Release ist sozusagen nur noch der Knopfdruck, um eine Funktion den Benutzerinnen und Benutzer zur Verfügung zu stellen. Aber auch bei zwei Deployments pro Jahr muss ich geduldig auf Feedback warten.
In DevOps wollen wir kurze und etablierte Feedback-Schleifen, um Probleme aufgrund von Fehlern oder unterschiedlichem Verständnis dann zu lösen, wenn sie auftreten. Das sagt uns nicht nur der gesunde Menschenverstand, sondern auch die drei Wege von DevOps:
- Erster Weg: Systemdenken und einen kontinuierlichen, schnellen Fluss ermöglichen - von der Idee bis zum Kunden
- Zweiter Weg: Feedback Loops verstärken
- Dritter Weg: Eine Kultur von kontinuierlichem Experimentieren und Lernen etablieren
Das Auftreten von Problemen und das Erkennen von Problemen kann zeitlich verschoben sein. Wenn bei einer Diskussion ein Missverständnis auftritt, können durchaus Tage, Wochen oder Monate vergehen, bis wir das Missverständniss erkennen (wenn überhaupt).
Um Software und Produkte zu bauen, die unserem Qualitätsanspruch genügen, ist es deshalb zentral, Mechanismen zu implementieren, die das schnelle Erkennen von Problemen unterstützen.
Dafür gibt es viele methodische und technische Möglichkeiten wie zum Beispiel:
Die allerbeste Möglichkeit ist aber:
Zusammenarbeit!
GitLab Review Apps
Funktionsweise
Und genau um diese Zusammenarbeit dreht es sich bei GitLab Review Apps. Sie sollen die Zusammenarbeit zwischen Entwicklung und Fachabteilung und Kundschaft fördern und den Feedback Loop verkürzen.
GitLab Review Apps sind Deployments, welche direkt mit einem Merge Request (GitLabs Version eines Pull Requests) verknüpft sind. Merge Request kreieren zudem einen Feature Branch. Sobald du eine Änderung auf den Feature Branch commitest, deployed GitLab (sofern die automatisierten Tests erfolgreich waren) den Feature Branch auf eine eigene (dynamische) Umgebung.
Anschliessend hat man die Möglichkeit, die Änderung auf der dezidierten Umgebung zu testen, Feedback zu geben und allfällige Korrekturen gleich wieder zu testen. Kürzer kann ein Feedback Loop kaum sein.
Sobald die Änderung freigeben wurde, führt GitLab die Änderungen des Feature Branches mit dem Master Branch zusammen (merge), räumt die dynamische Umgebung ab und schliesst den Merge Request.
Vorteile
- Frühes erkennen von Fehlern und Missverständnissen
Änderungen können von Fachpersonen oder Kundinnen und Kunden sofort verifiziert werden. - Zusammenarbeit über Grenzen hinweg
Mit dem Merge Request als Basis arbeiten Menschen aus unterschiedlichen Abteilungen/Teams/Unternehmen und mit unterschiedlichen Fähigkeiten zusammen - Release-Risiko reduzieren
Im Wissen über bereits getestete Features reduziert sich das Risiko von Fehler, wenn der Master Branch deployed oder released wird. - Kontinuierliches Testen
Neue Funktionen und Änderungen werden kontinuierlich sowohl automatisch wie auch manuell getestet und verifiziert. Damit gehört arbeits- und nervenintensives Testen während zusammengekürzten Testphasen der Vergangheit an.
Voraussetzung
Deine App sollte eine Webapplikation sein und du brauchst die Infrastruktur, auf welche die Review Apps deployed werden. Dazu gehört auch ein Kubernetes Cluster.
Was du nicht brauchst ist Geld (zumindest für GitLab Lizenzen). Review Apps sind auf allen Lizenzstufen - von Free bis Ultimate - verfügbar.
Der einfachste Weg geht über die (auch sehr erwähnenswerte) Auto DevOps Funktion. Ist Auto DevOps aktiviert, erkennt GitLab deine Programmiersprache und kreiert darauf basierend und mit Hilfe von Templates Default-Pipelines, um die App zu builden und zu testen.
Übrigens: Die Auto DevOps Konfigurationen lassen sich jederzeit auf die eigenen Bedürfnisse anpassen.
Kurzanleitung für die Minimum Voraussetzungen:
1. GitLab Saas oder GitLab onPrem (z.b. via unserem Managed GitLab Hosting)
2. Ein GitLab Projekt (Repository)
3. Kubernetes Cluster mit Ingress
4. GitLab Agent im Kubernetes Cluster
5. In den Projekteinstellung → CI/CD → Variablen
- KUBE_CONTEX Variable mit Wert <Projektpfad>:<Agent Name>
- KUBE_INGRESS_BASE_DOMAIN Variable mit IP-Adress auf deinen Kubernetes Cluster
6. Aktiviertes Auto DevOps in deinem GitLab Projekt
Hands-on
Lass uns gemeinsam anschauen, wie das nach getaner Arbeit ausschaut.
In GitLab erstelle ich ein neues Projekt basierend auf dem NodeJS Express Template. Das gibt mir eine minimale Webapplikation.
Ale erstes aktiviere ich im neuen Projekt Auto DevOps in den CI/CD Einstellungen.
Daraufhin kreiert mir GitLab eine Pipeline für den Master-Branch. Hier können wir bereits die verschiedenen, von Auto DevOps angelegten Jobs für das Testen meiner Applikation sehen.
Nachdem der Job “production” die App erfolgreich auf meinen Kubernetes Cluster deployed hat (in diesem Beispiel in der Google Cloud), kann ich die App aufrufen.
Nun wollen wir einen besseren Titel haben. Zu diesem Zweck eröffne ich einen Issue im Projekt. Issues werden in GitLab dafür verwendet, Änderungen zu planen und können auch in Board und auf Roadmaps dargestellt werden.
Basierend auf dem Issue erstelle ich einen neuen Merge Request. Im Merge Request werden die notwendigen Änderungen vorgenommen. Wir sehen auf dem folgenden Bild, dass ein neuer Feature-Branch “1-change-title” von GitLab erstellt wird.
Ich öffne auf dem Merge Request die in GitLab integrierte Web IDE für die Code Änderung.
Ich ändere den Titel (index.js) auf “Review Apps are cool!! und den Testfall (test.js), welcher die korrekte Wiedergabe des Titels testet.
Nach dem Commit der Änderung läuft auf dem Feature-Branch die von Auto DevOps zusammengestellte Pipeline. Für meine test.js hat GitLab einen eigenen Job kreiert. Die Review-App wird im Job “review” deployed.
Nachdem der Job “review” erfolgreich durchgelaufen ist, sehe ich auf dem Merge Request einen Button, um die Review App anzuschauen.
Ein kurzer Blick auf unser Kubernetes Cluster zeigt, dass wir nebst der Produktion nun auch eine “review-1-change” Umgebung am Laufen haben.
Mit Klick auf den “View App” Button, öffnet die Review App mit meinen Änderungen (hier mit zwei Ausrufezeichen im Gegensatz zum Code von oben, weil mit dem Kubernetes Cluster noch etwas nicht gestimmt hat und ich nochmals etwas commiten musste)
Es schaut alles so aus, wie erwartet, darum merge ich den Merge Request nun in den Master. Nachdem ich den entsprechenden Button auf dem Merge Request geklickt habe (Mark as ready → Merge), räumt zuerst die Feature-Branch Pipeline die Review App Umgebung auf (sprich, fährt sie herunter), bevor die Änderungen in den Master gemerged werden.
Die Master Pipeline steht schon bereit (siehe unten im Bild) und wird von GitLab gestartet, sobald das Aufräumen erledigt ist.
Nachdem die Master Pipeline die Änderungen gemerged und auf die Produktion im Kubernetes Cluster deployed hat, ist unsere geändert App produktiv.
Ein Blick auf unser Kubernetes Cluster zeigt, dass nur noch die Produktion am Laufen ist und die Review App nicht mehr.
Zusammenfassung
Review Apps von GitLab verkürzen den Feedback Loop zwischen den unterschiedlichen Beteiligten und helfen uns so, in einer frühen Phase Probleme zu identifizieren und lösen. Das wieder steigert die Qualität des gesamten Produktes.
Wenn ihr Fragen zu Review Apps, Auto DevOps oder GitLab habt, dann wendet euch gerne an uns.
Euer
Beni
