Dovođenje novog izdanja projekta u proizvodnju zahtijeva pažljiv balans između brzine implementacije i pouzdanosti rješenja. Slack cijeni brze iteracije, kratke cikluse povratnih informacija i brz odgovor na zahtjeve korisnika. Osim toga, kompanija ima stotine programera koji nastoje biti što produktivniji.
Autori materijala, čiji prevod danas objavljujemo, kažu da kompanija koja nastoji da se pridržava ovakvih vrednosti i istovremeno raste mora stalno da unapređuje svoj sistem implementacije projekata. Kompanija treba ulagati u transparentnost i pouzdanost radnih procesa, čineći to kako bi se osiguralo da ti procesi odgovaraju obimu projekta. Ovdje ćemo govoriti o tokovima rada koji su se razvili u Slacku, te o nekim odlukama koje su dovele kompaniju da koristi sistem implementacije projekata koji danas postoji.
Kako danas funkcioniraju procesi implementacije projekta
Svaki PR (pull zahtjev) u Slacku mora biti podvrgnut pregledu koda i mora uspješno proći sve testove. Tek nakon što su ovi uslovi ispunjeni, programer može spojiti svoj kod u glavnu granu projekta. Međutim, ovaj kod se primjenjuje samo tokom radnog vremena po sjevernoameričkom vremenu. Kao rezultat toga, zbog činjenice da su naši zaposleni na svojim radnim mjestima, u potpunosti smo spremni za rješavanje svih neočekivanih problema.
Svakog dana izvršimo oko 12 planiranih raspoređivanja. Tokom svake implementacije, programer određen kao vodeći za implementaciju odgovoran je za stavljanje nove verzije u proizvodnju. Ovo je proces u više koraka koji osigurava da se sklop neometano dovede u proizvodnju. Zahvaljujući ovom pristupu, možemo otkriti greške prije nego što utiču na sve naše korisnike. Ako ima previše grešaka, implementacija sklopa se može vratiti. Ako se nakon izdavanja otkrije određeni problem, lako se može izdati popravak za njega.
Interfejs sistema Checkpoint, koji se koristi u Slacku za implementaciju projekata
Proces implementacije novog izdanja u proizvodnju može se smatrati da se sastoji od četiri koraka.
▍1. Kreiranje grane izdanja
Svako izdanje počinje novom granom izdanja, točkom u našoj Git historiji. Ovo vam omogućava da dodijelite oznake izdanju i pruža mjesto gdje možete napraviti ispravke uživo za greške pronađene u procesu pripreme izdanja za puštanje u produkciju.
▍2. Primjena u scenskom okruženju
Sljedeći korak je postavljanje sklopa na servere za postavljanje i pokretanje automatskog testa za ukupnu izvedbu projekta (test dima). Stage okruženje je proizvodno okruženje koje ne prima vanjski promet. U ovom okruženju vršimo dodatno ručno testiranje. To nam daje dodatno povjerenje da modificirani projekt radi ispravno. Automatski testovi sami po sebi nisu dovoljni da obezbede ovaj nivo samopouzdanja.
▍3. Primena u psećoj i kanarinskoj sredini
Implementacija u produkciju počinje sa internim okruženjem, predstavljenim skupom hostova koji služe našim internim Slack radnim prostorima. Pošto smo veoma aktivni Slack korisnici, ovaj pristup nam je pomogao da uhvatimo mnogo grešaka u ranoj fazi implementacije. Nakon što smo se uvjerili da osnovna funkcionalnost sistema nije pokvarena, sklop se postavlja u canary okruženje. Predstavlja sisteme koji čine oko 2% proizvodnog prometa.
▍4. Postepeno puštanje u proizvodnju
Ako se indikatori praćenja za novo izdanje pokažu stabilnima, i ako nakon implementacije projekta u canary okruženju nismo primili nijednu pritužbu, nastavljamo postupno prenositi produkcijske servere na novo izdanje. Proces implementacije je podijeljen u sljedeće faze: 10%, 25%, 50%, 75% i 100%. Kao rezultat toga, možemo polako prebaciti proizvodni promet na novo izdanje sistema. Istovremeno, imamo vremena da istražimo situaciju ukoliko se otkriju bilo kakve anomalije.
▍Šta ako nešto pođe po zlu tokom implementacije?
Pravljenje modifikacija koda je uvijek rizik. Ali s tim se nosimo zahvaljujući prisutnosti dobro obučenih „vođa implementacije“ koji upravljaju procesom dovođenja novog izdanja u proizvodnju, prate indikatore praćenja i koordiniraju rad programera koji objavljuju kod.
U slučaju da nešto zaista krene po zlu, trudimo se da otkrijemo problem što je prije moguće. Istražujemo problem, pronalazimo PR koji uzrokuje greške, vraćamo ga nazad, analiziramo ga temeljito i kreiramo novu verziju. Istina, ponekad problem ostaje neprimijećen dok projekt ne krene u proizvodnju. U takvoj situaciji najvažnije je vratiti uslugu. Stoga, prije nego što počnemo da istražujemo problem, odmah se vraćamo na prethodnu radnu verziju.
Građevinski blokovi sistema za implementaciju
Pogledajmo tehnologije koje su u osnovi našeg sistema implementacije projekta.
▍Brza implementacija
Gore opisani tok posla može izgledati, retrospektivno, pomalo očigledan. Ali naš sistem raspoređivanja nije odmah postao takav.
Kada je kompanija bila mnogo manja, cijela naša aplikacija mogla je raditi na 10 Amazon EC2 instanci. Postavljanje projekta u ovoj situaciji značilo je korištenje rsync za brzu sinhronizaciju svih servera. Ranije je novi kod bio samo jedan korak od proizvodnje, a predstavljao ga je okruženje za postavljanje. Sklopovi su kreirani i testirani u takvom okruženju, a zatim su išli direktno u proizvodnju. Bilo je vrlo lako razumjeti takav sistem; omogućavao je svakom programeru da implementira kod koji je napisao u bilo koje vrijeme.
Ali kako je rastao broj naših klijenata, tako je rastao i obim infrastrukture potrebne za podršku projektu. Ubrzo, s obzirom na konstantan rast sistema, naš model implementacije, zasnovan na guranju novog koda na servere, više nije radio svoj posao. Naime, dodavanje svakog novog servera značilo je povećanje vremena potrebnog za završetak implementacije. Čak i strategije zasnovane na paralelnoj upotrebi rsync-a imaju određena ograničenja.
Ovaj problem smo na kraju riješili prelaskom na potpuno paralelni sistem implementacije, koji je dizajniran drugačije od starog sistema. Naime, sada nismo slali kod na servere koristeći skriptu za sinhronizaciju. Sada je svaki server samostalno preuzeo novi sklop, znajući da to treba učiniti praćenjem promjene ključa Consul. Serveri su učitavali kod paralelno. To nam je omogućilo da zadržimo veliku brzinu implementacije čak iu okruženju konstantnog rasta sistema.
1. Produkcijski serveri nadgledaju Consul ključ. 2. Ključ se mijenja, to govori serverima da moraju početi preuzimati novi kod. 3. Serveri preuzimaju tarball datoteke sa kodom aplikacije
▍Atomske implementacije
Još jedno rješenje koje nam je pomoglo da dođemo do višeslojnog sistema implementacije bila je atomska implementacija.
Prije korištenja atomskih implementacija, svaka implementacija mogla bi rezultirati velikim brojem poruka o grešci. Činjenica je da proces kopiranja novih datoteka na proizvodne servere nije bio atomski. Ovo je rezultiralo kratkim vremenskim periodom u kojem je kod koji je pozivao nove funkcije bio dostupan prije nego što su same funkcije postale dostupne. Kada je takav kod pozvan, to je rezultiralo vraćanjem internih grešaka. To se manifestiralo u neuspjelim API zahtjevima i pokvarenim web stranicama.
Tim koji je radio na ovom problemu ga je riješio uvođenjem koncepta “vrućih” i “hladnih” direktorija. Kod u vrućem direktoriju je odgovoran za obradu proizvodnog prometa. A u “hladnim” direktorijima, kod se, dok sistem radi, samo priprema za upotrebu. Tokom implementacije, novi kod se kopira u nekorišteni hladni direktorij. Zatim, kada nema aktivnih procesa na serveru, vrši se trenutna promena direktorijuma.
1. Raspakivanje koda aplikacije u “hladni” direktorij. 2. Prebacivanje sistema na "hladni" direktorij, koji postaje "vruć" (atomski rad)
Rezultati: prebacivanje naglaska na pouzdanost
U 2018. godini projekt je porastao do takvih razmjera da je vrlo brzo uvođenje počelo štetiti stabilnosti proizvoda. Imali smo veoma napredan sistem raspoređivanja u koji smo uložili mnogo vremena i truda. Sve što je trebalo da uradimo je da obnovimo i poboljšamo naše procese raspoređivanja. Izrasli smo u prilično veliku kompaniju, čiji razvoj se koristi širom svijeta za organizaciju nesmetane komunikacije i rješavanje važnih problema. Stoga je pouzdanost postala fokus naše pažnje.
Trebali smo proces implementacije novih Slack izdanja učiniti sigurnijim. Ova potreba nas je dovela do poboljšanja našeg sistema raspoređivanja. Zapravo, gore smo razgovarali o ovom poboljšanom sistemu. U dubinama sistema, nastavljamo da koristimo tehnologije brze i atomske implementacije. Način na koji se vrši implementacija je promijenjen. Naš novi sistem je dizajniran da postepeno implementira novi kod na različitim nivoima, u različitim okruženjima. Sada koristimo naprednije alate za podršku i alate za praćenje sistema nego ranije. Ovo nam daje mogućnost da uhvatimo i popravimo greške mnogo prije nego što imaju priliku doći do krajnjeg korisnika.
Ali nećemo stati na tome. Ovaj sistem stalno unapređujemo, koristeći naprednije pomoćne alate i alate za automatizaciju rada.
Dragi čitaoci! Kako proces implementacije novih projektnih izdanja funkcionira tamo gdje radite?
izvor: www.habr.com