På GitLab bearbetar vi programfixar på två sätt: manuellt och automatiskt. Läs vidare för att lära dig mer om releasehanterarens jobb med att skapa och leverera viktiga uppdateringar via automatiserad distribution till gitlab.com, samt patchar för användare att arbeta med på sina egna installationer.
Jag rekommenderar att du ställer in en påminnelse på din smartwatch: varje månad den 22:a kan användare som arbetar med GitLab på sina anläggningar se uppdateringar av den aktuella versionen av vår produkt. Den månatliga utgåvan innehåller nya funktioner, utvecklingar av befintliga och visar ofta slutresultatet av community-förfrågningar om verktyg eller sammanslagningar.
Men som praxis visar är mjukvaruutveckling sällan utan brister. När en bugg eller säkerhetssårbarhet upptäcks skapar releasehanteraren i leveransteamet en patch för våra användare med deras installationer. Gitlab.com uppdateras under CD-processen. Vi kallar denna CD-process för automatisk distribution för att undvika förvirring med CD-funktionen i GitLab. Denna process kan innehålla förslag från pull-förfrågningar som skickats av användare, kunder och vårt interna utvecklingsteam, så att lösa det tråkiga problemet med att släppa patchar löses på två mycket olika sätt.
«Vi ser till att allt utvecklare gör distribueras till alla miljöer varje dag innan det rullas ut till GitLab.com", förklarar , Senior teknisk chef, Infrastrukturavdelningen. "Tänk på utgåvor för dina installationer som ögonblicksbilder för gitlab.com-distributioner, för vilka vi har lagt till separata steg för att skapa ett paket så att våra användare kan använda det för att installera på sina installationer".
Oavsett bugg eller sårbarhet kommer gitlab.com-kunder att få korrigeringar kort efter att de har publicerats, vilket är en fördel med den automatiserade CD-processen. Patchar för användare med egna installationer kräver separat förberedelse av releasehanteraren.
Leveransteamet arbetar hårt för att automatisera de flesta processer som är involverade i att skapa releaser för att minska (medeltid till produktion, d.v.s. tid som spenderas på produktion), tidsperioden från bearbetning av en sammanslagningsförfrågan av en utvecklare till implementering på gitlab.com.
«Målet med leveransteamet är att se till att vi kan röra oss snabbare som företag, eller åtminstone få leveransfolket att arbeta snabbare, eller hur?, säger Marin.
Både gitlab.com-kunder och användare av deras installationer drar nytta av leveransteamets ansträngningar att minska cykeltiderna och påskynda driftsättningen. I den här artikeln kommer vi att förklara likheterna och skillnaderna mellan dessa två metoder. , och vi kommer också att beskriva hur vårt leveransteam förbereder patchar för användare som arbetar på deras anläggningar, samt hur vi säkerställer att gitlab.com är uppdaterad med hjälp av automatiserad distribution.
Vad gör en release manager?
Teammedlemmar varje månad våra utgåvor till användare på deras anläggningar, inklusive patchar och säkerhetsutgåvor som kan inträffa mellan utgåvor. De är också ansvariga för att leda företagets övergång till automatiserad, kontinuerlig driftsättning.
Självinstallationsutgåvor och gitlab.com-utgåvor använder liknande arbetsflöden men körs vid olika tidpunkter, förklarar Marin.
Först och främst ser releasehanteraren, oavsett releasetyp, till att GitLab är tillgängligt och säkert från det ögonblick applikationen lanseras på gitlab.com, inklusive att se till att samma problem inte hamnar i kundernas infrastruktur med deras egen kapacitet.
När en bugg eller sårbarhet har markerats som fixad i GitLab, måste releasehanteraren utvärdera att den kommer att inkluderas i patchar eller säkerhetsuppdateringar för användare med deras installationer. Om han bestämmer sig för att en bugg eller sårbarhet förtjänar en uppdatering börjar det förberedande arbetet.
Utgivningshanteraren måste bestämma om en korrigering ska förberedas eller när den ska distribueras - och detta är mycket beroende av situationens sammanhang, "under tiden är maskiner inte lika bra på att hantera sammanhang som människorsäger Marin.
Allt handlar om korrigeringar
Vad är patchar och varför behöver vi dem?
Releasehanteraren bestämmer om en fix ska släppas baserat på hur allvarlig felet är.
Felen varierar beroende på hur allvarliga de är. Så S4- eller S3-fel kan vara stilistiska, som pixel- eller ikonförskjutning. Detta är inte mindre viktigt, men det finns ingen betydande inverkan på någons arbetsflöde, vilket gör att sannolikheten att en fix kommer att skapas för sådana S3- eller S4-fel är liten, förklarar Marin.
Men sårbarheter S1 eller S2 innebär att användaren inte ska uppdatera till den senaste versionen, eller så finns det en betydande bugg som påverkar användarens arbetsflöde. Om de ingår i spåraren har många användare stött på dem, så releasehanteraren börjar omedelbart förbereda en fix.
När en patch för sårbarheter S1 eller S2 är klar, börjar releasehanteraren släppa patchen.
Till exempel skapades GitLab 12.10.1-patchen efter att flera blockeringsproblem identifierats och utvecklarna fixade det underliggande problemet som orsakade dem. Releasehanteraren bedömde riktigheten av de tilldelade allvarlighetsnivåerna och efter bekräftelse startade processen att släppa en fix, som var klar inom XNUMX timmar efter att blockeringsproblemen upptäcktes.
När många S4, S3 och S2 ackumuleras tittar releasehanteraren på sammanhanget för att fastställa hur brådskande det är att släppa en fix, och när ett visst antal av dem har nåtts kombineras och släpps de alla. Fixar efter release eller säkerhetsuppdateringar sammanfattas i blogginlägg.
Hur en releasehanterare skapar patchar
Vi använder GitLab CI och andra funktioner som våra ChatOps för att skapa patchar. Release manager startar releasen av fixen genom att aktivera ChatOps-teamet på vår interna kanal #releases i Slack.
/chatops run release prepare 12.10.1ChatOps arbetar inom Slack för att trigga olika händelser, som sedan bearbetas och exekveras av GitLab. Till exempel satte leveransteamet upp ChatOps för att automatisera olika saker för att släppa patchar.
När releasehanteraren väl startar ChatOps-teamet i Slack, sker resten av arbetet automatiskt i GitLab med CICD. Det finns tvåvägskommunikation mellan ChatOps i Slack och GitLab under releaseprocessen eftersom releasehanteraren aktiverar några av de stora stegen i processen.
Videon nedan visar den tekniska processen för att förbereda en patch för GitLab.
Hur automatisk distribution fungerar på gitlab.com
Processen och verktygen som används för att uppdatera gitlab.com liknar de som används för att skapa patchar. Att uppdatera gitlab.com kräver mindre manuellt arbete ur releasehanterarens synvinkel.
Istället för att köra distributioner med ChatOps använder vi CI-funktioner t.ex. , med vilken releasehanteraren kan schemalägga vissa åtgärder som ska utföras vid önskad tidpunkt. Istället för en manuell process finns det en pipeline som körs med jämna mellanrum en gång i timmen som laddar ner de nya ändringarna som gjorts i GitLab-projekt, paketerar dem och schemalägger distributionen och kör automatiskt testning, QA och andra nödvändiga steg.
"Så vi har många distributioner som körs i olika miljöer före gitlab.com, och efter att dessa miljöer är i bra form och testning visar bra resultat, startar releasehanteraren gitlab.com-distributionsåtgärderna", säger Marin.
CICD-teknik för att stödja gitlab.com-uppdateringar automatiserar hela processen till den punkt där releasehanteraren manuellt måste starta distributionen av produktionsmiljön till gitlab.com.
Marin går in i detalj om gitlab.com uppdateringsprocessen i videon nedan.
Vad gör leveransteamet mer?
Den största skillnaden mellan gitlab.com uppdateringsprocesser och släppande av patchar till kunder internt är att den senare processen kräver mer tid och mer manuellt arbete från releasehanteraren.
"Vi försenar ibland att släppa patchar till kunder med deras installationer på grund av rapporterade problem, verktygsproblem och för att det finns många nyanser som måste beaktas när man släpper en enda patch", säger Marin.
Ett av leveransteamets kortsiktiga mål är att minska mängden manuellt arbete från releasechefens sida för att påskynda releasen. Teamet arbetar med att förenkla, effektivisera och automatisera releaseprocessen, vilket kommer att hjälpa till att fixa problem med låg allvarlighetsgrad (S3 och S4, cirka. översättare). Att fokusera på hastighet är en nyckelprestandaindikator: det är nödvändigt att minska MTTP - tiden från att man tar emot en sammanslagningsförfrågan tills resultatet distribueras till gitlab.com - från nuvarande 50 timmar till 8 timmar.
Leveransteamet arbetar också med att migrera gitlab.com till en Kubernetes-baserad infrastruktur.
Redaktörens n.b.: Om du redan har hört talas om Kubernetes-teknik (och jag tvivlar inte på att du har), men ännu inte har rört den med dina händer, rekommenderar jag att du deltar i intensivkurser online , som kommer att hållas 28-30 september, och , som äger rum 14–16 oktober. Detta gör att du säkert kan navigera och arbeta med tekniken.
Det här är två tillvägagångssätt som strävar efter samma mål: snabb leverans av uppdateringar, både för gitlab.com och för kunder på deras anläggningar.
Några idéer eller rekommendationer till oss?
Alla är välkomna att bidra till GitLab, och vi välkomnar feedback från våra läsare. Om du har några idéer till vårt leveransteam, tveka inte markant team: Delivery.
Källa: will.com