Sjellja e një publikimi të ri të projektit në prodhim kërkon një ekuilibër të kujdesshëm midis shpejtësisë së vendosjes dhe besueshmërisë së zgjidhjes. Slack vlerëson përsëritjet e shpejta, ciklet e shkurtra të reagimit dhe përgjigjen e shpejtë ndaj kërkesave të përdoruesve. Përveç kësaj, kompania ka qindra programues që përpiqen të jenë sa më produktivë.
Autorët e materialit, përkthimin e të cilit po botojmë sot, thonë se një kompani që përpiqet t'u përmbahet vlerave të tilla dhe në të njëjtën kohë rritet, duhet të përmirësojë vazhdimisht sistemin e saj të vendosjes së projekteve. Kompania duhet të investojë në transparencën dhe besueshmërinë e proceseve të punës, duke e bërë këtë për të siguruar që këto procese të korrespondojnë me shkallën e projektit. Këtu do të flasim për rrjedhat e punës që janë zhvilluar në Slack dhe për disa nga vendimet që e çuan kompaninë të përdorë sistemin e vendosjes së projektit që ekziston sot.
Si funksionojnë sot proceset e vendosjes së projektit
Çdo PR (kërkesë tërheqjeje) në Slack duhet t'i nënshtrohet rishikimit të kodit dhe duhet të kalojë me sukses të gjitha testet. Vetëm pasi të plotësohen këto kushte, programuesi mund të bashkojë kodin e tij në degën kryesore të projektit. Sidoqoftë, ky kod vendoset vetëm gjatë orarit të punës, në kohën e Amerikës së Veriut. Si rezultat, për shkak të faktit se punonjësit tanë janë në vendet e tyre të punës, ne jemi plotësisht të përgatitur për të zgjidhur çdo problem të papritur.
Çdo ditë ne kryejmë rreth 12 dislokime të planifikuara. Gjatë çdo vendosjeje, programuesi i caktuar si drejtuesi i vendosjes është përgjegjës për futjen e ndërtimit të ri në prodhim. Ky është një proces me shumë hapa që siguron që montimi të sillet në prodhim pa probleme. Falë kësaj qasjeje, ne mund të zbulojmë gabimet përpara se ato të prekin të gjithë përdoruesit tanë. Nëse ka shumë gabime, vendosja e montimit mund të rikthehet. Nëse zbulohet një problem specifik pas lëshimit, lehtësisht mund të lëshohet një rregullim për të.
Ndërfaqja e sistemit të Checkpoint, i cili përdoret në Slack për të vendosur projekte
Procesi i vendosjes së një lëshimi të ri në prodhim mund të mendohet si i përbërë nga katër hapa.
▍1. Krijimi i një dege lëshimi
Çdo lëshim fillon me një degë të re lëshimi, një pikë në historinë tonë të Git. Kjo ju lejon të caktoni etiketa në version dhe ofron një vend ku mund të bëni rregullime të drejtpërdrejta për defektet e gjetura në procesin e përgatitjes së publikimit për lëshim në prodhim.
▍2. Vendosja në një mjedis skenik
Hapi tjetër është vendosja e montimit në serverët e skenës dhe ekzekutimi i një testi automatik për performancën e përgjithshme të projektit (testi i tymit). Mjedisi i skenës është një mjedis prodhimi që nuk pranon trafik të jashtëm. Në këtë mjedis, ne kryejmë testime shtesë manuale. Kjo na jep besim shtesë se projekti i modifikuar funksionon si duhet. Vetëm testet e automatizuara nuk janë të mjaftueshme për të siguruar këtë nivel besimi.
▍3. Shpërndarja në mjedise të testimit dhe kanarinave
Shpërndarja në prodhim fillon me një mjedis testimi, i përfaqësuar nga një grup hostesh që shërbejnë në hapësirat tona të brendshme të punës Slack. Meqenëse jemi përdorues shumë aktivë të Slack, marrja e kësaj qasjeje na ndihmoi të kapim shumë defekte në fillim të vendosjes. Pasi të jemi siguruar që funksionaliteti bazë i sistemit të mos prishet, montimi vendoset në mjedisin e kanarisë. Ai përfaqëson sisteme që përbëjnë afërsisht 2% të trafikut të prodhimit.
▍4. Lëshimi gradual në prodhim
Nëse treguesit e monitorimit për lëshimin e ri rezultojnë të qëndrueshëm dhe nëse pas vendosjes së projektit në mjedisin e kanarinës nuk kemi marrë asnjë ankesë, vazhdojmë të transferojmë gradualisht serverët e prodhimit në versionin e ri. Procesi i vendosjes ndahet në fazat e mëposhtme: 10%, 25%, 50%, 75% dhe 100%. Si rezultat, ne mund të transferojmë ngadalë trafikun e prodhimit në versionin e ri të sistemit. Në të njëjtën kohë, ne kemi kohë për të hetuar situatën nëse zbulohet ndonjë anomali.
▍Po sikur diçka të shkojë keq gjatë vendosjes?
Bërja e modifikimeve në kod është gjithmonë një rrezik. Por ne e përballojmë këtë falë pranisë së "udhëheqësve të vendosjes" të trajnuar mirë, të cilët menaxhojnë procesin e sjelljes së një versioni të ri në prodhim, monitorojnë treguesit e monitorimit dhe koordinojnë punën e programuesve që lëshojnë kodin.
Në rast se diçka nuk shkon vërtet, ne përpiqemi ta zbulojmë problemin sa më shpejt që të jetë e mundur. Ne e hetojmë problemin, gjejmë PR që po shkakton gabimet, e kthejmë atë, e analizojmë tërësisht dhe krijojmë një ndërtim të ri. Vërtetë, ndonjëherë problemi kalon pa u vënë re derisa projekti të hyjë në prodhim. Në një situatë të tillë, gjëja më e rëndësishme është rivendosja e shërbimit. Prandaj, përpara se të fillojmë të hetojmë problemin, ne kthehemi menjëherë në ndërtimin e mëparshëm të punës.
Ndërtimi i blloqeve të një sistemi vendosjeje
Le të shohim teknologjitë që qëndrojnë në themel të sistemit tonë të vendosjes së projektit.
▍Vendosje të shpejta
Rrjedha e punës e përshkruar më sipër mund të duket, në retrospektivë, disi e qartë. Por sistemi ynë i vendosjes nuk u bë i tillë menjëherë.
Kur kompania ishte shumë më e vogël, i gjithë aplikacioni ynë mund të ekzekutohej në 10 raste të Amazon EC2. Vendosja e projektit në këtë situatë nënkuptonte përdorimin e rsync për të sinkronizuar shpejt të gjithë serverët. Më parë, kodi i ri ishte vetëm një hap larg prodhimit, i përfaqësuar nga një mjedis skenik. Asambletë u krijuan dhe u testuan në një mjedis të tillë, dhe më pas kaluan direkt në prodhim. Ishte shumë e lehtë për të kuptuar një sistem të tillë; ai lejonte çdo programues të vendoste kodin që kishte shkruar në çdo kohë.
Por me rritjen e numrit të klientëve tanë, u rrit edhe shkalla e infrastrukturës së nevojshme për të mbështetur projektin. Së shpejti, duke pasur parasysh rritjen e vazhdueshme të sistemit, modeli ynë i vendosjes, i bazuar në shtyrjen e kodit të ri në serverë, nuk po e bënte më punën e tij. Gjegjësisht, shtimi i çdo serveri të ri nënkuptonte rritjen e kohës së nevojshme për të përfunduar vendosjen. Edhe strategjitë e bazuara në përdorimin paralel të rsync kanë kufizime të caktuara.
Ne përfunduam duke e zgjidhur këtë problem duke kaluar në një sistem vendosjeje krejtësisht paralele, i cili ishte projektuar ndryshe nga sistemi i vjetër. Gjegjësisht, tani ne nuk dërguam kod te serverët duke përdorur një skript sinkronizimi. Tani secili server shkarkoi në mënyrë të pavarur asamblenë e re, duke e ditur se duhej ta bënte këtë duke monitoruar ndryshimin e çelësit të Konsullit. Serverët ngarkuan kodin paralelisht. Kjo na lejoi të ruanim një shpejtësi të lartë vendosjeje edhe në një mjedis me rritje të vazhdueshme të sistemit.
1. Serverët e prodhimit monitorojnë çelësin e Konsullit. 2. Çelësi ndryshon, kjo u tregon serverëve se duhet të fillojnë të shkarkojnë kodin e ri. 3. Serverët shkarkojnë skedarë tarball me kodin e aplikacionit
▍Dislokimet atomike
Një zgjidhje tjetër që na ndihmoi të arrijmë një sistem vendosjeje me shumë nivele ishte vendosja atomike.
Përpara përdorimit të vendosjeve atomike, çdo vendosje mund të rezultojë në një numër të madh mesazhesh gabimi. Fakti është se procesi i kopjimit të skedarëve të rinj në serverët e prodhimit nuk ishte atomik. Kjo rezultoi në një dritare të shkurtër kohore ku kodi që thërriste funksione të reja ishte i disponueshëm përpara se vetë funksionet të ishin të disponueshme. Kur u thirr një kod i tillë, rezultoi në kthimin e gabimeve të brendshme. Kjo u shfaq në kërkesat e dështuara të API dhe faqet e internetit të prishura.
Ekipi që punoi për këtë problem e zgjidhi atë duke prezantuar konceptin e drejtorive "të nxehta" dhe "të ftohta". Kodi në drejtorinë e nxehtë është përgjegjës për përpunimin e trafikut të prodhimit. Dhe në drejtoritë "të ftohta", kodi, ndërsa sistemi po funksionon, po përgatitet vetëm për përdorim. Gjatë vendosjes, kodi i ri kopjohet në një drejtori të ftohtë të papërdorur. Pastaj, kur nuk ka procese aktive në server, kryhet një ndërrim direktoriumi i menjëhershëm.
1. Shpaketimi i kodit të aplikacionit në një direktori "të ftohtë". 2. Kalimi i sistemit në një drejtori "të ftohtë", e cila bëhet "e nxehtë" (operacion atomik)
Rezultatet: zhvendosja e theksit te besueshmëria
Në vitin 2018, projekti u rrit në një shkallë të tillë që vendosja shumë e shpejtë filloi të dëmtonte stabilitetin e produktit. Ne kishim një sistem shumë të avancuar vendosjeje në të cilin investuam shumë kohë dhe përpjekje. Gjithçka që duhej të bënim ishte të rindërtonim dhe përmirësonim proceset tona të vendosjes. Ne jemi rritur në një kompani mjaft të madhe, zhvillimet e së cilës janë përdorur në të gjithë botën për të organizuar komunikime të pandërprera dhe për të zgjidhur probleme të rëndësishme. Prandaj, besueshmëria u bë fokusi i vëmendjes sonë.
Na duhej ta bënim më të sigurt procesin e vendosjes së versioneve të reja Slack. Kjo nevojë na bëri të përmirësojmë sistemin tonë të vendosjes. Në fakt, ne diskutuam këtë sistem të përmirësuar më lart. Në thellësi të sistemit, ne vazhdojmë të përdorim teknologjitë e vendosjes së shpejtë dhe atomike. Mënyra se si bëhet vendosja ka ndryshuar. Sistemi ynë i ri është krijuar për të vendosur gradualisht kodin e ri në nivele të ndryshme, në mjedise të ndryshme. Tani përdorim mjete mbështetëse dhe mjete të monitorimit të sistemit më të avancuara se më parë. Kjo na jep mundësinë për të kapur dhe rregulluar gabimet shumë kohë përpara se të kenë një shans për të arritur përdoruesin përfundimtar.
Por ne nuk do të ndalemi me kaq. Ne jemi duke e përmirësuar vazhdimisht këtë sistem, duke përdorur mjete ndihmëse më të avancuara dhe mjete të automatizimit të punës.
Të nderuar lexues! Si funksionon procesi i vendosjes së publikimeve të reja të projekteve aty ku punoni?
Burimi: www.habr.com