Hos GitLab behandler vi softwarerettelser på to måder: manuelt og automatisk. Læs videre for at lære om releasemanagerens job med at skabe og levere vigtige opdateringer via automatiseret udrulning til gitlab.com, samt patches, som brugere kan arbejde med på deres egne installationer.
Jeg anbefaler at indstille en påmindelse på dit smartwatch: hver måned den 22. kan brugere, der arbejder med GitLab på deres faciliteter, se opdateringer til den aktuelle version af vores produkt. Den månedlige udgivelse indeholder nye funktioner, udviklinger af eksisterende og viser ofte slutresultatet af fællesskabsanmodninger om værktøj eller fusioner.
Men som praksis viser, er softwareudvikling sjældent uden fejl. Når en fejl eller sikkerhedssårbarhed opdages, opretter release manager i leveringsteamet en patch til vores brugere med deres installationer. Gitlab.com opdateres under cd-processen. Vi kalder denne cd-proces automatisk implementering for at undgå forvirring med cd-funktionen i GitLab. Denne proces kan inkorporere forslag fra pull-anmodninger indsendt af brugere, kunder og vores interne udviklingsteam, så løsningen af det kedelige problem med at frigive patches løses på to vidt forskellige måder.
«Vi sikrer, at alt, hvad udviklere laver, bliver implementeret til alle miljøer hver dag, før det rulles ud til GitLab.com", forklarer , Senior Technical Manager, Infrastrukturafdelingen. "Tænk på udgivelser til dine installationer som snapshots til gitlab.com-implementeringer, hvor vi har tilføjet separate trin til at oprette en pakke, så vores brugere kan bruge den til at installere på deres installationer'.
Uanset fejlen eller sårbarheden vil gitlab.com-kunder modtage rettelser kort efter, at de er publiceret, hvilket er en fordel ved den automatiserede cd-proces. Patches til brugere med deres egne installationer kræver separat forberedelse af release manager.
Leveringsteamet arbejder hårdt på at automatisere de fleste af de processer, der er involveret i at skabe udgivelser for at reducere (gennemsnitlig tid til produktion, dvs. tid brugt på produktion), tidsrummet fra behandling af en fletteanmodning fra en udvikler til implementering på gitlab.com.
«Målet med leveringsteamet er at sikre, at vi kan bevæge os hurtigere som virksomhed, eller i det mindste få leveringsfolkene til at arbejde hurtigere, ikke?, siger Marin.
Både gitlab.com-kunder og brugere af deres installationer nyder godt af leveringsteamets bestræbelser på at reducere cyklustider og fremskynde implementeringer. I denne artikel vil vi forklare lighederne og forskellene mellem disse to metoder. , og vi vil også beskrive, hvordan vores leveringsteam forbereder patches til brugere, der arbejder på deres faciliteter, samt hvordan vi sikrer, at gitlab.com er opdateret ved hjælp af automatiseret implementering.
Hvad laver en release manager?
Teammedlemmer hver måned vores udgivelser til brugere på deres faciliteter, herunder patches og sikkerhedsudgivelser, der kan forekomme mellem udgivelserne. De er også ansvarlige for at lede virksomhedens overgang til automatiseret, kontinuerlig implementering.
Selvinstallationsudgivelser og gitlab.com-udgivelser bruger lignende arbejdsgange, men kører på forskellige tidspunkter, forklarer Marin.
Først og fremmest sikrer releasemanageren, uanset udgivelsestype, at GitLab er tilgængeligt og sikkert fra det øjeblik, applikationen lanceres på gitlab.com, herunder at de samme problemer ikke ender i kundernes infrastruktur med deres egne kapaciteter.
Når en fejl eller sårbarhed er markeret som rettet i GitLab, skal releasemanageren evaluere, at den vil blive inkluderet i patches eller sikkerhedsopdateringer for brugere med deres installationer. Hvis han beslutter, at en fejl eller sårbarhed fortjener en opdatering, begynder det forberedende arbejde.
Udgivelsesadministratoren skal beslutte, om der skal forberedes en rettelse, eller hvornår den skal implementeres - og det afhænger meget af situationens kontekst, "i mellemtiden er maskiner ikke så gode til at styre kontekst som menneskersiger Marin.
Det handler om rettelserne
Hvad er patches, og hvorfor har vi brug for dem?
Udgivelsesmanageren beslutter, om der skal frigives en rettelse baseret på fejlens alvor.
Fejl varierer afhængigt af deres sværhedsgrad. Så S4- eller S3-fejl kan være stilistiske, såsom pixel- eller ikonforskydning. Dette er ikke mindre vigtigt, men der er ingen væsentlig indflydelse på nogens arbejdsgang, hvilket betyder, at sandsynligheden for, at der bliver lavet en rettelse til sådanne S3- eller S4-fejl, er lille, forklarer Marin.
Men sårbarheder S1 eller S2 betyder, at brugeren ikke skal opdatere til den nyeste version, eller der er en væsentlig fejl, der påvirker brugerens arbejdsgang. Hvis de er inkluderet i trackeren, er mange brugere stødt på dem, så releasemanageren begynder straks at forberede en rettelse.
Når en patch til sårbarheder S1 eller S2 er klar, begynder release manager at frigive patchen.
For eksempel blev GitLab 12.10.1-patchen oprettet, efter at adskillige blokeringsproblemer blev identificeret, og udviklerne løste det underliggende problem, der forårsagede dem. Release-manageren vurderede rigtigheden af de tildelte sværhedsgrader, og efter bekræftelse blev processen med at frigive en rettelse lanceret, som var klar inden for XNUMX timer efter, at blokeringsproblemerne blev opdaget.
Når en masse S4, S3 og S2 akkumulerer, ser release manager på konteksten for at bestemme, hvor meget det haster med at frigive en rettelse, og når et vist antal af dem er nået, kombineres de alle og frigives. Rettelser eller sikkerhedsopdateringer efter udgivelse er opsummeret i blogindlæg.
Hvordan en release manager opretter patches
Vi bruger GitLab CI og andre funktioner som vores ChatOps til at generere patches. Release manager starter frigivelsen af rettelsen ved at aktivere ChatOps-teamet på vores interne kanal #releases i Slack.
/chatops run release prepare 12.10.1ChatOps arbejder i Slack for at udløse forskellige hændelser, som derefter behandles og eksekveres af GitLab. For eksempel satte leveringsteamet ChatOps op til at automatisere forskellige ting for at frigive patches.
Når release manager starter ChatOps-teamet i Slack, sker resten af arbejdet automatisk i GitLab ved hjælp af CICD. Der er tovejskommunikation mellem ChatOps i Slack og GitLab under udgivelsesprocessen, da releasemanageren aktiverer nogle af de vigtigste trin i processen.
Videoen nedenfor viser den tekniske proces med at forberede en patch til GitLab.
Sådan fungerer automatisk implementering på gitlab.com
Processen og værktøjerne, der bruges til at opdatere gitlab.com, ligner dem, der bruges til at oprette patches. Opdatering af gitlab.com kræver mindre manuelt arbejde fra release managers synspunkt.
I stedet for at køre implementeringer ved hjælp af ChatOps, bruger vi CI-funktioner, f.eks. , hvormed udgivelsesadministratoren kan planlægge bestemte handlinger, der skal udføres på det krævede tidspunkt. I stedet for en manuel proces er der en pipeline, der kører med jævne mellemrum en gang i timen, som downloader de nye ændringer, der er lavet til GitLab-projekter, pakker dem og planlægger implementering og automatisk kører test, QA og andre nødvendige trin.
"Så vi har mange implementeringer, der kører i forskellige miljøer før gitlab.com, og efter at disse miljøer er i god form og test viser gode resultater, starter releasemanageren gitlab.com implementeringshandlingerne," siger Marin.
CICD-teknologi til understøttelse af gitlab.com-opdateringer automatiserer hele processen til det punkt, hvor releasemanageren manuelt skal starte udrulningen af produktionsmiljøet til gitlab.com.
Marin går i detaljer om gitlab.com-opdateringsprocessen i videoen nedenfor.
Hvad laver leveringsteamet ellers?
Den største forskel mellem gitlab.com-opdateringsprocesserne og frigivelse af patches til kunder internt er, at sidstnævnte proces kræver mere tid og mere manuelt arbejde fra releasemanageren.
"Vi forsinker nogle gange frigivelsen af patches til kunder med deres installationer på grund af rapporterede problemer, værktøjsproblemer, og fordi der er mange nuancer, der skal tages i betragtning, når man frigiver en enkelt patch," siger Marin.
Et af de kortsigtede mål for leveringsteamet er at reducere mængden af manuelt arbejde fra release managerens side for at fremskynde udgivelsen. Teamet arbejder på at forenkle, strømline og automatisere udgivelsesprocessen, hvilket vil hjælpe med at få rettelser til problemer med lav sværhedsgrad (S3 og S4, ca. oversætter). Fokus på hastighed er en vigtig præstationsindikator: det er nødvendigt at reducere MTTP - tiden fra modtagelse af en fletteanmodning til implementering af resultatet til gitlab.com - fra de nuværende 50 timer til 8 timer.
Leveringsteamet arbejder også på at migrere gitlab.com til en Kubernetes-baseret infrastruktur.
Redaktørens NB: Hvis du allerede har hørt om Kubernetes-teknologi (og det er jeg ikke i tvivl om, at du har), men endnu ikke har rørt det med dine hænder, anbefaler jeg at deltage i online intensive kurser , som finder sted 28.-30. september, og , som finder sted 14.-16. oktober. Dette giver dig mulighed for trygt at navigere og arbejde med teknologien.
Disse er to tilgange, der forfølger det samme mål: hurtig levering af opdateringer, både for gitlab.com og for kunder på deres faciliteter.
Nogle ideer eller anbefalinger til os?
Alle er velkomne til at bidrage til GitLab, og vi modtager gerne feedback fra vores læsere. Hvis du har nogle ideer til vores leveringsteam, så tøv ikke markeret team: Delivery.
Kilde: www.habr.com