Da unser Lieferteam nur unsere eigenen Ressourcen verwendet, hat es unser System unter CI / CD überarbeitet.
Ingenieurteams stehen ständig unter Druck: Sie müssen neue Funktionen in Form eines würdigen Produkts herausgeben und gleichzeitig die Zykluszeit ständig minimieren. Oft greifen Experten ohne zu greifen nach modernen Werkzeugen. Continuous Integration and Delivery (CI / CD) ist in GitLab, unserer einzigen DevOps-Lifecycle-Anwendung, integriert. Jetzt migrieren wir zu Kubernetes, um die Zykluszeit noch weiter zu verkürzen. Zum CI / CD - und letztendlich zu Kubernetes - gingen wir jedoch einen eher ungewöhnlichen Weg. Das Delivery-Team , das uns auf die kontinuierliche Lieferung von GitLab.com umstellte, belastete das alte System, und erst dann wechselten wir vollständig zu Kubernetes.
Wie wir Veröffentlichungen vor CI / CD veröffentlicht haben
Zwischen dem 7. August und dem 27. September 2019 erreichten die riesige GitLab-Community und unsere Teammitglieder durchschnittlich 55 Commits pro Tag - dies sind kontinuierliche Iterationen unseres Produkts, um neue Funktionen zu erstellen. Bevor wir jedoch die kontinuierliche Bereitstellung beherrschten, haben wir ab dem 7. eines jeden Monats Zeiträume eingefroren, in denen neue Funktionen eingefroren wurden: Zu diesem Zeitpunkt haben unsere Ingenieure ihre Aufmerksamkeit von der Entwicklung neuer Funktionen auf das Debuggen auf die Vorbereitung kommender Releases verlagert, die am 22. eines jeden Monats stabil herauskommen.
Durch die Einführung einer strengen Frist haben wir den Entwicklern ein Verhalten vermittelt, das ihnen half, sich letztendlich auf ein bestimmtes Datum zu konzentrieren, anstatt sich auf die Bereitschaft zu konzentrieren.
"... die Entwickler begannen ab dem 7. Date zu tanzen, weil sie auf den Kalender schauten und dachten: Nun, es ist noch Zeit, der 7. Tag in einer Woche, und dann, am 6. um Mitternacht, verschmolzen sie hektisch", sagte Marine Jankowski , CTO des Lieferteams. "Sie wissen, dass sie, wenn sie die Fristen überschreiten, einen weiteren Monat warten müssen, und wenn sie es rechtzeitig schaffen, haben sie zwei weitere gute Wochen zum Debuggen."
Seit der Gründung von GitLab.com wurden Zeiträume zum Einfrieren neuer Funktionen als Zeit zur Stabilisierung genutzt “, erklärte Marine.
Die Anzahl der Benutzer stieg jedoch und der Bedarf an neuen Funktionen zwang uns, das Entwicklungstempo zu beschleunigen. Die Stabilisierungsphase verlangsamte den Zyklus und verzögerte den Übergang zu Debugging, Regression und Bereitstellung von Funktionen erheblich - sowohl für Benutzer auf Gitlab.com als auch für einzelne Kunden.
"In einigen Fällen führte das [Einfrieren neuer Funktionen] sogar zu einer Instabilität der Plattform - aufgrund der Tatsache, dass Korrekturen mit höchster Priorität den Client nicht rechtzeitig erreichten", sagte Marine. - "Durch den Wechsel zu CI / CD liefern wir neue Produkte und debuggen sie viel schneller."
Bevor wir das Delivery-Team bildeten, um GitLab.com auf Continuous Delivery - und letztendlich auf Kubernetes - umzustellen, waren wir auf den Release-Manager angewiesen. Dies war eine Übergangsposition unter den Entwicklern, die von demjenigen gehalten wurde, der die neue Version vorbereitete. Wir haben den Prozess seit mehr als 5 Jahren wiederholt , aber Release-Manager haben eine Wissensbasis erstellt und diese mehr oder weniger automatisiert.
Die Methode erwies sich jedoch als ineffektiv, da der Bereitstellungsplan und die Vorbereitung für die Freigabe verschoben waren: von einem halben Tag auf mehrere Tage, da sich dabei Aufgaben für die manuelle Ausführung ansammelten .
"Der Release-Manager erhielt eine feste Liste von Aufgaben, eine Frist und wiederholte die obigen Schritte immer wieder, bis eine vollständig fertige und stabile Version auf GitLab.com erhalten wurde", sagte Marine. Im allgemeinsten Sinne wurde vom Release Manager Folgendes verlangt:
- Manuelles Synchronisieren der vielen Repositorys, aus denen GitLab besteht.
- Stellen Sie sicher, dass die richtigen Versionen in manuell erstellten Git-Zweigen enthalten sind.
- Wenn die Version die Tags empfängt, stellen Sie die Test- und Produktionsumgebung manuell auf GitLab.com bereit.
- Stellen Sie sicher, dass alles funktioniert, und veröffentlichen Sie Pakete für einzelne Benutzer manuell.
Bei einer Präsentation in Brooklyn während des GitLab-Commits zu diesem Thema teilte Marine die Ergebnisse der Beobachtungen für 2018 mit: In den zwei Wochen vor der Veröffentlichung verbrachte das Delivery-Team 60% der Zeit mit der Bereitstellung von Bereitstellungen, weitere 26% mit manuellen und halbmanuellen Aufgaben wie dem Schreiben einer Überprüfung monatliche Veröffentlichung.
Beobachtungsergebnisse für 2018 vor dem Übergang zur kontinuierlichen Lieferung: So verbrachte das Lieferteam zwei Wochen vor der Veröffentlichung Zeit.
"Allgemein gesprochen, dann 14 Tage, zwei Wochen vor der Veröffentlichung, tat das Team nur das, was es auf die Monitore starrte, und beobachtete, wie die Farbe trocknete oder so", sagte Marine.
Wenn das Lieferteam 86% dieses Kreises übernimmt (60% für Bereitstellungen + 26% für manuelle Aufgaben), würde es eine Reihe von Problemen lösen:
- Neuerscheinungen ohne Verzögerung.
- Wiederholbare und schnellere Bereitstellungen ohne Ausfallzeiten.
- Mehr Zeit für die Migration von GitLab.com zu Kubernetes.
- Mehr Freiheit bei der Vorbereitung Ihres Unternehmens auf die kontinuierliche Bereitstellung.
Obwohl die CD nur auf GitLab.com erhältlich ist, profitieren auch unsere einzelnen Kunden von unserer Umstellung darauf. Jetzt wird alles, was nicht von CI-Tests betroffen ist, automatisch und manuell in den Umgebungen getestet - bevor Sie zu GitLab.com gelangen. Alles, was auf GitLab.com gelangt und debuggt werden muss, wird innerhalb weniger Stunden debuggt. So wird die endgültige Version für einzelne Kunden sauber sein.
Der Übergang vom Einfrieren zur CD war eine Frage der Zeit, da unser Funktionsstapel wuchs und ein Team von Ingenieuren unter der Leitung von Marina den Übergang zu beobachten schien: „Das Lieferteam wurde mit dem alleinigen Zweck gebildet, das Unternehmen auf das CD-Modell zu übertragen und gleichzeitig das Unternehmen zu übertragen auf die Kubernetes-Plattform, um die Skalierung zu erleichtern und den Zyklus zu beschleunigen. "
Die meisten Unternehmen anstelle von GitLab würden den Übergang zu CI / CD und Kubernetes beginnen, indem sie zuerst neue Technologien in ihren Workflow integrieren und dabei den Entwicklungsprozess korrigieren. Wir haben einen anderen Ansatz gewählt.
Die Migration zu Kubernetes erfordert eine Änderung nicht nur des Produktionssystems, sondern auch des Entwicklungsansatzes “, sagte Marine. Kubernetes bietet bestimmte Funktionen, die einfach und ohne zusätzliche Investition verfügbar sind. Um jedoch wirklich von den kostenlosen Funktionen von Kubernetes profitieren zu können, benötigen Sie eine Art CI / CD.
Das Lieferteam akzeptierte dies: Um den Übergang zu Kubernetes für die kontinuierliche Lieferung zu erleichtern, sollten unsere Ingenieure bereits mit einem Fokus auf CI / CD arbeiten, was eine verbesserte Qualitätskontrolle (QS) und eine strengere Funktionsplanung impliziert. Und dann traf unser Delivery-Team eine düstere Entscheidung : Es baute ein CD-System mit vorhandenen Tools auf und organisierte die Infrastruktur der GitLab.com-Anwendung neu - anstatt sofort neue CD-Tools und -Technologien zu beherrschen.
"Die Idee war einfach", sagte Marine, "wir verwenden die uns zur Verfügung stehenden Werkzeuge , automatisieren die meisten manuellen Aufgaben und testen das gesamte statische System unter Last. Wenn das statische System standhält, fahren wir mit dem dynamischen Test fort."
Dieser Ansatz bot zwei Hauptvorteile:
Erstens haben wir alle Schwachstellen in unserem Ansatz identifiziert und durch Automatisierung mit CI stabilisiert, sodass unsere Anwendung stärker geworden ist und der Erfolg des Übergangs zu Kubernetes realer geworden ist.
Zweitens haben wir durch die Einrichtung eines Teams von Ingenieuren auf CD GitLab-Ingenieure implementiert, die es gewohnt sind, jede Woche Bereitstellungen durchzuführen und zu warten. Manchmal ist der ganze Tag, da sie sich auf die Zusammenführung auswirken, eine echte kulturelle Veränderung.
"Seit wir CI / CD beherrschen, haben unsere Entwickler auf neue Weise verstanden, was es bedeutet, getan zu werden", sagte Marine.
Vor der Einführung von CI / CD wurde die Änderung als abgeschlossen angesehen, sobald die Überprüfung abgeschlossen war. Dadurch wurde die Bereitstellung in verschiedenen Umgebungen vermieden, was zeitaufwändig war. Heutzutage werden Bereitstellungen innerhalb weniger Stunden geliefert, sodass es keinen Grund gibt, nicht zu bestätigen, dass die Änderungen in Test- und Produktionsumgebungen wirksam sind.
Durch die Bereitstellung von Kubernetes-Überprüfungsanwendungen können Entwickler Qualitätsprüfungen buchstäblich in Echtzeit durchführen, und die Verwendung von Funktionsflags für die progressive Bereitstellung beschleunigt auch die Entwicklung.
„Vom ersten Schritt der CD an müssen Entwickler auf jede automatisierte Qualitätskontrolle reagieren und manuelle Bestätigungen auf einer neuen Ebene sowohl in Produktions- als auch in Testumgebungen durchführen. Außerdem können Entwickler innerhalb eines Tages Änderungen an der Produktionsumgebung vornehmen Früher dauerte es mehrere Tage (oder sogar Wochen). "
Mit CD können Sie Codequalitätsprüfungen viel häufiger durchführen. Und da mit unserem CI / CD-System Änderungen im Code rund um die Uhr geliefert werden, wechseln die Entwickler bei Bedarf zu nicht standardmäßigen Problemen, die in Echtzeit auftreten, da die "Inkubationszeit" stark verkürzt wird.
Unsere neue Methode
Nach der Implementierung des CI / CD-Systems haben wir 90% des Prozesses automatisiert . Die restlichen 10% erfordern menschliches Eingreifen - eine Koordinierung zwischen vielen Personen mit Zugangsrecht ist erforderlich.
"Wir reduzieren diese 10% schrittweise - so dass wir nur die Genehmigung für die Veröffentlichung der Veröffentlichung benötigen", sagte Marine. In der aktuellen Iteration funktioniert der CI / CD-Prozess wie folgt :
- CI sucht automatisch nach bestimmten Tags in Zusammenführungsanforderungen, die von Prüfern und Entwicklern genehmigt wurden.
- CI synchronisiert automatisch die erforderlichen Repositorys und erstellt gleichzeitig die erforderlichen Git-Zweige und -Tags sowie die richtigen Release-Versionen, die wir bereitstellen möchten.
- Nach Abschluss der Builds werden Pakete automatisch in Testumgebungen bereitgestellt.
- Es werden automatische Qualitätsprüfungen durchgeführt, und wenn alles gut geht, wird die Bereitstellung an einen kleinen Teil der Benutzer in einer Produktionsumgebung geliefert.
- Parallel dazu führen Entwickler manuell eine Qualitätskontrolle auf einer anderen Ebene durch - um sicherzustellen, dass neue Funktionen ordnungsgemäß funktionieren.
- Wenn bei der manuellen Bestätigung ein Problem mit hoher Priorität festgestellt wird, werden die Bereitstellungen gestoppt.
- Wenn der vorherige Schritt abgeschlossen ist, startet das Mitglied des Bereitstellungsteams die Bereitstellungsbereitstellung für alle GitLab.com-Benutzer.
- Basierend auf der neuesten Produktionsbereitstellung, die auf GitLab.com gestartet wurde, wird dann eine individuelle Kundenversion erstellt.
Wie bei jedem anderen Engineering-Team ist die Skalierung für uns eine echte Herausforderung. Eine der größten Herausforderungen für Technikfreaks besteht jedoch darin, sicherzustellen, dass die Qualitätskontrolle alles abdeckt. Für ein großes Projekt wie GitLab.com ist dies jedoch eine intensive Arbeit. Außerdem müssen Sie sicherstellen, dass genügend Überwachung und Benachrichtigung vorhanden sind, damit das Projekt nicht nur mit vordefinierten Regeln funktioniert.
Die zweite große Herausforderung für uns ist die Komplexität des GitLab.com-Systems und die Übertragung von Änderungen direkt an alle Entwicklungsteams. "Es ist alles andere als einfach, den im Laufe der Jahre etablierten Prozess und die Gewohnheiten zu brechen", sagte Marine.
Ergebnisse
GitLab profitiert bereits stark vom Wechsel zu CI / CD.
Beobachtungen und Bewertungen im Jahr 2019 zeigten, dass das Lieferteam in diesen 14 Tagen vor der Veröffentlichung 82% der Zeit produktiver verbringt: Es wurde für die Arbeit an anderen wichtigen Aufgaben freigegeben.
Die Beobachtung für 2019 ergab, dass in den gleichen zwei Wochen dank des Übergangs zu c CD viel kostbare Zeit von den Entwicklern frei wurde.
Durch die Automatisierung der manuellen Arbeit wechselte das Delivery-Team schließlich zur Änderung der Infrastruktur von GitLab.com, um die Unterstützung für die Entwicklungsgeschwindigkeit und den Benutzerverkehr sowie die Migration zu Kubernetes zu verbessern.
"Und wie ich bereits sagte, ist dies alles ohne Kubernetes. Alles wurde auf dem alten Vorgängersystem gemacht", sagte Marine den Gästen des Brooklyn GitLab Commit. "Aber wir haben die Zeit gewonnen, und jetzt ist mein Team eng in die Migration involviert. Eine der größten Veränderungen hat sich jedoch gerade in der Gewohnheit ergeben, die Entwicklung zu organisieren."
Die Ergebnisse nach dem Übergang sind signifikant. Wenn das Team auf dem alten System im Mai 2019 irgendwo 7 Bereitstellungen geliefert hat, dann stieg diese Zahl im August 2019 auf 35. Und dies ist nicht die Grenze: Die Anzahl wird erheblich steigen - jetzt, da das Team täglich viele Bereitstellungen liefert.
"Wir haben gerade unseren Registrierungsdienst auf Kubernetes migriert. Wenn Sie die Containerregistrierung auf GitLab.com verwenden , werden alle Ihre Anforderungen auf der Kubernetes-Plattform ausgeführt", sagte Marine. - "GitLab ist ein Mehrkomponentensystem, und wir isolieren und übertragen weiterhin andere Dienste."
Jede neue Version enthält neue CI / CD-Funktionen. In Version 12.3 haben wir beispielsweise die GitLab-Container-Registrierung erweitert, sodass Benutzer CI / CD verwenden und Bilder / Tags sammeln und in ihre eigenen Projekte einbetten können . Es gab andere aufregende neue Innovationen.
Auch das System auf kontinuierliche Lieferung übertragen?
Marin hat Unternehmen beraten, die gerade dabei sind, auf CD umzusteigen, um mit dem zu beginnen, was sie haben.
"Was mich betrifft, bedeutet das Sitzen und Warten auf die Migration auf eine neue Plattform, sich selbst zu schaden", sagte Marine. „Die meisten Systeme können auf irgendeine Weise geändert werden und beschleunigen den Verarbeitungszyklus, ohne auf ein völlig neues System zu migrieren. Die Beschleunigung des Entwicklungs- / Freigabezyklus erhöht die Effizienz jedes Ingenieurs im System erheblich und spart mehr Zeit für die Migration auf eine neue Plattform wie Kubernetes.“
Wenn Sie neugierig sind, was als nächstes kommt, werfen Sie einen Blick auf diese detaillierte Zusammenfassung der aufregenden neuen CI / CD-Funktionen , die in den Startlöchern warten - ab Release 12.4.
Haben Sie das Brooklyn GitLab Commit verpasst?
Wenn Sie nicht an der Marina-Präsentation mit dem Hintergrund unseres Übergangs zu Kubernetes teilnehmen konnten, sehen Sie sich das vollständige Video unten an und nehmen Sie am 9. Oktober am European GitLab Commit in London teil .