Norint pradėti gaminti naują projekto leidimą, reikia kruopščiai suderinti diegimo greitį ir sprendimo patikimumą. Slack vertina greitas iteracijas, trumpus atsiliepimų ciklus ir greitą atsakymą į vartotojo užklausas. Be to, įmonėje dirba šimtai programuotojų, kurie stengiasi būti kuo produktyvesni.
Medžiagos, kurios vertimą šiandien skelbiame, autoriai teigia, kad tokių vertybių siekianti laikytis ir tuo pačiu auganti įmonė turi nuolat tobulinti projektų diegimo sistemą. Įmonė turi investuoti į darbo procesų skaidrumą ir patikimumą, tai darant, kad šie procesai atitiktų projekto mastą. Čia kalbėsime apie „Slack“ sukurtas darbo eigas ir kai kuriuos sprendimus, paskatinusius įmonę naudoti šiandien egzistuojančią projektų diegimo sistemą.
Kaip šiandien veikia projekto diegimo procesai
Kiekvienas „Slack“ PR (ištraukimo užklausa) turi būti peržiūrėtas kodas ir turi sėkmingai išlaikyti visus testus. Tik įvykdęs šias sąlygas, programuotojas gali sujungti savo kodą į pagrindinę projekto šaką. Tačiau šis kodas naudojamas tik darbo valandomis, Šiaurės Amerikos laiku. Dėl to, kad mūsų darbuotojai yra savo darbo vietose, esame visiškai pasiruošę išspręsti bet kokias netikėtas problemas.
Kasdien atliekame apie 12 suplanuotų dislokacijų. Kiekvieno diegimo metu programuotojas, paskirtas diegimo vadovu, yra atsakingas už naujos versijos įvedimą į gamybą. Tai kelių etapų procesas, užtikrinantis sklandų surinkimo procesą. Dėl šio metodo galime aptikti klaidas, kol jos nepaveiks visų mūsų vartotojų. Jei klaidų yra per daug, agregato diegimas gali būti atšauktas. Jei po išleidimo aptinkama konkreti problema, ją galima lengvai pataisyti.
„Checkpoint“ sistemos sąsaja, kuri naudojama „Slack“ projektams diegti
Naujo leidimo diegimo gamyboje procesą galima įsivaizduoti kaip susidedantį iš keturių etapų.
▍1. Išleidimo šakos kūrimas
Kiekvienas leidimas prasideda nauja leidimo šaka – tašku mūsų Git istorijoje. Tai leidžia leidimui priskirti žymas ir yra vieta, kur galite tiesiogiai pataisyti klaidas, aptiktas ruošiant leidimą gamybinei versijai.
▍2. Diegimas sustojimo aplinkoje
Kitas žingsnis – įdiegti rinkinį sustojimo serveriuose ir paleisti automatinį viso projekto našumo testą (dūmų testą). Sustojimo aplinka yra gamybos aplinka, kuri nepriima išorinio srauto. Šioje aplinkoje atliekame papildomą rankinį testavimą. Tai suteikia mums papildomo pasitikėjimo, kad pakeistas projektas veikia tinkamai. Norint užtikrinti tokį pasitikėjimo lygį, vien automatinių testų neužtenka.
▍3. Diegimas šunų maisto ir Kanarų aplinkose
Diegimas gamyboje prasideda negalutinės versijos aplinka, atstovaujama prieglobų, aptarnaujančių mūsų vidines „Slack“ darbo sritis, rinkinys. Kadangi esame labai aktyvūs „Slack“ vartotojai, taikydami šį metodą galėjome pastebėti daug klaidų diegimo pradžioje. Įsitikinus, kad pagrindinės sistemos funkcionalumas nėra pažeistas, agregatas dislokuojamas kanarėlių aplinkoje. Tai reiškia sistemas, kurios sudaro maždaug 2 % gamybos srauto.
▍4. Laipsniškas išleidimas į gamybą
Jei naujos laidos stebėjimo rodikliai pasirodytų stabilūs, o diegę projektą kanarinėje aplinkoje nesulaukėme jokių nusiskundimų, toliau palaipsniui perkeliame gamybinius serverius į naują laidą. Diegimo procesas yra padalintas į šiuos etapus: 10%, 25%, 50%, 75% ir 100%. Dėl to galime lėtai perkelti gamybos srautą į naują sistemos leidimą. Tuo pat metu turime laiko ištirti situaciją, jei bus aptikta kokių nors nukrypimų.
▍Ką daryti, jei diegimo metu kažkas negerai?
Kodo modifikavimas visada yra rizika. Tačiau su tuo susidorojame dėl gerai apmokytų „diegimo lyderių“, kurie valdo naujos leidimo į gamybą procesą, stebi stebėjimo rodiklius ir koordinuoja programuotojų, išleidžiančių kodą, darbą.
Jei kas nors iš tikrųjų negerai, stengiamės kuo anksčiau nustatyti problemą. Ištiriame problemą, surandame klaidas sukeliantį PR, grąžiname jį atgal, kruopščiai analizuojame ir sukuriame naują versiją. Tiesa, kartais problema lieka nepastebėta, kol projektas nepradedamas gaminti. Esant tokiai situacijai, svarbiausia atkurti paslaugą. Todėl, prieš pradėdami tirti problemą, nedelsdami grįžtame prie ankstesnės veikiančios versijos.
Diegimo sistemos blokai
Pažvelkime į technologijas, kuriomis grindžiama mūsų projekto diegimo sistema.
▍Greitas diegimas
Aukščiau aprašyta darbo eiga retrospektyviai gali atrodyti šiek tiek akivaizdi. Tačiau mūsų diegimo sistema tokia netapo iš karto.
Kai įmonė buvo daug mažesnė, visa mūsų programa galėjo veikti 10 Amazon EC2 egzempliorių. Projekto diegimas šioje situacijoje reiškė naudoti rsync, kad būtų galima greitai sinchronizuoti visus serverius. Anksčiau naujasis kodas buvo tik vienu žingsniu nuo gamybos, o jį reprezentavo sustojimo aplinka. Agregatai buvo sukurti ir išbandyti tokioje aplinkoje, o tada iš karto pateko į gamybą. Tokią sistemą buvo labai lengva suprasti; ji leido bet kuriam programuotojui bet kuriuo metu įdiegti savo parašytą kodą.
Tačiau augant mūsų klientų skaičiui, augo ir infrastruktūros, reikalingos projektui palaikyti, mastas. Netrukus, atsižvelgiant į nuolatinį sistemos augimą, mūsų diegimo modelis, pagrįstas naujo kodo siuntimu į serverius, nebeatliko savo darbo. Būtent, pridedant kiekvieną naują serverį, pailgėjo laikas, reikalingas diegimui užbaigti. Net strategijos, pagrįstos lygiagrečiu rsync naudojimu, turi tam tikrų apribojimų.
Šią problemą išsprendėme pereidami prie visiškai lygiagrečios diegimo sistemos, kuri buvo sukurta kitaip nei senoji sistema. Būtent dabar mes nesiuntėme kodo į serverius naudodami sinchronizavimo scenarijų. Dabar kiekvienas serveris savarankiškai atsisiuntė naują rinkinį, žinodamas, kad tai reikia padaryti stebint Consul rakto pakeitimą. Serveriai kodą įkėlė lygiagrečiai. Tai leido mums išlaikyti didelį diegimo greitį net nuolatinio sistemos augimo aplinkoje.
1. Gamybos serveriai stebi Consul raktą. 2. Pagrindiniai pakeitimai, tai praneša serveriams, kad jie turi pradėti atsisiųsti naują kodą. 3. Serveriai atsisiunčia tarball failus su programos kodu
▍Atominis dislokavimas
Kitas sprendimas, padėjęs mums pasiekti kelių pakopų diegimo sistemą, buvo atominis diegimas.
Prieš naudojant atominį diegimą, kiekvienas diegimas gali sukelti daug klaidų pranešimų. Faktas yra tas, kad naujų failų kopijavimo į gamybos serverius procesas nebuvo atominis. Dėl to atsirado trumpas laiko langas, kai kodas, iškvietęs naujas funkcijas, buvo pasiekiamas anksčiau nei buvo pasiekiamos pačios funkcijos. Kai toks kodas buvo iškviestas, buvo grąžintos vidinės klaidos. Tai pasireiškė nesėkmingomis API užklausomis ir neveikiančiais tinklalapiais.
Su šia problema dirbusi komanda ją išsprendė pristatydama „karštų“ ir „šaltų“ katalogų sąvokas. Kodas karštajame kataloge yra atsakingas už gamybos srauto apdorojimą. O „šaltuose“ kataloguose kodas, kol sistema veikia, tik ruošiamas naudoti. Diegimo metu naujas kodas nukopijuojamas į nenaudojamą šaltąjį katalogą. Tada, kai serveryje nėra aktyvių procesų, atliekamas momentinis katalogų perjungimas.
1. Programos kodo išpakavimas į „šaltą“ katalogą. 2. Sistemos perjungimas į „šaltą“ katalogą, kuris tampa „karštas“ (atominis veikimas)
Rezultatai: dėmesys perkeliamas į patikimumą
2018 metais projektas išaugo iki tokio masto, kad labai greitas diegimas pradėjo kenkti gaminio stabilumui. Turėjome labai pažangią diegimo sistemą, į kurią investavome daug laiko ir pastangų. Viskas, ką turėjome padaryti, buvo atkurti ir tobulinti diegimo procesus. Išaugome į gana didelę įmonę, kurios plėtra buvo naudojama visame pasaulyje organizuojant nenutrūkstamą komunikaciją ir sprendžiant svarbias problemas. Todėl mūsų dėmesio centre atsidūrė patikimumas.
Mums reikėjo padaryti saugesnį naujų „Slack“ leidimų diegimo procesą. Šis poreikis paskatino mus patobulinti diegimo sistemą. Tiesą sakant, šią patobulintą sistemą aptarėme aukščiau. Sistemos gilumoje ir toliau naudojame greito ir atominio diegimo technologijas. Pasikeitė diegimo būdas. Mūsų nauja sistema sukurta taip, kad laipsniškai diegtų naują kodą skirtinguose lygiuose, skirtingose aplinkose. Dabar naudojame pažangesnius palaikymo ir sistemos stebėjimo įrankius nei anksčiau. Tai suteikia mums galimybę sugauti ir ištaisyti klaidas dar gerokai anksčiau, nei jos pasiekia galutinį vartotoją.
Bet mes neketiname sustoti. Šią sistemą nuolat tobuliname, naudojame pažangesnius pagalbinius ir darbo automatizavimo įrankius.
Mieli skaitytojai! Kaip vyksta naujų projekto leidimų diegimo procesas ten, kur dirbate?
Šaltinis: www.habr.com