Hos GitLab behandler vi programvarefikser på to måter: manuelt og automatisk. Les videre for å lære om release managers jobb med å lage og levere viktige oppdateringer via automatisert distribusjon til gitlab.com, samt patcher som brukere kan jobbe med på sine egne installasjoner.
Jeg anbefaler å sette inn en påminnelse på smartklokken din: hver måned den 22. kan brukere som jobber med GitLab på deres anlegg se oppdateringer til den gjeldende versjonen av produktet vårt. Den månedlige utgivelsen inneholder nye funksjoner, utviklinger av eksisterende, og viser ofte sluttresultatet av fellesskapsforespørsler om verktøy eller sammenslåinger.
Men som praksis viser, er programvareutvikling sjelden uten feil. Når en feil eller sikkerhetssårbarhet oppdages, oppretter release manager i leveringsteamet en oppdatering for brukerne våre med installasjonene deres. Gitlab.com oppdateres under CD-prosessen. Vi kaller denne CD-prosessen automatisk distribusjon for å unngå forvirring med CD-funksjonen i GitLab. Denne prosessen kan inkludere forslag fra pull-forespørsler sendt inn av brukere, kunder og vårt interne utviklingsteam, slik at løsning av det kjedelige problemet med å frigi patcher løses på to vidt forskjellige måter.
«Vi sikrer at alt utviklere lager blir distribuert til alle miljøer hver dag før vi ruller det ut til GitLab.com", forklarer , Senior teknisk sjef, Infrastrukturavdelingen. "Tenk på utgivelser for installasjonene dine som øyeblikksbilder for gitlab.com-implementeringer, som vi har lagt til separate trinn for å lage en pakke slik at brukerne våre kan bruke den til å installere på installasjonene deres'.
Uavhengig av feil eller sårbarhet, vil gitlab.com-kunder motta rettelser kort tid etter at de er publisert, noe som er en fordel med den automatiserte CD-prosessen. Patcher for brukere med egne installasjoner krever separat forberedelse av release manager.
Leveringsteamet jobber hardt for å automatisere de fleste prosessene som er involvert i å lage utgivelser for å redusere (gjennomsnittlig tid til produksjon, dvs. tid brukt på produksjon), tidsperioden fra behandling av en sammenslåingsforespørsel fra en utvikler til distribusjon på gitlab.com.
«Målet med leveringsteamet er å sørge for at vi kan bevege oss raskere som selskap, eller i det minste få leveringsfolkene til å jobbe raskere, ikke sant?, sier Marin.
Både gitlab.com-kunder og brukere av deres installasjoner drar nytte av leveringsteamets innsats for å redusere syklustider og øke hastigheten på distribusjoner. I denne artikkelen vil vi forklare likhetene og forskjellene mellom disse to metodene. , og vi vil også beskrive hvordan leveringsteamet vårt forbereder oppdateringer for brukere som jobber på deres fasiliteter, samt hvordan vi sikrer at gitlab.com er oppdatert ved hjelp av automatisert distribusjon.
Hva gjør en release manager?
Teammedlemmer månedlig våre utgivelser til brukere ved deres anlegg, inkludert patcher og sikkerhetsutgivelser som kan oppstå mellom utgivelser. De er også ansvarlige for å lede selskapets overgang til automatisert, kontinuerlig distribusjon.
Selvinstallasjonsutgivelser og gitlab.com-utgivelser bruker lignende arbeidsflyter, men kjører til forskjellige tider, forklarer Marin.
Først og fremst sikrer release manager, uavhengig av utgivelsestype, at GitLab er tilgjengelig og sikker fra det øyeblikket applikasjonen lanseres på gitlab.com, inkludert å sikre at de samme problemene ikke havner i infrastrukturen til kundene med deres egne kapasiteter.
Når en feil eller sårbarhet er merket som fikset i GitLab, må utgivelsesbehandleren evaluere at den vil bli inkludert i oppdateringene eller sikkerhetsoppdateringene for brukere med deres installasjoner. Hvis han bestemmer seg for at en feil eller sårbarhet fortjener en oppdatering, starter det forberedende arbeidet.
Utgivelseslederen må bestemme om den skal forberede en rettelse, eller når den skal distribueres - og dette er svært avhengig av konteksten til situasjonen, "i mellomtiden er ikke maskiner like flinke til å håndtere kontekst som menneskersier Marin.
Alt handler om reparasjoner
Hva er patcher og hvorfor trenger vi dem?
Utgivelsessjefen bestemmer om en rettelse skal utgis basert på alvorlighetsgraden av feilen.
Feil varierer avhengig av alvorlighetsgraden. Så S4- eller S3-feil kan være stilistiske, for eksempel piksel- eller ikonforskyvning. Dette er ikke mindre viktig, men det er ingen nevneverdig innvirkning på noens arbeidsflyt, noe som betyr at sannsynligheten for at det opprettes en rettelse for slike S3- eller S4-feil er liten, forklarer Marin.
Men sårbarheter S1 eller S2 betyr at brukeren ikke skal oppdatere til siste versjon, eller det er en betydelig feil som påvirker brukerens arbeidsflyt. Hvis de er inkludert i sporingen, har mange brukere støtt på dem, så utgivelsesadministratoren begynner umiddelbart å forberede en løsning.
Når en oppdatering for sårbarheter S1 eller S2 er klar, begynner utgivelsesbehandlingen å gi ut oppdateringen.
For eksempel ble GitLab 12.10.1-oppdateringen opprettet etter at flere blokkeringsproblemer ble identifisert og utviklerne fikset det underliggende problemet som forårsaket dem. Utgivelseslederen vurderte riktigheten av de tildelte alvorlighetsnivåene, og etter bekreftelse ble prosessen med å frigi en rettelse startet, som var klar innen XNUMX timer etter at blokkeringsproblemene ble oppdaget.
Når mye S4, S3 og S2 akkumuleres, ser utgivelsesbehandleren på konteksten for å finne ut hvor haster det er å frigi en rettelse, og når et visst antall av dem er nådd, blir de alle kombinert og frigitt. Rettelser eller sikkerhetsoppdateringer etter utgivelse er oppsummert i blogginnlegg.
Hvordan en utgivelsesadministrator lager patcher
Vi bruker GitLab CI og andre funksjoner som ChatOps for å generere patcher. Release manager starter utgivelsen av rettelsen ved å aktivere ChatOps-teamet på vår interne kanal #releases i Slack.
/chatops run release prepare 12.10.1ChatOps jobber i Slack for å utløse forskjellige hendelser, som deretter behandles og utføres av GitLab. For eksempel satte leveringsteamet opp ChatOps for å automatisere forskjellige ting for å gi ut patcher.
Når utgivelsesadministratoren starter ChatOps-teamet i Slack, skjer resten av arbeidet automatisk i GitLab ved hjelp av CICD. Det er toveiskommunikasjon mellom ChatOps i Slack og GitLab under utgivelsesprosessen ettersom utgivelsessjefen aktiverer noen av de viktigste trinnene i prosessen.
Videoen nedenfor viser den tekniske prosessen med å forberede en oppdatering for GitLab.
Hvordan automatisk distribusjon fungerer på gitlab.com
Prosessen og verktøyene som brukes til å oppdatere gitlab.com ligner på de som brukes til å lage patcher. Å oppdatere gitlab.com krever mindre manuelt arbeid fra utgivelsessjefens synspunkt.
I stedet for å kjøre distribusjoner ved hjelp av ChatOps, bruker vi CI-funksjoner, f.eks. , som utgivelsesansvarlig kan planlegge bestemte handlinger som skal utføres på det nødvendige tidspunktet. I stedet for en manuell prosess, er det en pipeline som kjører med jevne mellomrom en gang i timen som laster ned de nye endringene som er gjort i GitLab-prosjekter, pakker dem og planlegger distribusjon, og kjører automatisk testing, QA og andre nødvendige trinn.
"Så vi har mange distribusjoner som kjører i forskjellige miljøer før gitlab.com, og etter at disse miljøene er i god form og testing viser gode resultater, starter utgivelsessjefen gitlab.com-distribusjonshandlingene," sier Marin.
CICD-teknologi for å støtte gitlab.com-oppdateringer automatiserer hele prosessen til det punktet hvor release manager manuelt må starte distribusjonen av produksjonsmiljøet til gitlab.com.
Marin går i detalj om gitlab.com-oppdateringsprosessen i videoen nedenfor.
Hva annet gjør leveringsteamet?
Hovedforskjellen mellom gitlab.com-oppdateringsprosessene og frigjøring av patcher til kunder internt er at sistnevnte prosess krever mer tid og mer manuelt arbeid fra utgivelsessjefen.
"Vi utsetter noen ganger utgivelsen av patcher til kundene med deres installasjoner på grunn av rapporterte problemer, verktøyproblemer, og fordi det er mange nyanser som må tas i betraktning når du utgir en enkelt patch," sier Marin.
Et av de kortsiktige målene til leveringsteamet er å redusere mengden manuelt arbeid fra utgivelsesansvarlig for å få fart på utgivelsen. Teamet jobber med å forenkle, strømlinjeforme og automatisere utgivelsesprosessen, noe som vil bidra til å fikse problemer med lav alvorlighetsgrad (S3 og S4, ca. oversetter). Fokus på hastighet er en nøkkelindikator for ytelse: det er nødvendig å redusere MTTP - tiden fra du mottar en sammenslåingsforespørsel til å distribuere resultatet til gitlab.com - fra gjeldende 50 timer til 8 timer.
Leveringsteamet jobber også med å migrere gitlab.com til en Kubernetes-basert infrastruktur.
Redaktørens NB: Hvis du allerede har hørt om Kubernetes-teknologi (og jeg er ikke i tvil om at du har det), men ennå ikke har rørt den med hendene, anbefaler jeg å delta på intensive nettkurser , som finner sted 28.-30. september, og , som finner sted 14.–16. oktober. Dette vil tillate deg å trygt navigere og jobbe med teknologien.
Dette er to tilnærminger som forfølger samme mål: rask levering av oppdateringer, både for gitlab.com og for kunder ved deres anlegg.
Noen ideer eller anbefalinger til oss?
Alle er velkomne til å bidra til GitLab, og vi tar gjerne imot tilbakemeldinger fra våre lesere. Hvis du har noen ideer til vårt leveringsteam, ikke nøl med varsel team: Delivery.
Kilde: www.habr.com