V GitLabu zpracováváme opravy softwaru dvěma způsoby: ručně a automaticky. Čtěte dále a dozvíte se o práci správce verzí při vytváření a dodávání důležitých aktualizací prostřednictvím automatického nasazení na gitlab.com a také o záplatách, se kterými mohou uživatelé pracovat na svých vlastních instalacích.
Doporučuji nastavit si na chytrých hodinkách připomenutí: každý měsíc 22. dne mohou uživatelé pracující s GitLab ve svých zařízeních vidět aktualizace aktuální verze našeho produktu. Měsíční verze obsahuje nové funkce, vývoj těch stávajících a často ukazuje konečný výsledek komunitních požadavků na nástroje nebo sloučení.
Ale, jak ukazuje praxe, vývoj softwaru je zřídka bez chyb. Když je zjištěna chyba nebo zranitelnost zabezpečení, správce vydání v týmu pro doručování vytvoří opravu pro naše uživatele s jejich instalacemi. Gitlab.com se aktualizuje během procesu CD. Tento proces CD nazýváme automatické nasazení, abychom se vyhnuli záměně s funkcí CD v GitLabu. Tento proces může zahrnovat návrhy z požadavků na stažení odeslaných uživateli, zákazníky a naším interním vývojovým týmem, takže řešení nudného problému s vydáváním záplat je řešeno dvěma velmi odlišnými způsoby.
«Zajišťujeme, aby vše, co vývojáři vytvořili, bylo každý den nasazeno do všech prostředí, než to zavedeme na GitLab.com“, vysvětluje , hlavní technický manažer, oddělení infrastruktury. "Představte si vydání pro vaše instalace jako snímky pro nasazení gitlab.com, pro které jsme přidali samostatné kroky k vytvoření balíčku, aby jej naši uživatelé mohli použít k instalaci do svých instalací.".
Bez ohledu na chybu nebo zranitelnost obdrží zákazníci gitlab.com opravy krátce po jejich zveřejnění, což je výhoda automatizovaného procesu CD. Opravy pro uživatele s vlastními instalacemi vyžadují samostatnou přípravu správcem vydání.
Doručovací tým tvrdě pracuje na automatizaci většiny procesů zapojených do vytváření verzí, aby se snížil (střední doba do výroby, tj. čas strávený výrobou), doba od zpracování žádosti o sloučení vývojářem po nasazení na gitlab.com.
«Cílem doručovacího týmu je zajistit, že se můžeme jako společnost pohybovat rychleji, nebo alespoň zajistit, aby doručovatelé pracovali rychleji, správně?, říká Marin.
Jak zákazníci gitlab.com, tak uživatelé jejich instalací těží ze snahy doručovacího týmu zkrátit dobu cyklu a urychlit nasazení. V tomto článku vysvětlíme podobnosti a rozdíly mezi těmito dvěma metodami. a také popíšeme, jak náš doručovací tým připravuje opravy pro uživatele, kteří pracují na jejich zařízeních, a také jak zajišťujeme, aby byl gitlab.com aktuální pomocí automatického nasazení.
Co dělá správce vydání?
Členové týmu měsíčně naše vydání pro uživatele v jejich zařízeních, včetně oprav a bezpečnostních verzí, ke kterým může dojít mezi vydáními. Jsou také zodpovědní za vedení přechodu společnosti na automatizované, nepřetržité nasazení.
Vydání samoinstalace a vydání gitlab.com používají podobné pracovní postupy, ale běží v různých časech, vysvětluje Marin.
V první řadě správce vydání, bez ohledu na typ vydání, zajišťuje, že GitLab je dostupný a bezpečný od okamžiku spuštění aplikace na gitlab.com, včetně zajištění toho, aby stejné problémy neskončily v infrastruktuře zákazníků s jejich vlastní kapacity.
Jakmile je chyba nebo zranitelnost v GitLabu označena jako opravená, musí správce vydání vyhodnotit, že bude zahrnuta do oprav nebo aktualizací zabezpečení pro uživatele s jejich instalacemi. Pokud se rozhodne, že si nějaká chyba nebo zranitelnost zaslouží aktualizaci, začnou přípravné práce.
Správce vydání se musí rozhodnout, zda připravit opravu nebo kdy ji nasadit – a to velmi závisí na kontextu situace,“mezitím stroje nejsou tak dobré v řízení kontextu jako lidé“ říká Marin.
Všechno je to o opravách
Co jsou záplaty a proč je potřebujeme?
Správce vydání rozhodne, zda vydá opravu na základě závažnosti chyby.
Chyby se liší v závislosti na jejich závažnosti. Chyby S4 nebo S3 tedy mohou být stylistické, jako je posunutí pixelu nebo ikony. To je neméně důležité, ale nemá to žádný významný dopad na pracovní postup nikoho, což znamená, že pravděpodobnost, že bude vytvořena oprava pro takové chyby S3 nebo S4, je malá, vysvětluje Marin.
Zranitelnosti S1 nebo S2 však znamenají, že by uživatel neměl aktualizovat na nejnovější verzi, nebo došlo k významné chybě, která ovlivňuje pracovní postup uživatele. Pokud jsou součástí trackeru, setkalo se s nimi mnoho uživatelů, takže správce vydání okamžitě začne připravovat opravu.
Jakmile je oprava pro zranitelnosti S1 nebo S2 připravena, správce vydání začne opravovat.
Například oprava GitLab 12.10.1 byla vytvořena poté, co bylo identifikováno několik problémů s blokováním a vývojáři opravili základní problém, který je způsoboval. Release manager posoudil správnost přiřazených úrovní závažnosti a po potvrzení byl spuštěn proces uvolnění opravy, která byla připravena do XNUMX hodin po zjištění problémů s blokováním.
Když se nahromadí velké množství S4, S3 a S2, správce vydání se podívá na kontext, aby určil naléhavost vydání opravy, a když je dosaženo určitého počtu z nich, jsou všechny spojeny a uvolněny. Opravy po vydání nebo aktualizace zabezpečení jsou shrnuty v příspěvcích na blogu.
Jak správce verzí vytváří opravy
Ke generování oprav používáme GitLab CI a další funkce, jako je náš ChatOps. Release manager zahájí vydání opravy aktivací týmu ChatOps na našem interním kanálu #releases ve Slacku.
/chatops run release prepare 12.10.1ChatOps funguje v rámci Slacku na spouštění různých událostí, které pak GitLab zpracovává a spouští. Doručovací tým například nastavil ChatOps k automatizaci různých věcí při vydávání oprav.
Jakmile správce vydání spustí tým ChatOps ve Slacku, zbytek práce proběhne automaticky v GitLabu pomocí CICD. Během procesu vydání probíhá obousměrná komunikace mezi ChatOps ve Slacku a GitLab, protože správce vydání aktivuje některé z hlavních kroků v procesu.
Video níže ukazuje technický proces přípravy patche pro GitLab.
Jak funguje automatické nasazení na gitlab.com
Proces a nástroje používané k aktualizaci gitlab.com jsou podobné těm, které se používají k vytváření oprav. Aktualizace gitlab.com vyžaduje méně manuální práce z pohledu správce vydání.
Místo spouštění nasazení pomocí ChatOps používáme funkce CI, např. , pomocí kterého může správce vydání naplánovat určité akce, které mají být provedeny v požadovaný čas. Namísto ručního procesu existuje kanál, který běží pravidelně jednou za hodinu a který stahuje nové změny provedené v projektech GitLab, zabalí je a naplánuje nasazení a automaticky spustí testování, kontrolu kvality a další nezbytné kroky.
"Takže před gitlab.com máme mnoho nasazení spuštěných v různých prostředích a poté, co jsou tato prostředí v dobrém stavu a testování ukazuje dobré výsledky, správce vydání spustí akce nasazení gitlab.com," říká Marin.
Technologie CICD pro podporu aktualizací gitlab.com automatizuje celý proces do té míry, že správce vydání musí ručně spustit nasazení produkčního prostředí na gitlab.com.
Marin se podrobně věnuje procesu aktualizace gitlab.com ve videu níže.
Co dalšího dělá doručovací tým?
Hlavní rozdíl mezi procesy aktualizace gitlab.com a vydáváním záplat zákazníkům interně je v tom, že druhý proces vyžaduje více času a více manuální práce od správce vydání.
„Někdy zdržujeme vydávání oprav zákazníkům s jejich instalacemi kvůli hlášeným problémům, problémům s nástroji a protože existuje mnoho nuancí, které je třeba vzít v úvahu při vydávání jediné opravy,“ říká Marin.
Jedním z krátkodobých cílů doručovacího týmu je snížit množství ruční práce na straně release managera a urychlit tak uvolnění. Tým pracuje na zjednodušení, zefektivnění a automatizaci procesu vydávání, což pomůže vyřešit problémy s nízkou závažností (S3 a S4, Cca. překladatel). Zaměření na rychlost je klíčovým ukazatelem výkonu: je nutné zkrátit MTTP – dobu od obdržení žádosti o sloučení po nasazení výsledku na gitlab.com – ze současných 50 hodin na 8 hodin.
Doručovací tým také pracuje na migraci gitlab.com do infrastruktury založené na Kubernetes.
Redakce n.b.: Pokud jste o technologii Kubernetes již slyšeli (a nepochybuji, že ano), ale ještě jste na ni nesáhli rukama, doporučuji zúčastnit se online intenzivních kurzů , který se bude konat 28. – 30. září a , který se uskuteční 14.–16. října. To vám umožní s jistotou navigovat a pracovat s technologií.
Jedná se o dva přístupy, které sledují stejný cíl: rychlé dodání aktualizací, jak pro gitlab.com, tak pro klienty v jejich zařízeních.
Nějaké nápady nebo doporučení pro nás?
Každý může přispět do GitLabu a uvítáme zpětnou vazbu od našich čtenářů. Pokud máte nějaké nápady pro náš doručovací tým, neváhejte s upozorněním team: Delivery.
Zdroj: www.habr.com