Warum die Technologie zur Zusammenarbeit von GitLab für GitOps entscheidend ist: Eine Demo
Software für die Zusammenarbeit (wie GitLab) erleichtert GitOps-Workflows. Der Artikel enthält eine Demo, die zeigt, wie GitLab GitOps durch Zusammenarbeit unterstützt.
GitOps bezieht sich auf die Verwendung eines Git-Repositorys als Single Source Of Truth für den gesamten Code, der in den Aufbau der Infrastruktur und die Bereitstellung von Anwendungen fließt. Durch die Verwendung eines Versionskontrollsystems wie Git als einzige Quelle der Wahrheit sind Entwickler(innen) in der Lage, den zugrunde liegenden Quellcode für ihre Anwendungen in einem Continuous-Delivery-Format zu aktualisieren.
Das System der Versionskontrolle sorgt für Dokumentation und Transparenz, während ein Audit-Trail die Einhaltung der Vorschriften ermöglicht. Mit GitOps kannst du Änderungen ganz einfach rückgängig machen. Es bietet außerdem einen zentralen Ort für den Zugriff auf die aktuellsten Informationen, damit Teams den aktuellen Status sowohl aus der Perspektive der Softwareentwicklungs- als auch der Betriebsteams im Blick haben können.
GitLab ist eine einzelne Anwendung für den gesamten DevOps-Lebenszyklus und dient als Zusammenarbeitsplattform, die es den Stakeholdern ermöglicht, sich am Code-Produktionsprozess zu beteiligen. Die Zusammenarbeit ist ein wichtiger Aspekt des GitOps-Prozesses, denn die Teams des gesamten Entwicklungslebenszyklus – von den Infrastruktur- und Entwicklungsteams bis hin zu den Sicherheits- und Business-Stakeholdern – benötigen eine nahtlose Methode zur Zusammenarbeit, um den Code schnell und effizient bereitzustellen.
Bei GitOps geht es nicht nur um die Programmierung, sondern auch um die Zusammenarbeit. GitLab ermöglicht es jedem Team, auf einer einzigen Plattform zu arbeiten.
Der verbleibende Artikel enthält eine Demo, die zeigt, wie GitLab GitOps durch Zusammenarbeit unterstützt. Die Demo umfasst Beispiele für Epics und Tickets, die in den folgenden Abschnitten verlinkt werden.
Projektplanung mit Epics
Da sich die Bereitstellung von GitOps auf die Versionskontrolle konzentriert, müssen in einem ersten Schritt der Umfang des Projekts definiert und die Beteiligten bestimmt werden. Als Nächstes können die Teammitglieder alle anderen Informationen austauschen, die für die Umsetzung des Projekts notwendig sind, z. B. Programmierung, Änderungen an der Infrastructure as Code, welche Änderungen überprüft und schließlich für die Produktion bereitgestellt werden müssen.
Nachdem ein Epic im zugehörigen Repository geöffnet wurde, können Teams Ziele und Aufgaben in der Beschreibung hinzufügen. Ein Epic ermöglicht es Teams, Issues (oder Tickets) über verschiedene Projekte und Meilensteine hinweg zu verfolgen. Ein Issue ist das wichtigste Medium für die Zusammenarbeit bei Ideen und die Planung von Arbeit in GitLab.
Beispiel für Epic und Issues
In diesem Beispiel-Epic mit dem Namen Scale the Cloud können Teams den Prozess hinter der Skalierung eines Kubernetes-Clusters in GitLab einsehen. Da GitLab eine Multicloud-Umgebung ist, gibt es für die Demo drei separate Themen, die beschreiben, was für die Bereitstellung des Kubernetes-Clusters in jeder einzelnen Umgebung erforderlich ist: Azure (AKS), Google (GKE) und Amazon (EKS).
Förderung der Zusammenarbeit und Transparenz mit GitLab
Auf der Epic-Ebene können die Teams sehen, dass das Issue für die Skalierung innerhalb des EKS-Clusters bereits fertiggestellt wurde. Wenn du auf das Issue klickst, siehst du, dass ein Merge Request aus den im Issue beschriebenen Aufgaben erstellt wurde und dass der MR bereits zusammengeführt wurde.
Um zu sehen, was genau sich zwischen dem ursprünglichen und dem aktuellen Code geändert hat, klicke auf den MR. Von hier aus können die Teams alle Tests sehen, die vor und nach der Zusammenführung erfolgreich durchgeführt wurden, den Kommentarverlauf einsehen, um Änderungen zu erkennen, und sehen, wer den Code genehmigt und zusammengeführt hat.
Das Ticket für die Skalierung auf GKE ist noch nicht abgeschlossen. Der Merge Request ist immer noch in Bearbeitung (WIP), das heißt, es wurde noch nichts geändert. Es gibt einen Kommentar zum MR von Terraform, der zeigt, dass die Anzahl der Knoten von zwei auf fünf erhöht werden muss, um die GKE-Umgebung für die Bereitstellung vorzubereiten. Die Person, die den MR genehmigt, klickt auf Resolve the WIP Status, um die Pipeline zu starten, und kann sich entscheiden, den Quellbranch zu löschen, um die aktualisierte Node-Anzahl zusammenzuführen.
Damit GitLab ein effektives Tool für die Zusammenarbeit ist, muss es auch transparent sein. Deshalb kann jeder in der Organisation standardmäßig ein Issue und den dazugehörigen MR sehen. Das Ticket und der MR können jemandem im Team zugewiesen werden, oder jemand kann im Kommentarbereich markiert werden, um ihn zur Aufgabenliste hinzuzufügen.
Wenn du zur Epic-Ansicht zurückkehrst, die die Stakeholder oft verwenden, um den Projektfortschritt zu sehen, können die Teams sehen, dass die Bereitstellung für die Skalierung von GKE auf fünf Knoten im Gange ist.
Durch den Einsatz von GitLab für einen GitOps-Workflow kann jedes Teammitglied mit demselben System arbeiten und den Status der Projekte einsehen. Ob in der Infrastruktur oder in der Anwendungsentwicklung, alle Änderungen folgen demselben Prozess: Definition des Arbeitsumfangs, Zuweisung an einzelne Personen, Zusammenarbeit mit anderen Teammitgliedern und Bereitstellung des Codes, wobei das Git-Repository als einzige Quelle der Wahrheit dient.
Bist du bereit?
Sieh dir an, was dein Team mit einer einheitlichen DevSecOps-Plattform erreichen könnte.