Projektide käivitamise meetod, mida kasutatakse Slackis

Uue projekti versiooni leidmine tootmises nõuab hoolikat tasakaalu arenduse kiirusel ja lahenduse usaldusväärsusel. Slackis hinnatakse kiireid iteratsioone, lühikesi tagasiside tsükleid ja kiiret reageerimist kasutajate päringutele. Peale selle töötab ettevõttes sadu programmeerijaid, kes püüdlevad maksimaalse produktiivsuse poole.

Materjali autorid, mille tõlget me täna avaldame, ütlevad, et ettevõte, kes soovib selliseid väärtusi järgida ja samal ajal kasvada, peab pidevalt täiustama oma projektide arendamise süsteemi. Ettevõte peab panustama oma tööprotsesside läbipaistvusse ja usaldusväärsusesse, tagades, et need protsessid vastaksid projekti mastaabile. Siin räägime Slackis välja kujunenud tööprotsessidest ja mõningatest lahendustest, mis on viinud ettevõtte sellise olemasoleva projektide arenduseni.

Kuidas projektide arendamise protsessid täna toimivad

Iga PR (pull request) Slackis peab olema kindlasti läbinud koodivaatamise ning edukalt sooritanud kõik testid. Ainult pärast nende tingimuste täitmist võib programmeerija oma koodi liita projekti master haruga. Siiski toimub sellise koodi arendamine ainult põhjaameerika tööaegadel. Tulemuseks on see, et meie töötajad on oma kohtades ning täielikult valmis lahendama kõiki ootamatuid probleeme.

Iga päev viime läbi umbes 12 planeeritud arendust. Iga arenduse käigus vastutab arenduse juht, kes on määratud kõigepealt, uue kogumi tootmisse viimise eest. See on mitmeastmeline protsess, mis tagab sujuva kogumi käivitamise töörežiimis. Tänu sellele lähenemisele saame vigu avastada enne, kui need mõjutavad kõiki meie kasutajaid. Kui vigu osutub liiga palju – arendust saab tagasi keerata. Kui mõni eraldi probleem avastatakse pärast välja laskmist, saab selle hõlpsasti parandada.

Checkpoini süsteemi liides, mida Slack kasutab projektide arendamiseks

Uue versiooni arendamise protsessi tootmises võib jagada neljaks sammuks.

▍1. Uue versiooni haru loomine

Iga versioon algab uue versiooni haru loomisega meie Git-i ajaloos. See võimaldab versioonile määrata silte ja loob koha, kuhu saab teha kiireid parandusi vigadele, mis avastatakse versiooni tootmisse laskmise ettevalmistamise käigus.

▍2. Kasutusele võtmine vahekeskkonnas

Töötamise järgmine samm on kogumise kasutusele võtmine vahe-serverites ning automaatse testi käivitamine projekti üldise toimivuse kontrollimiseks (smoke test). Vahekeskkond on tootmiskeskkond, kuhu väline liiklus ei jõua. Selles keskkonnas teeme täiendavat käsitsitestimist. See annab meile lisakindluse, et muudetud projekt töötab õigesti. Ainult automatiseeritud testidest ei piisa sellise kindluse saavutamiseks.

▍3. Kasutusele võtmine dogfood- ja canary-keskkondades

Tootmises kasutusele võtmine algab dogfood-keskkonnast, mis koosneb hulkadest hostidest, mis teenindavad meie sisemisi tööruume Slackis. Kuna oleme Slacki üsna aktiivsed kasutajad, on selline lähenemine aidanud varakult paljusid vigu avastada. Pärast seda, kui oleme kinnitanud, et süsteemi põhifunktsionaalsus ei ole kahjustatud, toimub kogumise kasutusele võtmine canary-keskkonnas. See tähistab süsteeme, millele suunatakse umbes 2% tootmistrafikust.

▍4. Aeglane tootmisse viimine

Kui uue versiooni jälgimise näitajad on stabiilsed ja kui pärast projekti kasutusele võtmist canary-keskkonnas me ei saa kaebusi, jätkame aeglast tootmisse viimist. Kasutusele võtmise protsess jaguneb järgmistesse etappidesse: 10%, 25%, 50%, 75% ja 100%. Selle tulemusena saame aeglaselt suunata tootmistrafiku süsteemi uuele versioonile. Samuti on meil aega olukorra uurimiseks, kui mingeid anomaaliaid tekib.

▍Kuidas käituda, kui kasutuselevõtu käigus läheb midagi valesti?

Koodi muutmine on alati risk. Kuid me saame sellega hakkama tänu meie hästi ettevalmistatud „deploy juhtidele“, kes juhivad uue versiooni tootmisesse toomise protsessi, jälgivad jälgimisnäitajaid ja koordineerivad programmeerijate tööd, kes koodi vabastavad.

Kui midagi tõeliselt valesti läheb, püüame probleemi avastada nii vara kui võimalik. Uurime probleemi, leiame PR-i, mis vead põhjustab, rullime selle tagasi, analüüsime hoolikalt ja loome uue versiooni. Tõsi, mõnikord jääb probleem tootmisse toimetamise ajal märkamatuks. Sellises olukorras on kõige olulisem teenuse töö taastamine. Seetõttu rullime enne probleemide uurimist kohe tagasi eelmise töötava versioonini.

Töötlussüsteemi ehitusblokid

Uurime tehnoloogiaid, mis on meie projektide käitussüsteemi aluseks.

▍Kiired käivitused

Eelpool kirjeldatud tööprotsess võib tagantjärele tunduda täiesti ilmne. Kuid meie käitussüsteem ei ole selliseks kujunenud üleöö.

Kui ettevõte oli oluliselt väiksem, suutis kogu meie rakendus töötada 10 Amazon EC2 instantsil. Projekti käitamine sellises olukorras tähendas rsynci kasutamist kõigi serverite kiireks sünkroniseerimiseks. Varem eraldas uue koodi tootmisest vaid üks samm, mis oli vahekeskkond. Versioonid loodi ja kontrolliti sellises keskkonnas ning siis saadeti kohe tootmisse. Sellises süsteemis oli lihtne orienteeruda, see võimaldas igal programmeerijal igal ajal käitada tema kirjutatud koodi.

Kuid koos meie klientide arvu kasvamisega kasvas ka vajalik infrastruktuuri ulatus projekti toimimise tagamiseks. Peagi, arvesse võttes süsteemi pidevat kasvu, lõpetas meie käitusmudel, mis põhines uue koodi tõukamisel serveritesse, oma ülesande täitmise. Iga uue serveri lisamine tähendas kaua käivitamiseks vajaliku aega. Ieven strateegiad, mis põhinevad rsynci paralleelses rakendamises, omavad oma piiranguid.

Kokkuvõttes lahendasime selle probleemi, liikudes täielikult paralleelsele juurutussüsteemile, mis oli korraldatud teisiti kui vana süsteem. Nimelt ei saatnud me enam koodi serveritesse, kasutades sünkroniseerimise skripti. Iga server laadis nüüd uusi kogusid iseseisvalt, saades teada, et see on vajalik, jälgides Consul'i võtme muutust. Serverid laadisid koodi paralleelselt. See võimaldas meil hoida kõrget juurutuskiirus isegi pideva süsteemi kasvu tingimustes.

1. Tootmisserverid jälgivad Consul'i võtit. 2. Võti muutub, teavitades servereid, et nad peavad alustama uue koodi laadimist. 3. Serverid laadivad tarball-failid, mis sisaldavad rakenduse koodi.

▍Aatomaarne juurutamine

Veel ühe lahendusena, mis aitas meil jõuda mitmetasandilise juurutussüsteemini, oli aatomaarne juurutamine.

Enne aatomaarsete juurutamiste kasutuselevõttu võis iga juurutamine põhjustada rohkelt tõrketeateid. Probleem oli selles, et uute failide kopeerimise protsess tootmisserveritesse ei olnud aatomaarne. See viis lühikese ajavahemiku tekkeni, mil koodiga, mis kutsus uusi funktsioone, oli saadaval enne nende funktsioonide kättesaadavust. Kui selliseid koodi kutsuti, põhjustas see sisemisi vigu. See avaldus ebaõnnestunud API päringutena ja „katkiste” veebilehtedena.

Probleemiga tegelev meeskond lahendas selle, tutvustades mõisteid „kuumad” (hot) ja „külmad” (cold) kataloogid. Kood „kuumas” kataloogis vastutab tootmisliiklusest. Ja „külmades” kataloogides valmistatakse kood süsteemi töö ajal lihtsalt ette kasutamiseks. Juhtimise käigus kopeeritakse uus kood kasutamata „külma” katalooge. Seejärel, kui serveris ei ole aktiivseid protsesse, toimub hetkeline kataloogide vahetamine.

1. Rakenduse koodi pakkimine „külmas” kataloogis. 2. Süsteemi üleminek „külmale” kataloogile, mis muutub „kuumaks” (aatomaarne operatsioon).

Kokkuvõtted: rõhuasetuse nihkumine usaldusväärsusele.

2018. aastal kasvas projekt selliste mõõtmeteni, kus väga kiire juurutamine hakkas toote stabiilsusele kahjulikult mõjuma. Meil oli üsna arenenud juurutussüsteem, millele olime panustanud palju jõudu ja aega. Meil oli vaja vaid ümberkorraldada ja täiustada juurutamise korralduse protsesse. Meist sai üsna suur ettevõte, mille arendusi kasutati maailmas pideva side tagamiseks ja oluliste probleemide lahendamiseks. Seetõttu keskendusime usaldusväärsusele.

Me peame juurutamise protsessi Slacki uute väljaannete osas muutma turvalisemaks. Just see vajadus viis meid meie juurutussüsteemi täiustamiseni. Ütlematagi selge, et ülalpool rääkisime sellest täiustatud süsteemist. Süsteemi sügavustes jätkame me kiirete ja atomaarsete juurutustehnoloogiate kasutamist. Muutunud on see, kuidas täpselt juurutamine toimub. Meie uus süsteem on mõeldud uue koodi järkjärguliseks juurutamiseks erinevatel tasemetel ja erinevates keskkondades. Nüüd kasutame arenenumaid abivahendeid ja süsteemi jälgimise vahendeid kui kunagi varem. See võimaldab meil vigu tuvastada ja kõrvaldada kaua enne, kui need jõuavad lõppkasutajani.

Aga me ei kavatse sellel lõpetada. Me täiustame seda süsteemi pidevalt, rakendades arenenumaid abivahendeid ja automaatikavahendeid.

Lugupeetud lugejad! Kuidas toimub uute väljaannete juurutamise protsess projektides, kus teie töötate?

Allikas: habr.com