V GitLab spracovávame opravy softvéru dvoma spôsobmi: manuálne a automaticky. Čítajte ďalej a dozviete sa o úlohe správcu vydania pri vytváraní a poskytovaní dôležitých aktualizácií prostredníctvom automatizovaného nasadenia na gitlab.com, ako aj o záplatách, s ktorými môžu používatelia pracovať na svojich vlastných inštaláciách.
Odporúčam nastaviť si pripomenutie na svojich inteligentných hodinkách: každý mesiac 22. dňa môžu používatelia pracujúci s GitLab vo svojich zariadeniach vidieť aktualizácie aktuálnej verzie nášho produktu. Mesačné vydanie obsahuje nové funkcie, vývoj existujúcich a často ukazuje konečný výsledok žiadostí komunity o nástroje alebo zlúčenia.
Ako však ukazuje prax, vývoj softvéru je zriedka bez chýb. Keď sa zistí chyba alebo slabé miesto zabezpečenia, správca vydania v tíme doručovania vytvorí opravu pre našich používateľov s ich inštaláciami. Gitlab.com sa aktualizuje počas procesu CD. Tento proces CD nazývame automatické nasadenie, aby sme sa vyhli zámene s funkciou CD v GitLab. Tento proces môže zahŕňať návrhy z požiadaviek na stiahnutie odoslaných používateľmi, zákazníkmi a naším interným vývojovým tímom, takže riešenie nudného problému s vydávaním opráv je vyriešené dvoma veľmi odlišnými spôsobmi.
«Zabezpečujeme, aby sa všetko, čo vývojári vyrobia, nasadilo do všetkých prostredí každý deň predtým, ako to uvedieme na GitLab.com“, vysvetľuje , hlavný technický manažér, oddelenie infraštruktúry. "Predstavte si vydania pre vaše inštalácie ako snímky pre nasadenia gitlab.com, pre ktoré sme pridali samostatné kroky na vytvorenie balíka, aby ho naši používatelia mohli použiť na inštaláciu na svojich inštaláciách.".
Bez ohľadu na chybu alebo zraniteľnosť dostanú zákazníci gitlab.com opravy krátko po ich zverejnení, čo je výhodou automatizovaného procesu CD. Opravy pre používateľov s vlastnými inštaláciami vyžadujú samostatnú prípravu správcom vydania.
Doručovací tím usilovne pracuje na automatizácii väčšiny procesov zapojených do vytvárania verzií, aby ich zredukoval (stredný čas do výroby, t. j. čas strávený výrobou), časový úsek od spracovania žiadosti o zlúčenie vývojárom po nasadenie na gitlab.com.
«Cieľom doručovacieho tímu je zabezpečiť, aby sme sa ako spoločnosť mohli pohybovať rýchlejšie, alebo aspoň prinútiť doručovateľov pracovať rýchlejšie, správne?, hovorí Marin.
Zákazníci gitlab.com aj používatelia ich inštalácií profitujú zo snahy doručovacieho tímu skrátiť časy cyklov a urýchliť nasadenia. V tomto článku vysvetlíme podobnosti a rozdiely medzi týmito dvoma metódami. a tiež opíšeme, ako náš doručovací tím pripravuje opravy pre používateľov, ktorí bežia na mieste, a ako udržiavame gitlab.com v aktuálnom stave pomocou automatického nasadenia.
Čo robí správca vydania?
Členovia tímu mesačne naše vydania pre používateľov v ich zariadeniach vrátane opráv a bezpečnostných vydaní, ktoré sa môžu vyskytnúť medzi vydaniami. Sú tiež zodpovední za vedenie prechodu spoločnosti na automatizované, nepretržité nasadenie.
Samoinštalačné vydania a vydania gitlab.com používajú podobné pracovné postupy, ale bežia v rôznych časoch, vysvetľuje Marin.
V prvom rade správca vydania bez ohľadu na typ vydania zaisťuje dostupnosť a bezpečnosť GitLab od okamihu spustenia aplikácie na gitlab.com, vrátane toho, že rovnaké problémy neskončia v infraštruktúre zákazníkov s ich vlastné kapacity.
Keď je chyba alebo zraniteľnosť označená ako opravená v GitLab, správca vydania musí posúdiť, či bude zahrnutá do opráv alebo bezpečnostných aktualizácií pre používateľov s ich inštaláciami. Ak sa rozhodne, že chyba alebo zraniteľnosť si zaslúži aktualizáciu, začnú sa prípravné práce.
Manažér vydania sa musí rozhodnúť, či pripraví opravu alebo kedy ju nasadí – a to vo veľkej miere závisí od kontextu situácie,“medzitým stroje nie sú také dobré v spravovaní kontextu ako ľudia“ hovorí Marin.
Všetko je to o opravách
Čo sú záplaty a prečo ich potrebujeme?
Manažér vydania rozhodne, či vydá opravu na základe závažnosti chyby.
Chyby sa líšia v závislosti od ich závažnosti. Takže chyby S4 alebo S3 môžu byť štylistické, ako napríklad posunutie pixelov alebo ikon. To nie je o nič menej dôležité, ale nemá to žiadny významný vplyv na pracovný tok nikoho, čo znamená, že pravdepodobnosť, že sa vytvorí oprava pre takéto chyby S3 alebo S4, je malá, vysvetľuje Marin.
Zraniteľnosť S1 alebo S2 však znamená, že používateľ by nemal aktualizovať na najnovšiu verziu, alebo sa vyskytla významná chyba, ktorá ovplyvňuje pracovný postup používateľa. Ak sú zahrnuté v sledovači, mnohí používatelia sa s nimi stretli, takže správca vydania okamžite začne pripravovať opravu.
Keď je oprava pre chyby zabezpečenia S1 alebo S2 pripravená, správca vydania začne s uvoľňovaním opravy.
Napríklad oprava GitLab 12.10.1 bola vytvorená po zistení niekoľkých problémov s blokovaním a vývojári opravili základný problém, ktorý ich spôsoboval. Release manager posúdil správnosť priradených úrovní závažnosti a po potvrdení bol spustený proces uvoľnenia opravy, ktorá bola pripravená do XNUMX hodín po zistení problémov s blokovaním.
Keď sa nahromadí veľa S4, S3 a S2, správca vydania sa pozrie na kontext, aby určil naliehavosť vydania opravy, a keď sa dosiahne určitý počet z nich, všetky sa spoja a uvoľnia. Opravy po vydaní alebo bezpečnostné aktualizácie sú zhrnuté v blogových príspevkoch.
Ako správca vydania vytvára záplaty
Na generovanie záplat používame GitLab CI a ďalšie funkcie, ako je náš ChatOps. Správca vydania spúšťa vydanie opravy aktiváciou tímu ChatOps na našom internom kanáli #releases v Slacku.
/chatops run release prepare 12.10.1ChatOps funguje v rámci Slacku a spúšťa rôzne udalosti, ktoré potom GitLab spracuje a vykoná. Napríklad doručovací tím nastavil ChatOps na automatizáciu rôznych vecí na vydávanie opráv.
Keď správca vydania spustí tím ChatOps v Slacku, zvyšok práce prebehne automaticky v GitLab pomocou CICD. Počas procesu vydania existuje obojsmerná komunikácia medzi ChatOps v Slacku a GitLab, pretože správca vydania aktivuje niektoré z hlavných krokov v procese.
Video nižšie ukazuje technický proces prípravy opravy pre GitLab.
Ako funguje automatické nasadenie na gitlab.com
Proces a nástroje používané na aktualizáciu gitlab.com sú podobné tým, ktoré sa používajú na vytváranie záplat. Aktualizácia gitlab.com vyžaduje menej manuálnej práce z pohľadu správcu vydania.
Namiesto spúšťania nasadení pomocou ChatOps využívame CI funkcie napr. , pomocou ktorého môže správca vydania naplánovať vykonanie určitých akcií v požadovanom čase. Namiesto manuálneho procesu existuje kanál, ktorý beží pravidelne raz za hodinu a ktorý sťahuje nové zmeny vykonané v projektoch GitLab, zabalí ich a naplánuje nasadenie a automaticky spustí testovanie, kontrolu kvality a ďalšie potrebné kroky.
„Pred gitlab.com máme veľa nasadení spustených v rôznych prostrediach a keď sú tieto prostredia v dobrom stave a testovanie ukazuje dobré výsledky, správca vydania spustí akcie nasadenia gitlab.com,“ hovorí Marin.
Technológia CICD na podporu aktualizácií gitlab.com automatizuje celý proces do tej miery, že správca vydania musí manuálne spustiť nasadenie produkčného prostredia na gitlab.com.
Marin sa podrobne zaoberá procesom aktualizácie gitlab.com vo videu nižšie.
Čo ešte robí doručovací tím?
Hlavný rozdiel medzi aktualizačnými procesmi gitlab.com a vydávaním záplat zákazníkom interne je v tom, že druhý proces vyžaduje viac času a viac manuálnej práce od správcu vydania.
„Niekedy odkladáme uvoľnenie záplat zákazníkom s ich inštaláciami kvôli nahláseným problémom, problémom s nástrojmi a pretože existuje veľa nuancií, ktoré je potrebné vziať do úvahy pri vydávaní jednej opravy,“ hovorí Marin.
Jedným z krátkodobých cieľov dodávateľského tímu je znížiť množstvo manuálnej práce na strane manažéra uvoľnenia, aby sa urýchlilo uvoľnenie. Tím pracuje na zjednodušení, zefektívnení a automatizácii procesu vydávania, čo pomôže získať opravy problémov s nízkou závažnosťou (S3 a S4, približne. prekladateľ). Zameranie na rýchlosť je kľúčovým ukazovateľom výkonu: je potrebné skrátiť MTTP – čas od prijatia žiadosti o zlúčenie po nasadenie výsledku na gitlab.com – zo súčasných 50 hodín na 8 hodín.
Doručovací tím tiež pracuje na migrácii gitlab.com na infraštruktúru založenú na Kubernetes.
Redakcia n.b.: Ak ste už o technológii Kubernetes počuli (a nepochybujem, že áno), ale ešte ste sa jej nedotkli rukami, odporúčam zúčastniť sa online intenzívnych kurzov , ktorý sa bude konať 28. – 30. septembra a , ktorý sa uskutoční 14.–16. To vám umožní s istotou navigovať a pracovať s technológiou.
Ide o dva prístupy, ktoré sledujú rovnaký cieľ: rýchle dodávanie aktualizácií pre gitlab.com aj pre klientov v ich prevádzkach.
Máte pre nás nejaké nápady alebo odporúčania?
Každý je vítaný, ak môže prispieť do GitLabu, a uvítame spätnú väzbu od našich čitateľov. Ak máte nejaké nápady pre náš doručovateľský tím, neváhajte s upozornením team: Delivery.
Zdroj: hab.com