Uvedba izdaje novega projekta v produkcijo zahteva skrbno ravnotežje med hitrostjo uvajanja in zanesljivostjo rešitve. Slack ceni hitre iteracije, kratke cikle povratnih informacij in hiter odziv na zahteve uporabnikov. Poleg tega ima podjetje na stotine programerjev, ki si prizadevajo biti čim bolj produktivni.
Avtorji gradiva, katerega prevod objavljamo danes, pravijo, da mora podjetje, ki si prizadeva slediti takim vrednotam in hkrati rasti, nenehno izboljševati svoj sistem za uvajanje projektov. Podjetje mora vlagati v transparentnost in zanesljivost delovnih procesov, s tem pa zagotoviti, da ti procesi ustrezajo obsegu projekta. Tukaj bomo govorili o delovnih tokovih, ki so se razvili v Slacku, in o nekaterih odločitvah, zaradi katerih je podjetje uporabilo sistem za uvajanje projektov, ki obstaja danes.
Kako danes potekajo procesi uvajanja projektov
Vsak PR (pull request) v Slacku mora biti predmet pregleda kode in mora uspešno prestati vse teste. Šele ko so ti pogoji izpolnjeni, lahko programer združi svojo kodo v glavno vejo projekta. Vendar je ta koda uvedena samo med delovnim časom po severnoameriškem času. Posledično smo zaradi dejstva, da so naši zaposleni na svojih delovnih mestih, popolnoma pripravljeni rešiti morebitne nepričakovane težave.
Vsak dan izvedemo približno 12 načrtovanih razporeditev. Med vsakim uvajanjem je programer, ki je določen kot vodja uvajanja, odgovoren za pripravo nove gradnje v proizvodnjo. To je večstopenjski postopek, ki zagotavlja, da se sestav nemoteno prenese v proizvodnjo. Zahvaljujoč temu pristopu lahko odkrijemo napake, preden prizadenejo vse naše uporabnike. Če je napak preveč, je mogoče razmestitev sklopa povrniti nazaj. Če se po izdaji odkrije določena težava, se zanjo zlahka izda popravek.
Vmesnik sistema Checkpoint, ki se uporablja v Slacku za uvajanje projektov
Postopek uvajanja nove izdaje v produkcijo lahko predstavljamo kot sestavljen iz štirih korakov.
▍1. Ustvarjanje izdajne veje
Vsaka izdaja se začne z novo vejo izdaje, točko v naši zgodovini Git. To vam omogoča, da izdaji dodelite oznake in nudi mesto, kjer lahko v živo izvajate popravke za hrošče, odkrite v procesu priprave izdaje za izdajo v proizvodnji.
▍2. Namestitev v uprizoritvenem okolju
Naslednji korak je razmestitev sklopa na uprizoritvenih strežnikih in zagon samodejnega preizkusa splošne zmogljivosti projekta (dimni test). Uprizoritveno okolje je produkcijsko okolje, ki ne prejema zunanjega prometa. V tem okolju izvajamo dodatno ročno testiranje. To nam daje dodatno zaupanje, da spremenjeni projekt deluje pravilno. Samo avtomatizirani testi niso dovolj za zagotavljanje te stopnje zaupanja.
▍3. Uvedba v okoljih interne uporabe in kanarčkov
Uvajanje v produkcijo se začne z okoljem za interno uporabo, ki ga predstavlja nabor gostiteljev, ki služijo našim notranjim delovnim prostorom Slack. Ker smo zelo aktivni uporabniki Slacka, nam je ta pristop pomagal odkriti veliko napak na začetku uvajanja. Ko smo se prepričali, da osnovna funkcionalnost sistema ni porušena, se sestav razmesti v kanarsko okolje. Predstavlja sisteme, ki predstavljajo približno 2 % proizvodnega prometa.
▍4. Postopna sprostitev v proizvodnjo
Če se indikatorji spremljanja za novo izdajo izkažejo za stabilne in če po uvedbi projekta v kanarsko okolje nismo prejeli nobenih pritožb, nadaljujemo s postopnim prenosom produkcijskih strežnikov v novo izdajo. Postopek uvajanja je razdeljen na naslednje stopnje: 10 %, 25 %, 50 %, 75 % in 100 %. Posledično lahko počasi prenesemo produkcijski promet v novo izdajo sistema. Hkrati imamo čas, da raziščemo situacijo, če se odkrijejo kakršne koli nepravilnosti.
▍Kaj če gre kaj narobe med uvajanjem?
Spreminjanje kode je vedno tveganje. Toda s tem se spopadamo zahvaljujoč prisotnosti dobro usposobljenih »vodij uvajanja«, ki upravljajo proces uvajanja nove izdaje v proizvodnjo, spremljajo indikatorje spremljanja in usklajujejo delo programerjev, ki izdajajo kodo.
V primeru, da gre res kaj narobe, poskušamo težavo odkriti čim prej. Težavo raziščemo, poiščemo PR, ki povzroča napake, jo vrnemo nazaj, temeljito analiziramo in ustvarimo novo gradnjo. Res je, včasih je težava neopažena, dokler projekt ne gre v proizvodnjo. V takšni situaciji je najpomembneje obnoviti storitev. Zato se, preden začnemo raziskovati težavo, takoj vrnemo na prejšnjo delovno zgradbo.
Gradniki sistema za uvajanje
Oglejmo si tehnologije, ki so osnova našega sistema za uvajanje projektov.
▍Hitre uvedbe
Zgoraj opisan potek dela se morda zdi, retrospektivno, nekoliko očiten. Toda naš sistem uvajanja ni takoj postal tak.
Ko je bilo podjetje veliko manjše, je lahko naša celotna aplikacija delovala na 10 primerkih Amazon EC2. Uvedba projekta v tej situaciji je pomenila uporabo rsync za hitro sinhronizacijo vseh strežnikov. Prej je bila nova koda le en korak stran od proizvodnje, ki jo je predstavljalo uprizoritveno okolje. V takem okolju so nastajali in testirali sklope, ki so šli takoj v proizvodnjo. Takšen sistem je bilo zelo enostavno razumeti; vsakemu programerju je omogočal, da kadar koli uporabi kodo, ki jo je napisal.
Toda z naraščanjem števila naših strank se je večal tudi obseg infrastrukture, potrebne za podporo projekta. Kmalu, glede na stalno rast sistema, naš model uvajanja, ki je temeljil na potiskanju nove kode na strežnike, ni več opravljal svojega dela. Dodajanje vsakega novega strežnika je namreč pomenilo podaljševanje časa, potrebnega za dokončanje uvedbe. Tudi strategije, ki temeljijo na vzporedni uporabi rsync, imajo določene omejitve.
To težavo smo na koncu rešili s prehodom na popolnoma vzporedni sistem uvajanja, ki je bil zasnovan drugače od starega sistema. Sedaj namreč na strežnike nismo pošiljali kode s sinhronizacijskim skriptom. Zdaj je vsak strežnik neodvisno prenesel nov sklop, saj je vedel, da mora to storiti s spremljanjem spremembe ključa Consul. Strežniki so kodo nalagali vzporedno. To nam je omogočilo ohraniti visoko hitrost uvajanja tudi v okolju nenehne rasti sistema.
1. Produkcijski strežniki nadzorujejo ključ Consul. 2. Ključne spremembe, to pove strežnikom, da morajo začeti prenašati novo kodo. 3. Strežniki prenesejo datoteke tarball s kodo aplikacije
▍Atomske uvedbe
Druga rešitev, ki nam je pomagala doseči večnivojski sistem uvajanja, je bila atomska uvedba.
Pred uporabo atomskih uvajanj lahko vsaka uvedba povzroči veliko število sporočil o napakah. Dejstvo je, da postopek kopiranja novih datotek na produkcijske strežnike ni bil atomičen. Posledica tega je bilo kratko časovno okno, ko je bila koda, ki je klicala nove funkcije, na voljo, preden so bile na voljo same funkcije. Ko je bila taka koda poklicana, so bile vrnjene notranje napake. To se je pokazalo v neuspelih zahtevah API-ja in pokvarjenih spletnih straneh.
Ekipa, ki se je ukvarjala s tem problemom, ga je rešila z uvedbo koncepta »vročih« in »hladnih« imenikov. Koda v vročem imeniku je odgovorna za obdelavo produkcijskega prometa. In v "hladnih" imenikih se koda, medtem ko sistem deluje, samo pripravlja za uporabo. Med uvajanjem se nova koda prekopira v neuporabljen hladni imenik. Potem, ko na strežniku ni aktivnih procesov, se izvede takojšen preklop imenika.
1. Razpakiranje kode aplikacije v "hladen" imenik. 2. Preklop sistema na "hladen" imenik, ki postane "vroč" (atomsko delovanje)
Rezultati: premik poudarka na zanesljivost
Leta 2018 je projekt tako zrasel, da je zelo hitro uvajanje začelo škodovati stabilnosti izdelka. Imeli smo zelo napreden sistem uvajanja, v katerega smo vložili veliko časa in truda. Vse, kar smo morali storiti, je bilo obnoviti in izboljšati naše postopke uvajanja. Zrasli smo v dokaj veliko podjetje, katerega razvoj je bil uporabljen po vsem svetu za organizacijo neprekinjenih komunikacij in reševanje pomembnih problemov. Zato je bila zanesljivost v središču naše pozornosti.
Postopek uvajanja novih izdaj Slack smo morali narediti bolj varen. Ta potreba nas je vodila k izboljšanju našega sistema uvajanja. Pravzaprav smo o tem izboljšanem sistemu razpravljali zgoraj. V globinah sistema še naprej uporabljamo tehnologije hitrega in atomskega uvajanja. Spremenil se je način uvajanja. Naš novi sistem je zasnovan za postopno uvajanje nove kode na različnih ravneh in v različnih okoljih. Zdaj uporabljamo naprednejša podporna orodja in orodja za nadzor sistema kot prej. To nam daje možnost, da ujamemo in popravimo napake veliko preden pridejo do končnega uporabnika.
Vendar se ne bomo ustavili pri tem. Ta sistem nenehno izboljšujemo z uporabo naprednejših pomožnih orodij in orodij za avtomatizacijo dela.
Drage bralke in bralci! Kako poteka postopek uvajanja novih izdaj projekta tam, kjer delate?
Vir: www.habr.com