Bij GitLab verwerken we softwarefixes op twee manieren: handmatig en automatisch. Lees verder om meer te weten te komen over de taak van de releasemanager: het creëren en leveren van belangrijke updates via geautomatiseerde implementatie op gitlab.com, evenals patches waarmee gebruikers op hun eigen installaties kunnen werken.
Ik raad aan een herinnering in te stellen op uw smartwatch: elke maand op de 22e kunnen gebruikers die op hun locatie met GitLab werken updates zien van de huidige versie van ons product. De maandelijkse release bevat nieuwe functies, ontwikkelingen van bestaande, en toont vaak het eindresultaat van communityverzoeken om tooling of samenvoegingen.
Maar zoals de praktijk laat zien, is softwareontwikkeling zelden zonder gebreken. Wanneer er een bug of beveiligingsprobleem wordt ontdekt, maakt de releasemanager van het leveringsteam een patch voor onze gebruikers bij hun installaties. Gitlab.com wordt bijgewerkt tijdens het cd-proces. We noemen dit CD-proces automatische implementatie om verwarring met de CD-functie in GitLab te voorkomen. Dit proces kan suggesties bevatten van pull-aanvragen die zijn ingediend door gebruikers, klanten en ons interne ontwikkelingsteam, zodat het oplossen van het saaie probleem van het uitbrengen van patches op twee heel verschillende manieren wordt opgelost.
«We zorgen ervoor dat alles wat ontwikkelaars maken elke dag in alle omgevingen wordt geïmplementeerd voordat het op GitLab.com wordt uitgerold", legt uit , Senior technisch manager, afdeling Infrastructuur. "Beschouw releases voor je installaties als snapshots voor gitlab.com-implementaties, waarvoor we afzonderlijke stappen hebben toegevoegd om een pakket te maken, zodat onze gebruikers het kunnen gebruiken om op hun installaties te installeren.
Ongeacht de bug of kwetsbaarheid, klanten van gitlab.com ontvangen oplossingen kort nadat ze zijn gepubliceerd, wat een voordeel is van het geautomatiseerde cd-proces. Patches voor gebruikers met eigen installaties vereisen een aparte voorbereiding door de releasemanager.
Het leveringsteam werkt er hard aan om de meeste processen die betrokken zijn bij het maken van releases te automatiseren (gemiddelde tijd tot productie, d.w.z. tijd besteed aan productie), de tijdsperiode vanaf het verwerken van een samenvoegverzoek door een ontwikkelaar tot aan de implementatie op gitlab.com.
«Het doel van het bezorgteam is om ervoor te zorgen dat we als bedrijf sneller kunnen bewegen, of in ieder geval de bezorgers sneller kunnen laten werken, toch??, zegt Marin.
Zowel klanten van gitlab.com als gebruikers van hun installaties profiteren van de inspanningen van het leveringsteam om de cyclustijden te verkorten en de implementatie te versnellen. In dit artikel leggen we de overeenkomsten en verschillen tussen deze twee methoden uit. , en we zullen ook beschrijven hoe ons leveringsteam patches voorbereidt voor gebruikers die op locatie draaien, en hoe we gitlab.com up-to-date houden met behulp van geautomatiseerde implementatie.
Wat doet een releasemanager?
Teamleden maandelijks onze releases aan gebruikers in hun faciliteiten, inclusief patches en beveiligingsreleases die tussen releases kunnen voorkomen. Zij zijn ook verantwoordelijk voor het leiden van de transitie van het bedrijf naar geautomatiseerde, continue implementatie.
Zelfinstallatie-releases en gitlab.com-releases gebruiken vergelijkbare workflows, maar draaien op verschillende tijdstippen, legt Marin uit.
Eerst en vooral zorgt de releasemanager, ongeacht het releasetype, ervoor dat GitLab beschikbaar en veilig is vanaf het moment dat de applicatie op gitlab.com wordt gelanceerd, en zorgt er ook voor dat dezelfde problemen niet in de infrastructuur van klanten terechtkomen met hun eigen capaciteiten.
Zodra een bug of kwetsbaarheid in GitLab als opgelost is gemarkeerd, moet de releasemanager evalueren of deze zal worden opgenomen in de patches of beveiligingsupdates voor gebruikers met hun installaties. Als hij besluit dat een bug of kwetsbaarheid een update verdient, begint het voorbereidende werk.
De releasemanager moet beslissen of hij een fix voorbereidt, of wanneer hij deze implementeert - en dit is sterk afhankelijk van de context van de situatie, "Ondertussen zijn machines niet zo goed in het beheren van context als mensen" zegt Marijn.
Het draait allemaal om de oplossingen
Wat zijn patches en waarom hebben we ze nodig?
De releasemanager beslist of er een oplossing wordt uitgebracht op basis van de ernst van de bug.
Fouten variëren afhankelijk van hun ernst. S4- of S3-fouten kunnen dus stilistisch zijn, zoals verplaatsing van pixels of pictogrammen. Dit is niet minder belangrijk, maar heeft geen significante impact op iemands workflow, wat betekent dat de kans dat er een oplossing voor dergelijke S3- of S4-fouten wordt gemaakt klein is, legt Marin uit.
Kwetsbaarheden S1 of S2 zorgen er echter voor dat de gebruiker niet naar de nieuwste versie moet updaten, of dat er een aanzienlijke bug is die de workflow van de gebruiker beïnvloedt. Als ze in de tracker zijn opgenomen, zijn veel gebruikers ze tegengekomen, dus de releasemanager begint onmiddellijk met het voorbereiden van een oplossing.
Zodra een patch voor kwetsbaarheden S1 of S2 gereed is, begint de releasemanager met het uitbrengen van de patch.
De GitLab 12.10.1-patch is bijvoorbeeld gemaakt nadat verschillende blokkeringsproblemen waren geïdentificeerd en de ontwikkelaars het onderliggende probleem hadden opgelost dat deze veroorzaakte. De Releasemanager beoordeelde de juistheid van de toegekende ernstniveaus en na bevestiging werd het proces voor het vrijgeven van een oplossing gestart, dat binnen XNUMX uur nadat de blokkeringsproblemen waren ontdekt, gereed was.
Wanneer veel S4, S3 en S2 zich ophopen, kijkt de releasemanager naar de context om de urgentie van het vrijgeven van een fix te bepalen, en wanneer een bepaald aantal van deze fixes is bereikt, worden ze allemaal gecombineerd en vrijgegeven. Reparaties of beveiligingsupdates na de release worden samengevat in blogposts.
Hoe een releasemanager patches maakt
We gebruiken GitLab CI en andere functies zoals onze ChatOps om patches te genereren. Release Manager activeert de release van de oplossing door het ChatOps-team op ons interne kanaal te activeren #releases in Slack.
/chatops run release prepare 12.10.1ChatOps werkt binnen Slack om verschillende gebeurtenissen te activeren, die vervolgens door GitLab worden verwerkt en uitgevoerd. Zo heeft het deliveryteam ChatOps opgezet om diverse zaken te automatiseren en patches uit te brengen.
Zodra de releasemanager het ChatOps-team in Slack start, gebeurt de rest van het werk automatisch in GitLab met behulp van CICD. Er is tweerichtingscommunicatie tussen ChatOps in Slack en GitLab tijdens het releaseproces, aangezien de releasemanager enkele van de belangrijkste stappen in het proces activeert.
De onderstaande video toont het technische proces van het voorbereiden van een patch voor GitLab.
Hoe automatische implementatie werkt op gitlab.com
Het proces en de tools die worden gebruikt om gitlab.com te updaten zijn vergelijkbaar met degene die worden gebruikt om patches te maken. Het updaten van gitlab.com vereist minder handmatig werk vanuit het oogpunt van de releasemanager.
In plaats van implementaties uit te voeren met ChatOps, gebruiken we CI-functies, b.v. , waarmee de releasemanager bepaalde acties op het gewenste tijdstip kan plannen. In plaats van een handmatig proces is er een pijplijn die periodiek één keer per uur wordt uitgevoerd en die de nieuwe wijzigingen in GitLab-projecten downloadt, verpakt en de implementatie plant, en automatisch tests, QA en andere noodzakelijke stappen uitvoert.
"We hebben dus veel implementaties in verschillende omgevingen vóór gitlab.com, en nadat die omgevingen in goede staat zijn en de tests goede resultaten opleveren, start de releasemanager de implementatieacties van gitlab.com", zegt Marin.
CICD-technologie voor het ondersteunen van gitlab.com-updates automatiseert het hele proces tot het punt waarop de releasemanager handmatig de implementatie van de productieomgeving op gitlab.com moet starten.
Marin gaat in de onderstaande video gedetailleerd in op het updateproces van gitlab.com.
Wat doet het bezorgteam nog meer?
Het belangrijkste verschil tussen de updateprocessen van gitlab.com en het intern uitbrengen van patches aan klanten is dat het laatste proces meer tijd en meer handmatig werk van de releasemanager vergt.
“Soms stellen we het uitbrengen van patches voor klanten bij hun installaties uit vanwege gerapporteerde problemen, toolingproblemen en omdat er veel nuances zijn waarmee rekening moet worden gehouden bij het uitbrengen van een enkele patch”, zegt Marin.
Eén van de kortetermijndoelstellingen van het opleveringsteam is het verminderen van de hoeveelheid handmatig werk van de releasemanager om de release te versnellen. Het team werkt aan het vereenvoudigen, stroomlijnen en automatiseren van het releaseproces, wat zal helpen bij het oplossen van problemen met een lage ernst (S3 en S4, ca. vertaler). Focussen op snelheid is een belangrijke prestatie-indicator: het is noodzakelijk om MTTP – de tijd tussen het ontvangen van een samenvoegverzoek en het implementeren van het resultaat op gitlab.com – terug te brengen van de huidige 50 uur naar 8 uur.
Het leveringsteam werkt ook aan de migratie van gitlab.com naar een op Kubernetes gebaseerde infrastructuur.
Redacteur n.b.: Als je al hebt gehoord over de Kubernetes-technologie (en ik twijfel er niet aan dat je dat hebt gedaan), maar het nog niet met je handen hebt aangeraakt, raad ik je aan deel te nemen aan online intensieve cursussen , die van 28-30 september wordt gehouden, en , dat plaatsvindt van 14 tot en met 16 oktober. Hierdoor kunt u vol vertrouwen navigeren en met de technologie werken.
Dit zijn twee benaderingen die hetzelfde doel nastreven: snelle levering van updates, zowel voor gitlab.com als voor klanten op hun locatie.
Heeft u ideeën of aanbevelingen voor ons?
Iedereen is welkom om bij te dragen aan GitLab, en we verwelkomen feedback van onze lezers. Heeft u ideeën voor ons bezorgteam? Aarzel dan niet met kennisgeving team: Delivery.
Bron: www.habr.com