Izlaz novog izdanja projekta u produkciju zahtijeva pažljivo usklađivanje između brzine implementacije i pouzdanosti rješenja. U Slacku cijene brze iteracije, kratke cikluse povratnih informacija i brzu reakciju na korisničke zahtjeve. Osim toga, kompanija ima stotine programera koji teže maksimalnoj produktivnosti.
Autori materijala, čiji prijevod danas objavljujemo, kažu da kompanija koja nastoji slijediti slične vrijednosti i pritom raste, mora stalno usavršavati svoj sustav implementacije projekata. Kompanija treba ulagati napore u transparentnost i pouzdanost radnih procesa, kako bi oni odgovarali razmjerima projekta. Ovdje će biti riječ o radnim procesima uspostavljenim u Slacku i o nekim rješenjima koja su dovela do korištenja sadašnjeg sustava implementacije projekata.
Kako procesi implementacije projekata danas funkcioniraju
Svaki PR (pull request) u Slacku mora proći kod-reviziju i proći sve testove. Tek nakon što su ispunjeni ovi uvjeti, programer može spojiti svoj kod s master granom projekta. Međutim, implementacija takvog koda izvodi se samo tijekom radnih sati po sjevernoameričkom vremenu. Kao rezultat toga, zahvaljujući tome što su naši zaposlenici prisutni na radnim mjestima, potpuno smo spremni za rješavanje bilo kakvih neočekivanih problema.
Svaki dan provodimo oko 12 planiranih implementacija. Tijekom svake implementacije, programer zadužen za vođenje implementacije odgovara za iznošenje nove verzije u produkciju. To je višestepeni proces koji osigurava glatko iznošenje verzije u radno stanje. Zahvaljujući ovom pristupu možemo otkriti greške prije nego što utječu na sve naše korisnike. Ako se pokaže da ima previše grešaka, implementacija verzije može se vratiti. Ako se neka pojedinačna greška otkrije nakon izdanja, lako se može izdati ispravak.
Sučelje sustava Checkpoint, koje se koristi u Slacku za implementaciju projekata
Proces implementacije novog izdanja u produkciji može se prikazati kao sastavljen od četiri koraka.
▍1. Stvaranje izdavačke grane
Svako izdanje započinje novom izdavačkom granom u našoj Git povijesti. To omogućuje dodavanje oznaka izdanju i pruža mjesto za brzo ispravke grešaka pronađenih tijekom pripreme izdanja za produkciju.
▍2. Implementacija u međufazno okruženje
Sljedeći korak je implementacija verzije na međufazne (staging) servere i pokretanje automatskog testa za opću funkcionalnost projekta (smoke test). Međufazno okruženje je produkcijsko okruženje koje ne prima vanjski promet. U ovom okruženju provodimo dodatno ručno testiranje. To nam daje dodatnu sigurnost da izmijenjeni projekt ispravno radi. Samo automatizirani testovi nisu dovoljni za postizanje takve sigurnosti.
▍3. Implementacija u dogfood i canary okruženja
Implementacija u produkciji započinje s dogfood okruženjem, koje se sastoji od niza hostova koji opslužuju naše interne Slack radne prostore. Budući da smo vrlo aktivni korisnici Slacka, primjena ovog pristupa pomogla je otkriti brojne greške u ranim fazama implementacije. Nakon što smo se uvjerili da osnovna funkcionalnost sustava nije narušena, provodimo implementaciju verzije u canary okruženju. To su sustavi kojima prolazi oko 2% produkcijskog prometa.
▍4. Postepeno uvođenje u produkciju
Ako pokazatelji praćenja novog izdanja ostanu stabilni, i ako nakon implementacije projekta u canary okruženju ne primimo pritužbe, nastavljamo s postepenim prebacivanjem produkcijskih servera na novo izdanje. Proces implementacije podijeljen je na sljedeće faze: 10%, 25%, 50%, 75% i 100%. Tako možemo polako preusmjeriti produkcijski promet na novo izdanje sustava. U međuvremenu imamo vremena za istraživanje situacije ukoliko se pojave neke anomalije.
▍Što učiniti ako nešto pođe po zlu tijekom implementacije?
Modifikacija koda uvijek nosi rizik. No, uspijevamo se nositi s tim zahvaljujući dobro pripremljenim "voditeljima implementacije" koji upravljaju procesom izlaska nove verzije u produkciju, prate pokazatelje nadzora i koordiniraju rad programera koji izvode kod.
U slučaju da nešto zaista pođe po zlu, trudimo se otkriti problem što je ranije moguće. Istražujemo problem, pronalazimo PR koji uzrokuje greške, vraćamo ga, pažljivo analiziramo i kreiramo novu verziju. Međutim, ponekad problem ostane nezapažen sve do izlaska projekta u produkciju. U takvoj situaciji najvažnije je obnoviti funkcioniranje usluge. Stoga, prije nego što započnemo istraživanje problema, odmah se vraćamo na prethodnu radnu verziju.
Građevni blokovi sustava implementacije
Razmotrimo tehnologije koje leže u osnovi našeg sustava implementacije projekata.
▍Brze implementacije
Gore opisani radni proces može izgledati, u retrospektivi, potpuno očito. No, naš sustav implementacije nije postao takav odmah.
Kad je tvrtka bila znatno manja, cijela naša aplikacija mogla je raditi na 10 Amazon EC2 instanci. Implementacija projekta u takvoj situaciji značila je korištenje rsync za brzu sinkronizaciju svih poslužitelja. Prije, nova verzija u produkciji bila je odvojena samo jednim korakom, koji je predstavljao međuprostor. Verzije su se kreirale i provjeravale u tom prostoru, a zatim su odmah išle u produkciju. Bilo je vrlo lako shvatiti takav sustav, omogućavao je bilo kojem programeru da bilo kada implementira svoj kod.
No, kako je broj naših klijenata rastao, rasla je i infrastruktura potrebna za podršku radu projekta. Ubrzo, s obzirom na stalni rast sustava, naš model implementacije, koji se temeljio na slanju novog koda na poslužitelje, prestao je ispunjavati svoju ulogu. Naime, dodavanje svakog novog poslužitelja značilo je povećanje vremena potrebnog za izvršenje implementacije. Čak i strategije temeljen na paralelnom korištenju rsync-a imaju određena ograničenja.
Na kraju smo riješili ovaj problem prelaskom na potpuno paralelni sustav implementacije, koji nije bio postavljen kao stari sustav. Naime, sada nismo slali kod na poslužitelje koristeći skriptu za sinkronizaciju. Sada je svaki poslužitelj samostalno preuzimao novu verziju, saznajući da to treba učiniti putem praćenja promjene ključa Consul. Poslužitelji su preuzimali kod paralelno. To nam je omogućilo održavanje visoke brzine implementacije čak i u uvjetima stalnog rasta sustava.
1. Proizvodni poslužitelji prate ključ Consul. 2. Kada se ključ promijeni, to obavještava poslužitelje da započnu preuzimanje novog koda. 3. Poslužitelji preuzimaju tarball datoteke s aplikacijskim kodom.
▍Atomske implementacije
Još jedno rješenje koje nam je pomoglo da dođemo do višeslojnog sustava implementacije bilo je atomsko implementiranje.
Prije korištenja atomske implementacije, svaka implementacija mogla je dovesti do velikog broja poruka o pogreškama. Naime, proces kopiranja novih datoteka na proizvodne poslužitelje nije bio atomaran. To je dovelo do postojanja kratkog vremenskog perioda kada je kod koji je pozivao nove funkcije bio dostupan prije nego što su te funkcije postale dostupne. Kada je takav kod bio pozvan, to je dovelo do vraćanja internih pogrešaka. To se manifestiralo u neuspješnim API pozivima i „pokvarenim“ web stranicama.
Tim koji se bavio ovim problemom riješio ga je uvođenjem pojmova „vruće“ (hot) i „hladne“ (cold) direktorije. Kod u „vrućoj“ direktoriji odgovara za obradu proizvodnog prometa. A u „hladnim“ direktorijima kod se, tijekom rada sustava, samo priprema za korištenje. Tijekom implementacije novi kod kopira se u neiskorištenu „hladnu“ direktoriju. Zatim, kada na poslužitelju ne bude aktivnih procesa, izvršava se trenutni prelazak direktorija.
1. Raspakiranje aplikacijskog koda u „hladnu“ direktoriju. 2. Prebacivanje sustava na „hladnu“ direktoriju, koja postaje „vruća“ (atomarna operacija).
Zaključci: pomak fokusa na pouzdanost.
U 2018. godini projekt je dosegao razmjere kada je vrlo brzo razmještanje počelo štetiti stabilnosti proizvoda. Imali smo prilično napredan sustav razmještanja, u koji smo uložili mnogo truda i vremena. Trebalo je samo prestrukturirati i unaprijediti procese organizacije razmještanja. Postali smo dovoljno velika tvrtka čiji se razvoj koristi širom svijeta za održavanje neprekidne komunikacije i rješavanje važnih zadataka. Stoga je pouzdanost postala središnja tačka našeg interesa.
Trebao nam je sigurniji proces razmještanja novih izdanja Slacka. Ova potreba dovela nas je do unaprjeđenja našeg sustava razmještanja. Uostalom, o tom smo unapređenom sustavu ranije razgovarali. Unutarnjim dijelovima sustava i dalje koristimo tehnologije brzog i atomskog razmještanja. Promijenilo se samo to kako se točno izvršava razmještanje. Naš novi sustav namijenjen je postupnom izvršavanju razmještanja novog koda na različitim razinama, u različitim okruženjima. Sada koristimo naprednije pomoćne alate i sredstva za praćenje sustava nego prije. To nam omogućava da uhvatimo i ispravimo greške mnogo prije nego što dobiju priliku doći do krajnjeg korisnika.
Ali ne planiramo stati na postignutom. Stalno unapređujemo ovaj sustav primjenom naprednijih pomoćnih alata i sredstava za automatizaciju rada.
Dragi čitatelji! Kako izgleda proces razmještanja novih izdanja projekata gdje vi radite?
Izvor: habr.com
