Proiektuaren bertsio berri bat produkziora ekartzeak inplementazio-abiaduraren eta irtenbideen fidagarritasunaren arteko oreka zaindua behar du. Slack-ek iterazio azkarrak, iritzi-ziklo laburrak eta erabiltzaileen eskaerei erantzun azkarra ematen die. Horrez gain, konpainiak ehunka programatzaile ditu, ahalik eta produktiboena izaten ahalegintzen direnak.
Materialaren egileek, zeinaren itzulpena gaur argitaratzen ari garen, esaten dute balio horiek betetzen ahalegintzen den eta, aldi berean, hazten den enpresa batek etengabe hobetu behar duela bere proiektuak zabaltzeko sistema. Enpresak lan-prozesuen gardentasunean eta fidagarritasunean inbertitu behar du, prozesu horiek proiektuaren eskalarekin bat datozela ziurtatzeko. Hemen Slack-en garatu diren lan-fluxuei buruz hitz egingo dugu, eta enpresa gaur egun dagoen proiektuak zabaltzeko sistema erabiltzera eraman duten erabaki batzuei buruz.
Nola funtzionatzen duten gaur egun proiektuak zabaltzeko prozesuek
Slack-en PR bakoitza (pull request) kodea berrikusi behar da eta proba guztiak behar bezala gainditu behar ditu. Baldintza hauek bete ondoren bakarrik programatzaileak bere kodea batu dezake proiektuaren adar nagusiarekin. Hala ere, kode hau lanorduetan soilik zabaltzen da, Ipar Amerikako orduan. Ondorioz, gure langileak lantokietan daudelako, ustekabeko arazoak konpontzeko guztiz prest gaude.
Egunero aurreikusitako 12 inplementazio inguru egiten ditugu. Inplementazio bakoitzean, hedapen-buru gisa izendatutako programatzailea arduratzen da eraikuntza berria produkzioan sartzeaz. Hau urrats anitzeko prozesu bat da, muntaia leunki produkzioan sartzea ziurtatzen duena. Ikuspegi honi esker, akatsak hauteman ditzakegu gure erabiltzaile guztiei eragin aurretik. Akats gehiegi badira, muntaiaren hedapena atzera egin daiteke. Askatu ondoren arazo zehatz bat aurkitzen bada, konponketa bat erraz askatu daiteke.
Slack-en proiektuak zabaltzeko erabiltzen den Checkpoint sistemaren interfazea
Bertsio berri bat ekoizpenera hedatzeko prozesua lau urratsez osatuta dagoela pentsa daiteke.
β1. Askapen adar bat sortzea
Argitalpen bakoitza bertsio-adar berri batekin hasten da, gure Git historiako puntu batekin. Horri esker, bertsioari etiketak esleitzeko aukera ematen dizu eta oharra prestatzeko prozesuan aurkitutako akatsen zuzeneko konponketa egiteko lekua eskaintzen du.
β2. Inplementazioa eszenatze-ingurunean
Hurrengo urratsa muntaia eszenatze zerbitzarietan zabaltzea eta proiektuaren errendimendu orokorraren proba automatiko bat egitea da (ke proba). Eszenaratzeko ingurunea kanpoko trafikoa jasotzen ez duen ekoizpen ingurunea da. Ingurune honetan, eskuzko proba osagarriak egiten ditugu. Horrek ziurtasun gehiago ematen digu aldatutako proiektuak behar bezala funtzionatzen duela. Proba automatizatuak bakarrik ez dira nahikoa konfiantza maila hori emateko.
β3. Inplementazioa dogfood eta kanariar inguruneetan
Produkziorako inplementazioa proba-ingurune batekin hasten da, gure Slack-eko barneko lan-eremuak zerbitzatzen dituzten ostalari multzo batek adierazten duena. Slack-eko erabiltzaile oso aktiboak garenez, ikuspegi hau hartzeak akats asko harrapatzen lagundu zigun hedapenaren hasieran. Sistemaren oinarrizko funtzionaltasuna apurtzen ez dela ziurtatu ondoren, muntaia kanariar ingurunean zabaltzen da. Produkzioaren trafikoaren %2 inguru hartzen duten sistemak adierazten ditu.
β4. Pixkanaka ekoizpenera kaleratzea
Argitalpen berriaren jarraipen-adierazleak egonkorrak suertatzen badira, eta proiektua kanariar ingurunean zabaldu ondoren kexarik jaso ez badugu, ekoizpen-zerbitzariak bertsio berrira pixkanaka transferitzen jarraituko dugu. Hedapen-prozesua fase hauetan banatzen da: % 10, % 25, ββ% 50, % 75 eta % 100. Ondorioz, poliki-poliki ekoizpen-trafikoa sistemaren bertsio berrira transferi dezakegu. Aldi berean, egoera ikertzeko denbora dugu anomaliarik hautematen bada.
βZer gertatzen da inplementazioan zerbait gaizki ateratzen bada?
Kodean aldaketak egitea arriskua da beti. Baina horri aurre egiten diogu ondo prestatutako "inplementazio-buruen" presentziari esker, bertsio berri bat produkziora ekartzeko prozesua kudeatzen dutenak, jarraipen-adierazleak kontrolatzen dituztenak eta kodea askatzen duten programatzaileen lana koordinatzen dutenak.
Benetan zerbait gaizki joango balitz, arazoa ahalik eta lasterren detektatzen saiatzen gara. Arazoa ikertzen dugu, akatsak eragiten dituen PR-a aurkitzen dugu, atzera bota, ondo aztertzen dugu eta eraikuntza berri bat sortzen dugu. Egia da, batzuetan arazoa oharkabean pasatzen da proiektua produkzioan sartzen den arte. Egoera horretan, garrantzitsuena zerbitzua berreskuratzea da. Hori dela eta, arazoa ikertzen hasi baino lehen, berehala itzuliko gara aurreko laneko eraikuntzara.
Hedapen-sistema baten eraikuntza-blokeak
Ikus ditzagun gure proiektuak hedatzeko sistemaren oinarrian dauden teknologiak.
βInplementazio azkarrak
Goian deskribatutako lan-fluxua, atzera begira, agerikoa dirudi. Baina gure hedapen sistema ez zen horrela bihurtu berehala.
Konpainia askoz txikiagoa zenean, gure aplikazio osoa Amazon EC10 2 instantziatan exekutatu zitekeen. Proiektua egoera honetan zabaltzeak rsync erabiltzea zerbitzari guztiak azkar sinkronizatzeko esan nahi zuen. Aurretik, kode berria produkziotik urrats bakarrera zegoen, eszenatze ingurune batek irudikatuta. Asanbladak halako ingurune batean sortu eta probatu ziren, eta gero zuzenean produkziora pasa ziren. Oso erraza zen horrelako sistema bat ulertzea; edozein programatzaileri edozein unetan idatzitako kodea zabaltzeko aukera ematen zion.
Baina gure bezeroen kopurua hazi ahala, proiektuari laguntzeko beharrezkoa den azpiegituraren tamaina ere handitu zen. Laster, sistemaren etengabeko hazkundea ikusita, gure inplementazio ereduak, zerbitzarietara kode berria bultzatzean oinarrituta, ez zuen bere lana egiten. Hots, zerbitzari berri bakoitza gehitzeak inplementazioa burutzeko behar den denbora handitzea ekarri zuen. Rsync-en erabilera paraleloan oinarritutako estrategiek ere muga batzuk dituzte.
Arazo hau konpontzen amaitu genuen inplementazio sistema guztiz paralelo batera pasatuz, sistema zaharretik desberdin diseinatu zena. Alegia, orain ez dugu koderik bidali zerbitzarietara sinkronizazio script bat erabiliz. Orain zerbitzari bakoitzak modu independentean deskargatu zuen muntaia berria, jakinda hori egin behar zuela Kontsularen gako aldaketa kontrolatuz. Zerbitzariek paraleloan kargatu zuten kodea. Horri esker, inplementazio-abiadura handia mantendu genuen sistema etengabe hazten den ingurune batean ere.
1. Produkzio-zerbitzariek Kontsularen gakoa kontrolatzen dute. 2. Gakoa aldatzen da, honek zerbitzariei kode berria deskargatzen hasi behar dutela esaten die. 3. Zerbitzariek tarball fitxategiak deskargatzen dituzte aplikazioaren kodearekin
βInplementazio atomikoak
Maila anitzeko hedapen-sistema batera iristen lagundu zigun beste irtenbide bat hedapen atomikoa izan zen.
Inplementazio atomikoak erabili aurretik, inplementazio bakoitzak errore-mezu ugari sor ditzake. Kontua da produkzio-zerbitzarietan fitxategi berriak kopiatzeko prozesua ez zela atomikoa izan. Horrek denbora-leiho laburra ekarri zuen non funtzio berriak deitzen zituen kodea erabilgarri zegoen funtzioak beraiek erabilgarri egon aurretik. Kode hori deitzen zenean, barne akatsak itzuli ziren. Hau huts egin duten API eskaeretan eta hautsitako web orrialdeetan agertu da.
Arazo hau lantzen ari den taldeak direktorio βberoaβ eta βhotzaβ kontzeptua sartuz konpondu zuen. Direktorio beroko kodea ekoizpen-trafikoa prozesatzeaz arduratzen da. Eta direktorio "hotzetan", kodea, sistema martxan dagoen bitartean, erabiltzeko bakarrik prestatzen ari da. Inplementazioan, kode berria erabiltzen ez den direktorio hotz batera kopiatzen da. Ondoren, zerbitzarian prozesu aktiborik ez dagoenean, berehalako direktorio aldaketa bat egiten da.
1. Aplikazio-kodea deskonprimitu direktorio "hotz" batean. 2. Sistema direktorio βhotzβ batera aldatzea, βberoβ bihurtzen dena (eragiketa atomikoa)
Emaitzak: fidagarritasunera enfasia aldatzea
2018an, proiektua halako eskalaraino hazi zen, non hedapen oso azkarra produktuaren egonkortasuna kaltetzen hasi zen. Inplementazio sistema oso aurreratua genuen eta horretan denbora eta esfortzu asko inbertitu genuen. Gure inplementazio-prozesuak berreraiki eta hobetzea besterik ez genuen egin behar. Enpresa handi samarra bihurtu gara, eta haren garapenak mundu osoan erabili dira etenik gabeko komunikazioak antolatzeko eta arazo garrantzitsuak konpontzeko. Horregatik, fidagarritasuna bihurtu zen gure arretaren ardatz.
Slack bertsio berriak zabaltzeko prozesua seguruagoa egin behar genuen. Behar honek gure hedapen sistema hobetzera eraman gintuen. Izan ere, sistema hobetu honi buruz hitz egin dugu. Sistemaren sakonean, hedapen-teknologia azkarrak eta atomikoak erabiltzen jarraitzen dugu. Hedapena egiteko modua aldatu egin da. Gure sistema berria maila ezberdinetan kode berria pixkanaka zabaltzeko diseinatuta dago, ingurune ezberdinetan. Orain lehen baino laguntza-tresna aurreratuagoak eta sistema kontrolatzeko tresnak erabiltzen ditugu. Horrek akatsak atzemateko eta konpontzeko gaitasuna ematen digu azken erabiltzailearengana iristeko aukera izan baino askoz lehenago.
Baina ez gara hor geldituko. Sistema hau etengabe hobetzen ari gara, tresna laguntzaile eta lana automatizatzeko tresna aurreratuagoak erabiliz.
Irakurle maitea! Nola funtzionatzen du lan egiten duzun tokian proiektuen bertsio berriak zabaltzeko prozesuak?
Iturria: www.habr.com