Uvođenje novog izdanja projekta u proizvodnju zahtijeva pažljivu ravnotežu između brzine postavljanja i pouzdanosti rješenja. Slack cijeni brze iteracije, kratke cikluse povratnih informacija i brz odgovor na zahtjeve korisnika. Osim toga, tvrtka ima stotine programera koji se trude biti što produktivniji.
Autori materijala, čiji prijevod danas objavljujemo, kažu da tvrtka koja se nastoji pridržavati takvih vrijednosti i istovremeno raste mora stalno poboljšavati svoj sustav implementacije projekata. Tvrtka treba ulagati u transparentnost i pouzdanost radnih procesa, čineći to kako bi osigurala da ti procesi odgovaraju razmjeru projekta. Ovdje ćemo govoriti o tijekovima rada koji su se razvili u Slacku i o nekim odlukama koje su navele tvrtku da koristi sustav implementacije projekta koji danas postoji.
Kako danas funkcioniraju procesi implementacije projekta
Svaki PR (pull request) u Slacku mora biti podvrgnut pregledu koda i mora uspješno proći sve testove. Tek nakon što su ti uvjeti ispunjeni, programer može spojiti svoj kod u glavnu granu projekta. Međutim, ovaj se kôd primjenjuje samo tijekom radnog vremena, po sjevernoameričkom vremenu. Kao rezultat toga, budući da su naši zaposlenici na svojim radnim mjestima, u potpunosti smo spremni riješiti sve neočekivane probleme.
Svaki dan provodimo oko 12 planiranih raspoređivanja. Tijekom svake implementacije, programer koji je određen kao voditelj implementacije odgovoran je za puštanje nove verzije u proizvodnju. Ovo je proces u više koraka koji osigurava glatko puštanje sklopa u proizvodnju. Zahvaljujući ovom pristupu, možemo otkriti pogreške prije nego što utječu na sve naše korisnike. Ako postoji previše pogrešaka, implementacija sklopa može se vratiti unatrag. Ako se nakon izdavanja otkrije određeni problem, za njega se lako može izdati popravak.
Sučelje sustava Checkpoint, koji se koristi u Slacku za implementaciju projekata
Proces implementacije novog izdanja u proizvodnju može se zamisliti kao da se sastoji od četiri koraka.
▍1. Stvaranje grane izdanja
Svako izdanje počinje s novom granom izdanja, točkom u našoj Git povijesti. To vam omogućuje dodjeljivanje oznaka izdanju i pruža mjesto na kojem možete uživo ispravljati greške pronađene u procesu pripreme izdanja za puštanje u proizvodnju.
▍2. Implementacija u prizornom okruženju
Sljedeći korak je implementacija sklopa na probne poslužitelje i pokretanje automatskog testa ukupne izvedbe projekta (dimni test). Pripremno okruženje je proizvodno okruženje koje ne prima vanjski promet. U ovom okruženju provodimo dodatno ručno testiranje. To nam daje dodatnu sigurnost da modificirani projekt radi ispravno. Sami automatizirani testovi nisu dovoljni za pružanje ove razine povjerenja.
▍3. Implementacija u internoj verziji i okruženjima Canary
Implementacija u produkciju počinje s internom okolinom za probnu upotrebu, predstavljenom skupom hostova koji opslužuju naše interne Slack radne prostore. Budući da smo vrlo aktivni korisnici Slacka, korištenje ovog pristupa pomoglo nam je da uhvatimo mnogo grešaka u ranoj fazi implementacije. Nakon što smo se uvjerili da osnovna funkcionalnost sustava nije pokvarena, sklop se postavlja u okruženje canary. Predstavlja sustave koji čine približno 2% proizvodnog prometa.
▍4. Postupno puštanje u proizvodnju
Ako se pokazatelji praćenja za novo izdanje pokažu stabilnima i ako nakon implementacije projekta u kanarskom okruženju nismo primili nikakve pritužbe, nastavljamo s postupnim prijenosom proizvodnih poslužitelja na novo izdanje. Proces postavljanja podijeljen je u sljedeće faze: 10%, 25%, 50%, 75% i 100%. Kao rezultat toga, možemo polako prenijeti proizvodni promet na novo izdanje sustava. U isto vrijeme, imamo vremena istražiti situaciju ako se otkriju bilo kakve anomalije.
▍Što ako nešto pođe po zlu tijekom implementacije?
Izrada izmjena koda uvijek je rizik. Ali nosimo se s tim zahvaljujući prisutnosti dobro obučenih "vođa implementacije" koji upravljaju procesom uvođenja novog izdanja u proizvodnju, prate indikatore praćenja i koordiniraju rad programera koji objavljuju kod.
U slučaju da nešto stvarno pođe po zlu, nastojimo što prije otkriti problem. Istražujemo problem, pronalazimo PR koji uzrokuje pogreške, vraćamo ga unatrag, temeljito ga analiziramo i stvaramo novu verziju. Istina, ponekad problem ostane nezapažen sve dok projekt ne krene u proizvodnju. U takvoj situaciji najvažnije je vratiti uslugu. Stoga, prije nego počnemo istraživati problem, odmah se vraćamo na prethodnu radnu verziju.
Sastavni dijelovi sustava za implementaciju
Pogledajmo tehnologije koje su u osnovi našeg sustava implementacije projekta.
▍Brze implementacije
Gore opisan tijek rada može se, retrospektivno, činiti pomalo očiglednim. Ali naš sustav implementacije nije odmah postao takav.
Kad je tvrtka bila puno manja, cijela naša aplikacija mogla se pokrenuti na 10 instanci Amazon EC2. Implementacija projekta u ovoj situaciji značila je korištenje rsync za brzu sinkronizaciju svih poslužitelja. Prethodno je novi kôd bio samo jedan korak od proizvodnje, predstavljen scenskim okruženjem. Sklopovi su kreirani i testirani u takvom okruženju, a zatim su išli ravno u proizvodnju. Bilo je vrlo lako razumjeti takav sustav; omogućavao je svakom programeru da u bilo kojem trenutku primijeni kod koji je napisao.
Ali kako je rastao broj naših klijenata, tako je rastao i opseg infrastrukture potrebne za podršku projektu. Ubrzo, s obzirom na stalni rast sustava, naš model implementacije, temeljen na guranju novog koda na poslužitelje, više nije radio svoj posao. Naime, dodavanje svakog novog poslužitelja značilo je povećanje vremena potrebnog za dovršetak implementacije. Čak i strategije temeljene na paralelnoj upotrebi rsync-a imaju određena ograničenja.
Na kraju smo riješili ovaj problem prelaskom na potpuno paralelni sustav implementacije, koji je dizajniran drugačije od starog sustava. Naime, sada nismo slali kod na servere pomoću skripte za sinkronizaciju. Sada je svaki poslužitelj samostalno preuzeo novi sklop, znajući da to treba učiniti praćenjem promjene ključa Consul. Poslužitelji su paralelno učitavali kod. To nam je omogućilo da održimo veliku brzinu implementacije čak iu okruženju stalnog rasta sustava.
1. Proizvodni poslužitelji nadziru Consul ključ. 2. Ključne promjene, ovo govori poslužiteljima da trebaju početi preuzimati novi kod. 3. Poslužitelji preuzimaju tarball datoteke s kodom aplikacije
▍Atomske implementacije
Još jedno rješenje koje nam je pomoglo da postignemo višeslojni sustav implementacije bila je atomska implementacija.
Prije korištenja atomskih implementacija, svaka implementacija može dovesti do velikog broja poruka o pogrešci. Činjenica je da proces kopiranja novih datoteka na proizvodne poslužitelje nije bio atomski. To je rezultiralo kratkim vremenskim okvirom u kojem je kod koji je pozivao nove funkcije bio dostupan prije nego što su same funkcije postale dostupne. Kada je takav kod pozvan, rezultirao je vraćanjem internih pogrešaka. To se očitovalo neuspjelim API zahtjevima i pokvarenim web stranicama.
Tim koji je radio na ovom problemu riješio ga je uvođenjem koncepta “vrućih” i “hladnih” imenika. Kod u vrućem direktoriju odgovoran je za obradu proizvodnog prometa. A u "hladnim" imenicima kod se, dok sustav radi, samo priprema za upotrebu. Tijekom implementacije, novi kod se kopira u nekorišteni hladni direktorij. Zatim, kada na poslužitelju nema aktivnih procesa, izvršava se trenutna promjena imenika.
1. Raspakiranje koda aplikacije u "hladni" direktorij. 2. Prebacivanje sustava na "hladni" direktorij, koji postaje "vrući" (atomski rad)
Rezultati: pomak naglaska na pouzdanost
Godine 2018. projekt je narastao do takvih razmjera da je vrlo brza implementacija počela štetiti stabilnosti proizvoda. Imali smo vrlo napredan sustav implementacije u koji smo uložili puno vremena i truda. Sve što smo trebali učiniti bilo je ponovno izgraditi i poboljšati naše procese implementacije. Izrasli smo u prilično veliku tvrtku, čiji se razvoj koristi u cijelom svijetu za organiziranje nesmetane komunikacije i rješavanje važnih problema. Stoga je pouzdanost postala fokus naše pažnje.
Morali smo učiniti proces implementacije novih Slack izdanja sigurnijim. Ta nas je potreba dovela do poboljšanja našeg sustava implementacije. Zapravo, gore smo raspravljali o ovom poboljšanom sustavu. U dubini sustava nastavljamo koristiti tehnologije brze i atomske implementacije. Promijenio se način implementacije. Naš novi sustav dizajniran je za postupnu implementaciju novog koda na različitim razinama, u različitim okruženjima. Sada koristimo naprednije alate za podršku i alate za nadzor sustava nego prije. To nam daje mogućnost da uhvatimo i popravimo pogreške mnogo prije nego što imaju priliku doći do krajnjeg korisnika.
Ali nećemo tu stati. Ovaj sustav stalno unapređujemo, koristeći naprednije pomoćne alate i alate za automatizaciju rada.
Dragi čitatelji! Kako proces implementacije novih izdanja projekta funkcionira tamo gdje radite?
Izvor: www.habr.com