Bei GitLab verarbeiten wir Softwarekorrekturen auf zwei Arten: manuell und automatisch. Lesen Sie weiter, um mehr über die Aufgabe des Release-Managers zu erfahren, wichtige Updates über die automatisierte Bereitstellung auf gitlab.com zu erstellen und bereitzustellen, sowie Patches, mit denen Benutzer an ihren eigenen Installationen arbeiten können.
Ich empfehle, eine Erinnerung auf Ihrer Smartwatch einzurichten: Jeden 22. Monat im Monat können Benutzer, die in ihren Einrichtungen mit GitLab arbeiten, Updates zur aktuellen Version unseres Produkts sehen. Die monatliche Veröffentlichung enthält neue Funktionen, Weiterentwicklungen bestehender Funktionen und zeigt häufig das Endergebnis von Community-Anfragen nach Tools oder Zusammenführungen.
Doch wie die Praxis zeigt, verläuft die Softwareentwicklung selten fehlerfrei. Wenn ein Fehler oder eine Sicherheitslücke entdeckt wird, erstellt der Release-Manager im Bereitstellungsteam einen Fix für unsere Benutzer mit ihren Installationen. Gitlab.com wird während des CD-Vorgangs aktualisiert. Wir nennen diesen CD-Prozess automatische Bereitstellung, um Verwechslungen mit der CD-Funktion in GitLab zu vermeiden. Dieser Prozess kann Vorschläge aus Pull-Requests einbeziehen, die von Benutzern, Kunden und unserem internen Entwicklungsteam eingereicht wurden, sodass die Lösung des langweiligen Problems der Veröffentlichung von Patches auf zwei sehr unterschiedliche Arten gelöst wird.
«Wir stellen sicher, dass alles, was Entwickler machen, jeden Tag in allen Umgebungen bereitgestellt wird, bevor es auf GitLab.com bereitgestellt wird", erklärt , Senior Technical Manager, Infrastrukturabteilung. "Stellen Sie sich Releases für Ihre Installationen als Snapshots für gitlab.com-Bereitstellungen vor, für die wir separate Schritte zum Erstellen eines Pakets hinzugefügt haben, damit unsere Benutzer es zur Installation auf ihren Installationen verwenden können".
Unabhängig vom Fehler oder der Schwachstelle erhalten Kunden von gitlab.com die Korrekturen kurz nach der Veröffentlichung, was ein Vorteil des automatisierten CD-Prozesses ist. Patches für Benutzer mit eigenen Installationen bedürfen einer gesonderten Vorbereitung durch den Release Manager.
Das Bereitstellungsteam arbeitet intensiv daran, die meisten Prozesse bei der Erstellung von Releases zu automatisieren, um sie zu reduzieren (mittlere Zeit bis zur Produktion, d. h. die für die Produktion aufgewendete Zeit), der Zeitraum von der Bearbeitung einer Zusammenführungsanforderung durch einen Entwickler bis zur Bereitstellung auf gitlab.com.
«Das Ziel des Lieferteams besteht darin, sicherzustellen, dass wir als Unternehmen schneller vorankommen oder zumindest dafür sorgen, dass die Lieferleute schneller arbeiten, richtig?, sagt Marin.
Sowohl Kunden von gitlab.com als auch Benutzer ihrer Installationen profitieren von den Bemühungen des Bereitstellungsteams, Zykluszeiten zu verkürzen und Bereitstellungen zu beschleunigen. In diesem Artikel erklären wir die Gemeinsamkeiten und Unterschiede zwischen diesen beiden Methoden. Außerdem beschreiben wir, wie unser Bereitstellungsteam Patches für Benutzer vorbereitet, die an ihren Einrichtungen arbeiten, und wie wir durch automatisierte Bereitstellung sicherstellen, dass gitlab.com auf dem neuesten Stand ist.
Was macht ein Release-Manager?
Teammitglieder monatlich unsere Veröffentlichungen an Benutzer in ihren Einrichtungen, einschließlich Patches und Sicherheitsveröffentlichungen, die zwischen Veröffentlichungen auftreten können. Sie sind auch dafür verantwortlich, den Übergang des Unternehmens zur automatisierten, kontinuierlichen Bereitstellung zu leiten.
Selbstinstallationsversionen und gitlab.com-Versionen verwenden ähnliche Arbeitsabläufe, werden jedoch zu unterschiedlichen Zeiten ausgeführt, erklärt Marin.
In erster Linie stellt der Release-Manager unabhängig vom Release-Typ sicher, dass GitLab ab dem Start der Anwendung auf gitlab.com verfügbar und sicher ist, und stellt unter anderem sicher, dass dieselben Probleme nicht in der Infrastruktur der Kunden landen eigene Kapazitäten.
Sobald ein Fehler oder eine Schwachstelle in GitLab als behoben markiert wird, muss der Release-Manager bewerten, ob er in den Patches oder Sicherheitsupdates für Benutzer in ihren Installationen enthalten sein wird. Wenn er entscheidet, dass ein Fehler oder eine Schwachstelle ein Update verdient, beginnt die vorbereitende Arbeit.
„Der Release-Manager muss entscheiden, ob er einen Fix vorbereitet oder wann er ihn bereitstellt – und das hängt stark vom Kontext der Situation ab“,Mittlerweile können Maschinen den Kontext nicht so gut verwalten wie Menschen", sagt Marin.
Es geht nur um die Korrekturen
Was sind Patches und warum brauchen wir sie?
Der Release-Manager entscheidet anhand der Schwere des Fehlers, ob ein Fix veröffentlicht wird.
Fehler variieren je nach Schweregrad. S4- oder S3-Fehler können also stilistischer Natur sein, etwa Pixel- oder Symbolverschiebungen. Dies ist nicht weniger wichtig, hat aber keine wesentlichen Auswirkungen auf den Arbeitsablauf von irgendjemandem, was bedeutet, dass die Wahrscheinlichkeit, dass für solche S3- oder S4-Fehler ein Fix erstellt wird, gering ist, erklärt Marin.
Die Sicherheitslücken S1 oder S2 bedeuten jedoch, dass der Benutzer nicht auf die neueste Version aktualisieren sollte, oder es liegt ein erheblicher Fehler vor, der den Arbeitsablauf des Benutzers beeinträchtigt. Wenn sie im Tracker enthalten sind, sind sie vielen Benutzern begegnet, sodass der Release-Manager sofort mit der Vorbereitung eines Fixes beginnt.
Sobald ein Patch für die Schwachstellen S1 oder S2 fertig ist, beginnt der Release-Manager mit der Veröffentlichung des Patches.
Beispielsweise wurde der GitLab 12.10.1-Patch erstellt, nachdem mehrere Blockierungsprobleme identifiziert wurden und die Entwickler das zugrunde liegende Problem behoben hatten, das sie verursachte. Der Release-Manager bewertete die Richtigkeit der zugewiesenen Schweregrade und nach der Bestätigung wurde der Prozess zur Veröffentlichung eines Fixes gestartet, der innerhalb von XNUMX Stunden nach Entdeckung der Blockierungsprobleme bereit war.
Wenn sich viele S4-, S3- und S2-Fixes ansammeln, prüft der Release-Manager den Kontext, um die Dringlichkeit der Veröffentlichung eines Fixes zu bestimmen. Wenn eine bestimmte Anzahl davon erreicht ist, werden sie alle zusammengefasst und veröffentlicht. Korrekturen oder Sicherheitsupdates nach der Veröffentlichung werden in Blogbeiträgen zusammengefasst.
Wie ein Release-Manager Patches erstellt
Wir nutzen GitLab CI und andere Funktionen wie unsere ChatOps, um Patches zu generieren. Der Release-Manager startet die Veröffentlichung des Fixes, indem er das ChatOps-Team auf unserem internen Kanal aktiviert #releases in Slack.
/chatops run release prepare 12.10.1ChatOps löst innerhalb von Slack verschiedene Ereignisse aus, die dann von GitLab verarbeitet und ausgeführt werden. Das Bereitstellungsteam hat beispielsweise ChatOps eingerichtet, um verschiedene Dinge zur Veröffentlichung von Patches zu automatisieren.
Sobald der Release-Manager das ChatOps-Team in Slack startet, erfolgt der Rest der Arbeit automatisch in GitLab mit CICD. Während des Release-Prozesses gibt es eine bidirektionale Kommunikation zwischen ChatOps in Slack und GitLab, da der Release-Manager einige der wichtigsten Schritte im Prozess aktiviert.
Das folgende Video zeigt den technischen Prozess der Vorbereitung eines Patches für GitLab.
So funktioniert die automatische Bereitstellung auf gitlab.com
Der Prozess und die Tools zum Aktualisieren von gitlab.com ähneln denen zum Erstellen von Patches. Das Aktualisieren von gitlab.com erfordert aus Sicht des Release-Managers weniger manuelle Arbeit.
Anstatt Bereitstellungen mit ChatOps auszuführen, verwenden wir CI-Funktionen, z. B. , mit dem der Release-Manager die Ausführung bestimmter Aktionen zum gewünschten Zeitpunkt einplanen kann. Anstelle eines manuellen Prozesses gibt es eine Pipeline, die regelmäßig einmal pro Stunde ausgeführt wird und die neuen Änderungen an GitLab-Projekten herunterlädt, sie verpackt, die Bereitstellung plant und automatisch Tests, Qualitätssicherung und andere notwendige Schritte durchführt.
„Wir haben also viele Bereitstellungen in verschiedenen Umgebungen vor gitlab.com ausgeführt, und nachdem diese Umgebungen in einem guten Zustand sind und die Tests gute Ergebnisse zeigen, startet der Release-Manager die Bereitstellungsaktionen für gitlab.com“, sagt Marin.
Die CICD-Technologie zur Unterstützung von gitlab.com-Updates automatisiert den gesamten Prozess bis zu dem Punkt, an dem der Release-Manager die Bereitstellung der Produktionsumgebung auf gitlab.com manuell starten muss.
Marin geht im folgenden Video ausführlich auf den Aktualisierungsprozess von gitlab.com ein.
Was macht das Lieferteam sonst noch?
Der Hauptunterschied zwischen den Update-Prozessen von gitlab.com und der internen Veröffentlichung von Patches für Kunden besteht darin, dass letzterer Prozess mehr Zeit und mehr manuelle Arbeit vom Release-Manager erfordert.
„Manchmal verzögern wir die Veröffentlichung von Patches für Kunden mit ihren Installationen aufgrund gemeldeter Probleme, Tool-Problemen und weil es viele Nuancen gibt, die bei der Veröffentlichung eines einzelnen Patches berücksichtigt werden müssen“, sagt Marin.
Eines der kurzfristigen Ziele des Bereitstellungsteams besteht darin, den manuellen Arbeitsaufwand des Release-Managers zu reduzieren, um die Veröffentlichung zu beschleunigen. Das Team arbeitet daran, den Veröffentlichungsprozess zu vereinfachen, zu rationalisieren und zu automatisieren, um Lösungen für Probleme mit geringem Schweregrad (S3 und S4, ca. Übersetzer). Der Fokus auf Geschwindigkeit ist ein wichtiger Leistungsindikator: Es ist notwendig, MTTP – die Zeit vom Empfang einer Zusammenführungsanforderung bis zur Bereitstellung des Ergebnisses auf gitlab.com – von derzeit 50 Stunden auf 8 Stunden zu reduzieren.
Das Bereitstellungsteam arbeitet außerdem an der Migration von gitlab.com auf eine Kubernetes-basierte Infrastruktur.
Anmerkung des Herausgebers:: Wenn Sie bereits von der Kubernetes-Technologie gehört haben (und daran habe ich keinen Zweifel), sie aber noch nicht selbst in die Hand genommen haben, empfehle ich die Teilnahme an Online-Intensivkursen , die vom 28. bis 30. September stattfinden wird, und , die vom 14. bis 16. Oktober stattfinden wird. Dies ermöglicht Ihnen eine sichere Navigation und Arbeit mit der Technologie.
Dabei handelt es sich um zwei Ansätze, die das gleiche Ziel verfolgen: schnelle Bereitstellung von Updates, sowohl für gitlab.com als auch für die Kunden vor Ort.
Irgendwelche Ideen oder Empfehlungen für uns?
Jeder ist willkommen, einen Beitrag zu GitLab zu leisten, und wir freuen uns über das Feedback unserer Leser. Wenn Sie Ideen für unser Lieferteam haben, zögern Sie nicht markiert team: Delivery.
Source: habr.com