Projektide juurutamise meetod, mida kasutatakse Slackis

Uue projekti versiooni käivitamine nõuab hoolikat tasakaalu leidmist juurutamise kiirus ning lahenduse usaldusväärsuse vahel. Slackis hinnatakse kiireid iteratsioone, lühikesi tagasiside tsükleid ja kiiret reageerimist kasutajate päringutele. Lisaks sellele on ettevõttes sadu programmeerijaid, kes püüdlevad maksimaalse tootlikkuse poole.

Kunstnikud, kelle materjali tõlget täna avaldame, ütlevad, et ettevõte, kes püüab järgida selliseid väärtusi ja samal ajal kasvada, peab pidevalt täiustama oma projekti juurutamise süsteemi. Ettevõttel tuleb pühendada jõud protsesside läbipaistvusele ja usaldusväärsusele, et vastata projekti ulatusele. Siin käsitleme Slackis välja kujunenud tööprotsesse ja mõningaid lahendusi, mis viisid ettevõtte sellise tänapäevase projekti juurutamise süsteemi kasutamise juurde.

Kuidas projektide juurutamise protsessid tänapäeval toimivad

Iga PR (pull request) Slackis peab olema kindlasti läbinud koodivaatluse ja edukalt läbinud kõik testid. Alles pärast nende tingimuste täitmist võib arendaja oma koodi ühendada projekti master-haru. Siiski, sellise koodi juurutamine toimub vaid tööaegadel põhjaameerika ajavööndis. Seetõttu oleme, kuna meie töötajad on töökohtadel, täielikult valmis lahendama ootamatuid probleeme.

Igal päeval teeme umbes 12 planeeritud juurutust. Iga juurutamise käigus vastutab juurutamise juhtiv arendaja uue versiooni toimetamise eest tootmisse. See on mitmeastmeline protsess, mis tagab sujuva versiooni viimise töörežiimi. Tänu sellele lähenemisele saame avastada vigu enne, kui need mõjutavad kõiki meie kasutajaid. Kui vigu on liiga palju, võib versiooni juurutamise tagasi võtta. Kui aga mõni konkreetne probleem tuvastatakse pärast väljalaskmist, on lihtne sellele parandust välja anda.

Slackis kasutatav Checkpoint süsteemi liides projektide juurutamiseks

Uue väljaande juurutamise protsessi võib jagada neljaks sammuks.

▍1. Väljaande haru loomine

Iga väljaanne algab uue haru loomisega, mis toimub meie Git-i ajaloos. See võimaldab väljaandele silte määrata ja loob koha, kuhu saab teha kiireid parandusi, kui ilmnevad vead, mis leiti väljaande tootmisse viimise ettevalmistamisel.

▍2. Juurutamine vahekeskkonnas

Töö järgmine samm on versiooni juurutamine vahe (staging) serveritesse ja automaatse testimise käivitamine projekti üldise toimivuse (smoke test) kontrollimiseks. Vahekeskkond on tootmiskeskkond, kuhu väline liiklus ei pääse. Selles keskkonnas teeme täiendavat käsitsi testimist. See annab meile täiendava kindlustunde, et muudetud projekt töötab õigesti. Ainuüksi automatiseeritud testidest ei piisa, et sellist kindlustunnet saavutada.

▍3. Juurutamine dogfood- ja canary- keskkondades

Tootmise tootmisringis algab dogfood-keskkonna loomisega, mille esinduseks on hulk hoste, mis haldavad meie sisemisi Slack-tööruume. Kuna oleme Slacki aktiivsed kasutajad, aitas selline lähenemine tuvastada palju vigu varases tootmisfaasis. Pärast seda, kui oleme veendunud, et süsteemi põhifunktsionaalsus ei ole häiritud, toimub versiooni juurutamine canary-keskkonnas. See koosneb süsteemidest, mis saavad umbes 2% tootmist liiklusest.

▍4. Aeglane juurutamine tootmisse

Kui uue väljaande jälgimise näitajad on stabiilsed ning pärast projekti juurutamist canary-keskkonnas ei ole me saanud kaebusi, jätkame tootmisserverite üleminekut uuele väljaandele järk-järgult. Juurutamisprotsess jaguneb järgmistesse etappidesse: 10%, 25%, 50%, 75% ja 100%. Sel viisil saame aeglaselt suunata tootmisliiklust uuele süsteemi väljaandele. Samuti on meil aega olukorra uurimiseks, kui tuvastame mingeid anomaaliaid.

▍Mida teha, kui juurutamise käigus midagi läks valesti?

Koodi muutmine on alati risk. Aga me saame sellega hakkama tänu meie hästi ettevalmistatud „juhtidele juurutamises“, kes juhivad uue versiooni tootmisse toomise protsessi, jälgivad jälgimisnäitajaid ja koordineerivad arendajate tööd, kes koodi väljastavad.

Kui midagi tõesti läheb valesti, püüame probleemi avastada nii varakult kui võimalik. Uurime probleemi, leiame PR-i, mis vigu tekitab, tagandame selle, analüüsime hoolikalt ja loome uue versiooni. Tõele au andes, mõnikord jääb probleem märkamatuks kuni projekti tootmisse viimiseni. Sellises olukorras on kõige olulisem taastada teenuse töö. Seetõttu tagandame enne probleemi uurimist kohe eelmise tööversiooni.

Juurutamissüsteemi ehitusplokid

Vaatame tehnoloogiaid, mis on meie projektide juurutamissüsteemi aluseks.

▍Kiired juurutamised

Ülaltoodud tööprotsess võib tagantjärele tunduda täiesti ilmne. Kuid meie juurutamissüsteem ei saanud selliseks kaugeltki kohe.

Kui ettevõte oli oluliselt väiksem, sai meie rakendus töötada 10 Amazon EC2 instantsil. Projekti käivitamine sellises olukorras tähendas rsynci kasutamist, et kiiresti sünkroonida kõiki servereid. Varem eraldas uue koodi tootmisest ainult üks samm, mida esindas vahekeskkond. Kogumikud loodi ja kontrolliti sellises keskkonnas ning seejärel suundusid need otse tootmisse. Sellises süsteemis orienteerumine oli väga lihtne, see võimaldas igal programmeerijal igal ajal käivitada kirjutatud koodi.

Kuid kliendibaasi kasvades suurenes ka infrastruktuuri ulatus, mis oli vajalik projekti toimimiseks. Varsti, arvestades süsteemi pidevat kasvu, ei suutnud meie uue koodi serveritesse toimetamisele tuginev disain oma ülesandeid enam täita. Nimelt tähendas iga uue serveri lisamine, et suurenes ajakulu, mis oli vajalik käivitamiseks. Ieven paralleelsetel rsynci rakendamisel põhinevates strateegiates on teatud piirangud.

Kokkuvõttes lahendasime selle probleemi, minnes üle täiesti paralleelsele juurutussüsteemile, mis ei olnud üles seatud nagu vana süsteem. Nimelt, nüüd ei saatnud me koodi serveritesse, kasutades sünkroonimisskripti. Iga server laadis ise uue kogumi alla, teades, et see tuleb teha, jälgides Consul'i võtme muutust. Serverid laadisid koodi paralleelselt. See võimaldas meil hoida kõrget juurutamiskiirus, isegi pideva süsteemi kasvu tingimustes.

1. Tootmisserverid jälgivad Consul'i võtit. 2. Võti muutub, mis annab serveritele teada, et nad peavad alustama uue koodi laadimist. 3. Serverid laadivad alla tarball-failid rakenduskoodiga.

▍Atoomilised juurutamised

Veel ühe lahendusena, mis aitas meil minna üle tasemel juurutussüsteemile, sai atoombne juurutamine.

Enne aatomaarsete juurutuste kasutuselevõttu võis iga juurutamine põhjustada suure hulga vigade teateid. Asi on selles, et uute failide kopeerimise protsess tootmisserveritesse ei olnud aatomaarne. See tõi kaasa lühikese ajavahemiku, mille jooksul kood, mis kutsus esile uusi funktsioone, oli saadaval enne, kui need funktsioonid endid olid kättesaadavad. Kui sellist koodi kutsuti, põhjustas see sisemisi vigu. See avaldus API-päringute ebaõnnestumises ja „rikutud” veebilehtedes.

Probleemiga tegelenud meeskond lahendas selle, tuues sisse mõisted „kuumad” (hot) ja „külmad” (cold) kataloogid. „Kuumas” kataloogis olev kood vastutab tootmistrafiku töötlemise eest. Külmades kataloogides valmistatakse kood süsteemi töötamise ajal lihtsalt kasutamiseks ette. Juurutamise käigus kopeeritakse uus kood kasutamata „külma” katalooge. Seejärel viiakse, kui serveris ei ole aktiivseid protsesse, läbi kohene kataloogide vahetus.

1. Rakenduse koodi pakkimine „külma“ direktori. 2. Süsteemi üleviimine „külma“ direktorisse, mis muutub „kuumaks“ (aatomaarne operatsioon)

Kokkuvõtted: rõhu nihkumine usaldusväärsusele

Aastal 2018 kasvas projekt sellistele mõõtmetele, et väga kiire juurutamine hakkas kahjustama toote stabiilsust. Meil oli üsna arenenud juurutussüsteem, millesse olime investeerinud palju aega ja jõudu. Me pidime vaid ümber korraldama ja täiustama juurutamise protsesse. Meist sai piisavalt suur ettevõte, mille arendusi kasutati üle kogu maailma, et tagada katkestusteta side ja lahendada olulisi ülesandeid. Seetõttu sai usaldusväärsus keskseks tähelepanu all olevaks teemaks.

Meil oli vaja muuta Slacki uute versioonide juurutamisprotsessi turvalisemaks. See vajadus viis meid meie juurutamissüsteemi täiustamiseni. Tegelikult arutasime just seda täiustatud süsteemi. Süsteemi sisemuses jätkame kiire ja atomaarse juurutamise tehnoloogiate kasutamist. On muutunud see, kuidas täpselt juurutamine toimub. Meie uus süsteem on loodud uue koodi järkjärguliseks juurutamiseks erinevates etappides ja keskkondades. Nüüd kasutame arenenumaid abivahendeid ja süsteemi jälgimise vahendeid kui kunagi varem. See annab meile võimaluse tuvastada ja kõrvaldada tõrkeid palju enne, kui need saavad võimaluse jõuda lõppkasutajani.

Kuid me ei kavatse peatuda saavutatu peal. Me pidevalt täiustame seda süsteemi, rakendades arenenumaid abivahendeid ja töö automatiseerimise vahendeid.

Lugupidamisega lugejad! Kuidas on korraldatud uute versioonide juurutamisprotsess seal, kus teie töötate?

Allikas: habr.com