V GitLabe riešime softvérové záplaty dvoma spôsobmi: manuálne a automaticky. Čítajte ďalej a dozviete sa viac o tom, ako správca vydaní vytvára a doručuje dôležité aktualizácie prostredníctvom automatického nasadenia na gitlab.com, ako aj záplaty pre používateľov pracujúcich s vlastnými inštaláciami.
Odporúčam nastaviť si pripomienku na inteligentných hodinkách: každý mesiac 22. môžu používatelia pracujúci s GitLabom na svojich zariadeniach vidieť aktualizácie najnovšej verzie nášho produktu. Mesačné vydanie obsahuje nové funkcie, vylepšenia existujúcich a často obsahuje aj konečné výsledky požiadaviek komunity na funkcie nástrojov alebo zlúčení.
Ako však ukazuje prax, vývoj softvéru je zriedka bezchybný. Keď sa objaví chyba alebo bezpečnostná zraniteľnosť, manažér vydania v tíme pre vývojárov vytvorí pre našich používateľov záplatu spolu s ich vlastnými nastaveniami. Stránka Gitlab.com sa aktualizuje prostredníctvom procesu CD. Tento proces CD nazývame „automatizované nasadenie“, aby sme sa vyhli zámene s funkciou CD v GitLabe. Tento proces môže zahŕňať návrhy z pull requestov odoslaných používateľmi, zákazníkmi a naším interným vývojovým tímom, takže zdĺhavá úloha vydávania záplat sa rieši dvoma veľmi odlišnými spôsobmi.
«Zabezpečujeme, aby všetko, čo vývojári urobili, bolo každý deň nasadené do všetkých prostredí predtým, ako to bude zverejnené na GitLab.com.“, vysvetľuje , Vedúci technický manažér oddelenia infraštruktúry.Predstavte si vydania pre vaše inštalácie ako snapshoty pre nasadenia na 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 svoje vlastné systémy.".
Bez ohľadu na chybu alebo zraniteľnosť dostanú klienti gitlab.com záplaty krátko po ich publikovaní, čo je výhodou automatizovaného procesu vydávania na CD. Záplaty pre používateľov s vlastnými inštaláciami vyžadujú samostatnú prípravu manažérom vydania.
Tím pre realizáciu usilovne pracuje na automatizácii väčšiny procesov spojených s vytváraním vydaní, aby sa znížilo (priemerný čas do produkcie), čas od spracovania žiadosti o stiahnutie vývojárom až po jej 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ň urýchliť prácu doručovateľov, však?„,“ hovorí Marin.
Zákazníci gitlab.com aj používatelia ich inštalácií profitujú zo snahy realizačného tímu o skrátenie cyklov a zrýchlenie nasadenia. V tomto článku vysvetlíme podobnosti a rozdiely medzi týmito dvoma prístupmi. Taktiež popíšeme, ako náš tím pre distribúciu pripravuje záplaty pre používateľov, ktorí používajú vlastné systémy, a ako udržiavame stránku gitlab.com aktuálnu pomocou automatizovaných nasadení.
Čo robí manažér vydania?
Členovia tímu mesačne Naše vydania pre používateľov v našich priestoroch vrátane opráv a bezpečnostných vydaní, ktoré sa môžu objaviť medzi jednotlivými vydaniami. Sú tiež zodpovední za prechod spoločnosti na automatizované, nepretržité nasadzovanie.
Marin vysvetľuje, že lokálne vydania a vydania na gitlab.com používajú podobné pracovné postupy, ale spúšťajú sa v rôznych časoch.
V prvom rade manažér vydania, bez ohľadu na typ vydania, zabezpečuje dostupnosť a bezpečnosť GitLabu od momentu spustenia aplikácie na gitlab.com, vrátane zabezpečenia, aby sa identické problémy s jeho možnosťami nedostali do infraštruktúry zákazníka.
Keď je chyba alebo zraniteľnosť v GitLabe označená ako opravená, manažér vydania musí vyhodnotiť, či bude zahrnutá do záplat alebo bezpečnostných aktualizácií pre používateľov s ich inštaláciami. Ak zistí, že chyba alebo zraniteľnosť si zaslúži aktualizáciu, začínajú 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.ale zatiaľ stroje nie sú v riadení kontextu také dobré ako ľudia.“, hovorí Marin.
Všetko o opravách
Čo sú to korekcie a prečo ich potrebujeme?
Manažér vydania rozhoduje o vydaní opravy v závislosti od závažnosti chyby.
Chyby sa líšia v závislosti od ich závažnosti. Napríklad chyby S4 alebo S3 môžu byť štylistické, ako napríklad nesprávne zarovnaný pixel alebo ikona. Hoci to nie je o nič menej dôležité, nemá to významný vplyv na pracovný postup, čo znamená, že pravdepodobnosť vytvorenia opravy pre takéto chyby S3 alebo S4 je nízka, vysvetľuje Marin.
Zraniteľnosti S1 alebo S2 však znamenajú, že používateľ by nemal aktualizovať na najnovšiu verziu alebo existuje závažná chyba ovplyvňujúca pracovný postup používateľa. Ak sú tieto chyby nahlásené sledovaciemu systému, znamená to, že sa s nimi stretlo veľa používateľov, takže manažér vydania okamžite začne pripravovať opravu.
Keď je oprava zraniteľnosti S1 alebo S2 pripravená, správca vydaní spustí vydanie opravy.
Napríklad, rýchla oprava GitLab 12.10.1 bola vytvorená po tom, čo bolo identifikovaných niekoľko blokujúcich problémov a vývojári vyriešili základný problém. Manažér vydania posúdil priradené úrovne závažnosti a po potvrdení bol spustený proces vydania rýchlej opravy, ktorý bol dokončený do 24 hodín od zistenia blokujúcich problémov.
Keď sa nahromadí veľký počet problémov S4, S3 a S2, manažér vydaní vyhodnotí kontext, aby určil naliehavosť vydania opravy. Po dosiahnutí určitého počtu problémov sa všetky zlúčia a vydajú. Opravy alebo aktualizácie zabezpečenia sú stručne popísané v blogových príspevkoch po vydaní.
Ako manažér vydania vytvára opravy
Na vytváranie rýchlych opráv používame GitLab CI a ďalšie funkcie, ako napríklad naše ChatOps. Správca vydaní iniciuje vydanie rýchlej opravy aktiváciou tímu ChatOps v našom internom kanáli. #releases v Slacku.
/chatops run release prepare 12.10.1ChatOps pracuje v Slacku na spúšťaní rôznych udalostí, ktoré potom spracováva a vykonáva GitLab. Napríklad tím pre realizáciu nakonfiguroval ChatOps na automatizáciu rôznych aspektov vydávania záplat.
Keď manažér vydania iniciuje príkaz ChatOps v Slacku, zvyšok práce sa v GitLabe vykoná automaticky pomocou CICD. Počas procesu vydania prebieha obojsmerná komunikácia medzi ChatOps v Slacku a GitLabem, keďže manažér vydania iniciuje niektoré kľúčové kroky.
Video nižšie zobrazuje technický proces prípravy opravy pre GitLab.
Ako funguje automatizované nasadenie na gitlab.com
Proces a nástroje používané na aktualizáciu gitlab.com sú podobné tým, ktoré sa používajú na opravy. Aktualizácia gitlab.com vyžaduje z pohľadu manažéra vydania menej manuálnej práce.
Namiesto spúšťania nasadení pomocou ChatOps používame funkcie CI, ako napríklad , ktorú môže manažér vydania použiť na naplánovanie konkrétnych akcií v konkrétnych časoch. Namiesto manuálneho procesu existuje pipeline, ktorý beží pravidelne raz za hodinu a sťahuje nové zmeny vykonané v projektoch GitLab, balí ich a plánuje nasadenie. Testovanie, QA a ďalšie potrebné kroky sa tiež spúšťajú automaticky.
„Pred spustením gitlab.com máme teda veľa nasadení spustených v rôznych prostrediach a akonáhle sú tieto prostredia v dobrom stave a testovanie ukazuje dobré výsledky, správca vydaní spustí akcie nasadenia gitlab.com,“ hovorí Marin.
Technológia CICD pre podporu aktualizácií gitlab.com automatizuje celý proces, až kým manažér vydania nemusí manuálne iniciovať nasadenie produkčného prostredia na gitlab.com.
Marin podrobne ukazuje proces aktualizácie gitlab.com vo videu nižšie.
Čo ešte robí doručovací tím?
Hlavný rozdiel medzi procesom aktualizácie na gitlab.com a vydávaním záplat zákazníkom lokálne je v tom, že druhý proces vyžaduje viac času a manuálnej práce od manažéra vydaní.
„Niekedy odkladáme vydávanie záplat pre zákazníkov s ich vlastnými inštaláciami kvôli nahláseným problémom, problémom s nástrojmi a preto, že existuje veľa nuáns, ktoré je potrebné zvážiť pri vydávaní jednej záplaty,“ hovorí Marin.
Jedným z krátkodobých cieľov realizačného tímu je znížiť množstvo manuálnej práce, ktorú vyžaduje manažér vydávania, aby sa urýchlili vydania. Tím pracuje na zjednodušení, optimalizácii a automatizácii procesu vydávania, čo pomôže urýchliť vydávanie opráv pre problémy s nízkou závažnosťou (S3 a S4, približne. prekladateľ). Zameranie sa na rýchlosť je kľúčovou metrikou výkonnosti: musíme skrátiť MTTP – čas od prijatia žiadosti o stiahnutie zmien (pull request) po nasadenie výsledku na gitlab.com – zo súčasných 50 hodín na 8 hodín.
Tím pre realizáciu tiež pracuje na migrácii gitlab.com do infraštruktúry založenej na Kubernetes.
Redakcia n.b.Ak ste už počuli o Kubernetes (a som si istý, že áno), ale ešte ste si ho nevyskúšali, odporúčam zúčastniť sa online intenzívnych školení. , ktorý sa bude konať 28. – 30. septembra a , ktorý sa uskutoční od 14. do 16. októbra. To vám umožní s istotou sa orientovať v technológii a pracovať s ňou.
Ide o dva prístupy, ktoré majú rovnaký cieľ: rýchle poskytovanie aktualizácií na gitlab.com aj zákazníkom v ich vlastných priestoroch.
Máte pre nás nejaké nápady alebo odporúčania?
Na vývoji GitLabu sa môže podieľať ktokoľvek a vítame spätnú väzbu od našich čitateľov. Ak máte nápady pre náš realizačný tím, neváhajte sa o ne podeliť. s upozornením team: Delivery.
Zdroj: hab.com
