Lëshimi i një versioni të ri të projektit në prodhim kërkon një balancim të kujdesshëm midis shpejtësisë së zhvillimit dhe besueshmërisë së zgjidhjes. Në kompaninë Slack, vlerësojnë iteracione të shpejta, cikle të shkurtra të feedback-ut dhe reagim të shpejtë ndaj kërkesave të përdoruesve. Për më tepër, në kompani ka qindra programues që synojnë produktivitet maksimal.
Autorët e materialit, përkthimi i të cilit po publikojmë sot, thonë se një kompani që synon të ndjekë vlera të tilla dhe për më tepër po rritet, duhet të përmirësojë vazhdimisht sistemin e saj të zhvillimit të projekteve. Kompanitë duhet të investojnë në transparencë dhe besueshmëri të proceseve të punës për të siguruar që këto procese t'i përshtaten përmasave të projektit. Ky artikull do të flasë për proceset e punës që janë krijuar në Slack dhe disa zgjidhje që e çuan kompaninë në përdorimin e sistemit aktual të zhvillimit të projekteve.
Si funksionojnë sot proceset e zhvillimit të projekteve
Ădo PR (pull request) nĂ« Slack duhet patjetĂ«r tĂ« kalojĂ« nĂ«pĂ«r njĂ« rishikim kodi dhe duhet tĂ« kalojĂ« me sukses tĂ« gjitha testet. VetĂ«m pas pĂ«rmbushjes sĂ« kĂ«tyre kushteve, programuesi mund tĂ« kryejĂ« bashkimin e kodit tĂ« tij me degĂ«n master tĂ« projektit. MegjithatĂ«, zhvillimi i kĂ«tij kodi realizohet vetĂ«m nĂ« orar tĂ« punĂ«s sipas kohĂ«s sĂ« AmerikĂ«s sĂ« Veriut. Si rezultat, ne, pĂ«r shkak se punonjĂ«sit tanĂ« janĂ« nĂ« punĂ«, jemi plotĂ«sisht tĂ« gatshĂ«m pĂ«r tĂ« zgjidhur çdo problem tĂ« papritur.
Ădo ditĂ« ne realizojmĂ« rreth 12 zhvillime tĂ« planifikuara. NĂ« procesin e çdo zhvillimi, programuesi i emĂ«ruar si pĂ«rgjegjĂ«s pĂ«r zhvillimet, Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r nxjerrjen e njĂ« ndĂ«rtese tĂ« re nĂ« prodhim. Ky Ă«shtĂ« njĂ« proces me shumĂ« hapa qĂ« siguron njĂ« kalim tĂ« qetĂ« tĂ« ndĂ«rtese nĂ« modin aktiv. FalĂ« kĂ«tij qasje, ne mund tĂ« identifikojmĂ« gabimet para se ato tĂ« ndikojnĂ« te çdo pĂ«rdorues tonin. NĂ«se ka shumĂ« gabime, zhvillimi mund tĂ« anulohet. NĂ«se njĂ« problem i veçantĂ« zbulohet pas lĂ«shimit, Ă«shtĂ« e lehtĂ« tĂ« lĂ«shosh njĂ« rregullim pĂ«r tĂ«.
Interfaca e sistemit Checkpoint, e cila përdoret në Slack për zhvillimin e projekteve
Procesi i zhvillimit të një versioni të ri në prodhim mund të përfaqësohet nga katër hapa.
â1. Krijimi i degĂ«s sĂ« lĂ«shimit
Ădo lĂ«shim fillon me njĂ« degĂ« tĂ« re tĂ« lĂ«shimit, nga momenti nĂ« historinĂ« tonĂ« Git. Kjo lejon qĂ« tĂ« caktojmĂ« etiketat pĂ«r lĂ«shimin dhe krijon njĂ« hapĂ«sirĂ« ku mund tĂ« bĂ«jmĂ« korrigjime tĂ« menjĂ«hershme pĂ«r gabimet e gjetura gjatĂ« pĂ«rgatitjes sĂ« lĂ«shimit pĂ«r publikim nĂ« prodhim.
â2. ShpĂ«rndarja nĂ« mjedisin e ndĂ«rmjetĂ«m
Hapi tjetër i punës është shpërndarja e ndërtimit në servera ndërmjetës (staging) dhe ekzekutimi i testit automatik për funksionalitetin e përgjithshëm të projektit (smoke test). Mjedisi ndërmjetës është mjedisi i prodhimit, ku nuk kalon trafiku i jashtëm. Në këtë mjedis ne kryejmë testime manuale të tjera. Kjo na jep një besim të shtuar se projekti i ndryshuar funksionon siç duhet. Vetëm testet automatizuar nuk janë të mjaftueshme për të fituar një besim të tillë.
â3. ShpĂ«rndarja nĂ« mjediset dogfood dhe canary
Shpërndarja në prodhim fillon me mjedisin dogfood, i cili përbëhet nga një grup hostesh që shërbejnë hapësirat tona të punës në Slack. Duke qenë se jemi përdorues shumë aktivë të Slack, ky qasje ka ndihmuar në zbardhjen e shumë gabimeve në fazat e hershme të shpërndarjes. Pasi të jemi siguruar që funksionaliteti bazë i sistemit nuk është thyer, shpërndajmë ndërtimin në mjedisin canary. Ky përbën sisteme që marrin rreth 2% të trafikut të prodhimit.
â4. Nxjerrja graduale nĂ« prodhim
Nëse treguesit e monitorimit për lëshimin e ri janë të qëndrueshëm, dhe pas shpërndarjes së projektit në mjedisin canary nuk kemi marrë ankesa, vazhdojmë me transferimin gradual të serverëve të prodhimit në lëshimin e ri. Procesi i shpërndarjes është i ndarë në faza: 10%, 25%, 50%, 75% dhe 100%. Kështu ne mund të kalojmë ngadalë trafikun e prodhimit në lëshimin e ri të sistemit. Gjatë kësaj kohe kemi hapësirë për të hetuar situatën në rast se shfaqen anomali të caktuara.
âĂfarĂ« tĂ« bĂ«jmĂ« nĂ«se gjatĂ« shpĂ«rndarjes ndodhi diçka qĂ« shkoi keq?
Modifikimi i kodit gjithmonë përmban rrezik. Por ne e menaxhojmë këtë falë të pasurive të mira të «shefave të shpërndarjes», të cilët drejtojnë procesin e daljes së versioneve të reja në prodhim, monitorojnë parametrat dhe koordinojnë punën e programuesve që lëshojnë kodin.
Nëse ndonjëherë diçka shkon keq, ne përpiqemi ta zbulojmë problemin sa më herët të jetë e mundur. Ne shqyrtojmë problemin, gjejmë PR-in që shkakton gabime, e rrotullojmë atë, e analizojmë me kujdes dhe krijojmë një ndërtim të ri. E vërteta është se ndonjëherë problemi mbetet i paditur deri në daljen e projektit në prodhim. Në një situatë të tillë, gjëja më e rëndësishme është rikthimi i funksionimit të shërbimit. Prandaj, para se të fillojmë hetimin e problemit, ne menjëherë kthehemi në ndërtimin e mëparshëm të punës.
Blloqet ndërtuese të sistemit tonë të shpërndarjes
Le të shqyrtojmë teknologjitë që qëndrojnë pas sistemit tonë të shpërndarjes së projekteve.
âShpĂ«rndarje tĂ« shpejta
Procesi i punës i përshkruar më sipër mund të duket, në retrospektivë, si diçka krejtësisht e qartë. Por sistemi ynë i shpërndarjes nuk u bë kështu menjëherë.
Kur kompania ishte shumë më e vogël, gjithë aplikacioni ynë mund të funksiononte në 10 instanca Amazon EC2. Shpërndarja e një projekti në një situatë të tillë do të thoshte përdorimin e rsync për sinkronizimin e shpejtë të të gjithë serverëve. Disa kohë, kodi i ri nga prodhimi ndaheshin vetëm me një hap, të paraqitur nga ambienti ndërmjetës. Ndërtimet krijoheshin dhe kontrolloheshin në një ambient të tillë dhe pastaj shkonin menjëherë në prodhim. Të kuptuarit e një sistemi të tillë ishte shumë e lehtë, ai lejonte çdo programues të shpejtojë kodin e shkruar në çdo kohë.
Por ndërsa numri i klientëve tanë rritej, rritej edhe shkalla e infrastrukturës që nevojitej për të mbështetur projektin. Shpejt, duke marrë parasysh rritjen e vazhdueshme të sistemit, modeli ynë i shpërndarjes, i bazuar në dërgimin e kodit të ri në serverë, nuk ishte më në gjendje të përmbushte detyrën e tij. Konkretisht, shtimi i çdo serveri të ri do të thoshte rritje të kohës së nevojshme për të realizuar shpërndarjen. Edhe strategjitë që bazohen në aplikimin paralel të rsync kanë kufizime të caktuara.
Si nĂ« fund, ne zgjidhĂ«m kĂ«tĂ« problem duke kaluar nĂ« njĂ« sistem tĂ«rĂ«sisht paralel tĂ« implementimit, i cili nuk ishte i ndĂ«rtuar si sistemi i vjetĂ«r. Tani, ne nuk dĂ«rgonim kodin nĂ« serverĂ« duke pĂ«rdorur njĂ« skritp sinkronizimi. Ădo server tani ngarkohej automatikisht me njĂ« version tĂ« ri, duke e mĂ«suar kĂ«tĂ« nevojĂ« pĂ«rmes ndjekjes sĂ« ndryshimit tĂ« çelĂ«sit Consul. ServerĂ«t ngarkonin kodin paralelisht. Kjo na lejoi tĂ« mbajmĂ« njĂ« shpejtĂ«si tĂ« lartĂ« tĂ« implementimit edhe nĂ« njĂ« ambient me rritje tĂ« vazhdueshme tĂ« sistemit.
1. ServerĂ«t e prodhimit ndjekin çelĂ«sin Consul. 2. ĂelĂ«si ndryshon, duke i njoftuar serverĂ«t se duhet tĂ« fillojnĂ« ngarkimin e kodit tĂ« ri. 3. ServerĂ«t ngarkojnĂ« skedarĂ« tarball me kodin e aplikacionit.
âImplementime atomike
Një tjetër zgjidhje që na ndihmoi të arrijmë një sistem të ndarë të implementimit ishte implementimi atomic.
Para pĂ«rdorimit tĂ« implementimeve atomike, çdo implementim mund tĂ« çonte nĂ« njĂ« numĂ«r tĂ« madh mesazhesh gabimi. Kjo ndodhte sepse procesi i kopjimit tĂ« skedareve tĂ« rinj nĂ« serverĂ«t e prodhimit nuk ishte atomic. Kjo kishim pĂ«r pasojĂ« qĂ« pĂ«r njĂ« periudhĂ« tĂ« shkurtĂ«r, kodi qĂ« thĂ«rriste funksionet e reja bĂ«hej i qasshĂ«m para se vetĂ« funksionet tĂ« ishin tĂ« disponueshme. Kur ky kod thĂ«rritej, kjo sillte kthimin e gabimeve tĂ« brendshme. Kjo shfaqej nĂ« kĂ«rkesat e dĂ«shtuara ndaj API-sĂ« dhe nĂ« faqe tĂ« âprishuraâ web.
Ekipa qĂ« merrej me kĂ«tĂ« problem e zgjidhi atĂ« duke pĂ«rdorur konceptet e direktorive âtĂ« nxehtaâ (hot) dhe âtĂ« ftohtaâ (cold). Kodi nĂ« direktorinĂ« âtĂ« nxehtĂ«â pĂ«rgjigjet pĂ«r pĂ«rpunimin e trafikut tĂ« prodhimit. NdĂ«rsa nĂ« direktorive âtĂ« ftohtaâ, kodi pĂ«rgatitet pĂ«r pĂ«rdorim gjatĂ« punĂ«s sĂ« sistemit. GjatĂ« implementimit, kodi i ri kopjohet nĂ« njĂ« direktorinĂ« âtĂ« ftohtĂ«â qĂ« nuk pĂ«rdoret. Pastaj, kur nĂ« server nuk ka procese aktive, bĂ«het njĂ« kalim i menjĂ«hershĂ«m i direktorive.
1. Zhbllokimi i kodit tĂ« aplikacionit nĂ« direktorinĂ« âtĂ« ftohtĂ«â. 2. Kalimi i sistemit nĂ« direktorinĂ« âtĂ« ftohtĂ«â, e cila bĂ«het âtĂ« nxehtĂ«â (operacion atomic).
Përfundime: kalimi në fokusin te qëndrueshmëria.
Në vitin 2018, projekti arriti një shkallë ku shpërndarja e shpejtë filloi të dëmtonte stabilitetin e produktit. Kishim një sistem të avancuar shpërndarjeje, në të cilin kishim investuar shumë përpjekje dhe kohë. Na nevojitej vetëm të ristrukturojmë dhe përmirësojmë proceset e organizimit të shpërndarjes. U bëmë një kompani mjaft të madhe, zhvillimet e së cilës përdoren në të gjithë botën për të organizuar komunikimin e pandërprerë dhe për të zgjidhur probleme të rëndësishme. Prandaj, fokusimi ynë ishte në besueshmëri.
Na nevojitej të bënim procesin e shpërndarjes së versioneve të reja të Slack më të sigurta. Kjo nevojë na çoi në përmirësimin e sistemit tonë të shpërndarjes. Në thellësitë e sistemit, ne vazhdojmë të përdorim teknologjitë e shpërndarjes së shpejtë dhe atomike. Ajo që ndryshoi është mënyra se si konkretisht bëhet shpërndarja. Sistemi ynë i ri është dizajnuar për të realizuar gradualisht shpërndarjen e kodit të ri në nivele të ndryshme, në mjedise të ndryshme. Tani përdorim mjete ndihmëse dhe instrumente monitorimi më të avancuara se më parë. Kjo na jep mundësinë të kapim dhe zgjidhim gabimet shumë përpara se ato të kenë mundësinë të arrijnë te përdoruesi i fundit.
Por ne nuk planifikojmë të ndalemi këtu. Ne vazhdimisht po e përmirësojmë këtë sistem duke aplikuar mjete ndihmëse dhe metoda automatizimi më të avancuara.
Të nderuar lexues! Si është organizuar procesi i shpërndarjes së versioneve të reja të projekteve atje ku punoni ju?
Burimi: habr.com
