Kuleta toleo jipya la mradi katika uzalishaji kunahitaji uwiano wa makini kati ya kasi ya upelekaji na utegemezi wa suluhisho. Thamani zisizo na kasi kurudiwa kwa haraka, mizunguko mifupi ya maoni, na majibu ya haraka kwa maombi ya mtumiaji. Kwa kuongezea, kampuni ina mamia ya watengenezaji programu ambao wanajitahidi kuwa na tija iwezekanavyo.
Waandishi wa nyenzo, tafsiri ambayo tunachapisha leo, wanasema kwamba kampuni ambayo inajitahidi kuzingatia maadili kama hayo na wakati huo huo inakua lazima iboreshe mfumo wake wa kupeleka mradi kila wakati. Kampuni inahitaji kuwekeza katika uwazi na kuegemea kwa michakato ya kazi, ikifanya hivi ili kuhakikisha kuwa michakato hii inalingana na ukubwa wa mradi. Hapa tutazungumza juu ya mtiririko wa kazi ambao umetengenezwa katika Slack, na kuhusu baadhi ya maamuzi ambayo yalisababisha kampuni kutumia mfumo wa kusambaza mradi uliopo leo.
Jinsi michakato ya kusambaza mradi inavyofanya kazi leo
Kila PR (ombi la kuvuta) katika Slack lazima iwe chini ya ukaguzi wa msimbo na lazima ifaulu majaribio yote. Ni baada tu ya masharti haya kutimizwa ndipo mpangaji programu anaweza kuunganisha msimbo wake kwenye tawi kuu la mradi. Hata hivyo, msimbo huu hutumwa tu wakati wa saa za kazi, saa za Amerika Kaskazini. Matokeo yake, kutokana na ukweli kwamba wafanyakazi wetu wako kwenye maeneo yao ya kazi, tumejiandaa kikamilifu kutatua matatizo yoyote yasiyotarajiwa.
Kila siku tunatekeleza takriban mipango 12 ya kupeleka. Wakati wa kila upelekaji, mtayarishaji programu aliyeteuliwa kama kiongozi wa upelekaji anawajibika kupata muundo mpya katika uzalishaji. Huu ni mchakato wa hatua nyingi ambao unahakikisha mkusanyiko unaletwa katika uzalishaji vizuri. Shukrani kwa mbinu hii, tunaweza kugundua makosa kabla ya kuathiri watumiaji wetu wote. Ikiwa kuna makosa mengi, uwekaji wa mkusanyiko unaweza kurudishwa nyuma. Ikiwa tatizo mahususi litagunduliwa baada ya kutolewa, linaweza kusuluhishwa kwa urahisi.
Kiolesura cha mfumo wa Checkpoint, unaotumika katika Slack kupeleka miradi
Mchakato wa kupeleka toleo jipya kwa umma unaweza kuzingatiwa kuwa unajumuisha hatua nne.
β1. Kuunda tawi la kutolewa
Kila toleo huanza na tawi jipya la toleo, hatua katika historia yetu ya Git. Hii hukuruhusu kugawa lebo kwenye toleo na hutoa mahali ambapo unaweza kufanya marekebisho ya moja kwa moja ya hitilafu zinazopatikana katika mchakato wa kuandaa toleo kwa ajili ya kutolewa kwa toleo la umma.
β2. Kupelekwa katika mazingira ya jukwaa
Hatua inayofuata ni kupeleka mkusanyiko kwenye seva za staging na kukimbia mtihani wa moja kwa moja kwa utendaji wa jumla wa mradi (mtihani wa moshi). Mazingira ya jukwaa ni mazingira ya uzalishaji ambayo haipati trafiki ya nje. Katika mazingira haya, tunafanya majaribio ya ziada ya mwongozo. Hii inatupa imani ya ziada kuwa mradi uliorekebishwa hufanya kazi kwa usahihi. Majaribio ya kiotomatiki pekee hayatoshi kutoa kiwango hiki cha kujiamini.
β3. Usambazaji katika vyakula vya kindani na mazingira ya canary
Usambazaji kwenye toleo la umma huanza na mazingira ya jaribio la kindani, linalowakilishwa na kundi la wapangishi wanaohudumia nafasi zetu za kazi za ndani za Slack. Kwa kuwa sisi ni watumiaji wa Slack amilifu, kuchukua mbinu hii kulitusaidia kupata hitilafu nyingi mapema katika uwekaji. Baada ya kuhakikisha kuwa utendaji wa msingi wa mfumo haujavunjwa, mkusanyiko unatumiwa katika mazingira ya canary. Inawakilisha mifumo inayochukua takriban 2% ya trafiki ya uzalishaji.
β4. Kutolewa taratibu kwa uzalishaji
Ikiwa viashiria vya ufuatiliaji wa toleo jipya vinageuka kuwa imara, na ikiwa baada ya kupeleka mradi katika mazingira ya canary hatujapokea malalamiko yoyote, tunaendelea kuhamisha seva za uzalishaji hatua kwa hatua kwenye toleo jipya. Mchakato wa kupeleka umegawanywa katika hatua zifuatazo: 10%, 25%, 50%, 75% na 100%. Kwa hivyo, tunaweza kuhamisha polepole trafiki ya uzalishaji hadi toleo jipya la mfumo. Wakati huo huo, tunayo wakati wa kuchunguza hali hiyo ikiwa shida yoyote itagunduliwa.
βJe, ikiwa kitu kitaenda vibaya wakati wa kusambaza?
Kufanya marekebisho kwa msimbo daima ni hatari. Lakini tunakabiliana na shukrani hii kwa uwepo wa "viongozi wa upelekaji" waliofunzwa vyema ambao husimamia mchakato wa kuleta toleo jipya katika uzalishaji, kufuatilia viashiria vya ufuatiliaji na kuratibu kazi ya waandaaji wa programu wanaotoa msimbo.
Katika tukio ambalo kitu kitaenda vibaya, tunajaribu kugundua shida mapema iwezekanavyo. Tunachunguza tatizo, kutafuta PR ambayo inasababisha makosa, irudishe nyuma, tuichambue kwa kina, na kuunda muundo mpya. Kweli, wakati mwingine tatizo huenda bila kutambuliwa hadi mradi unapoingia katika uzalishaji. Katika hali hiyo, jambo muhimu zaidi ni kurejesha huduma. Kwa hiyo, kabla ya kuanza kuchunguza tatizo, tunarudi mara moja kwenye muundo wa awali wa kufanya kazi.
Vitalu vya Ujenzi wa Mfumo wa Usambazaji
Hebu tuangalie teknolojia zinazosimamia mfumo wetu wa kusambaza mradi.
β Usambazaji wa haraka
Mtiririko wa kazi ulioelezewa hapo juu unaweza kuonekana, kwa kuangalia nyuma, dhahiri. Lakini mfumo wetu wa kupeleka haukuwa hivi mara moja.
Wakati kampuni ilikuwa ndogo zaidi, programu yetu yote inaweza kuendeshwa kwenye matukio 10 ya Amazon EC2. Kupeleka mradi katika hali hii kulimaanisha kutumia rsync kusawazisha seva zote haraka. Hapo awali, msimbo mpya ulikuwa hatua moja tu kutoka kwa uzalishaji, ukiwakilishwa na mazingira ya jukwaa. Makusanyiko yaliundwa na kujaribiwa katika mazingira kama haya, na kisha kwenda moja kwa moja kwenye uzalishaji. Ilikuwa rahisi sana kuelewa mfumo kama huo; iliruhusu programu yoyote kupeleka nambari aliyokuwa ameandika wakati wowote.
Lakini kadiri idadi ya wateja wetu inavyoongezeka, ndivyo na ukubwa wa miundombinu inayohitajika kusaidia mradi huo. Hivi karibuni, kutokana na ukuaji wa mara kwa mara wa mfumo, mtindo wetu wa kupeleka, kulingana na kusukuma msimbo mpya kwa seva, haukufanya kazi yake tena. Yaani, kuongeza kila seva mpya kulimaanisha kuongeza muda unaohitajika kukamilisha utumaji. Hata mikakati kulingana na utumiaji sambamba wa rsync ina mapungufu fulani.
Tulimaliza kutatua tatizo hili kwa kuhamia kwenye mfumo wa upelekaji sambamba kabisa, ambao uliundwa tofauti na mfumo wa zamani. Yaani, sasa hatukutuma msimbo kwa seva kwa kutumia hati ya ulandanishi. Sasa kila seva ilipakua mkusanyiko mpya kwa kujitegemea, ikijua kwamba ilihitaji kufanya hivyo kwa kufuatilia mabadiliko ya ufunguo wa Balozi. Seva zilipakia msimbo sambamba. Hii ilituwezesha kudumisha kasi ya juu ya kupelekwa hata katika mazingira ya ukuaji wa mfumo wa mara kwa mara.
1. Seva za uzalishaji hufuatilia ufunguo wa Balozi. 2. Mabadiliko muhimu, hii inawaambia seva kwamba wanahitaji kuanza kupakua msimbo mpya. 3. Seva hupakua faili za tarball na msimbo wa maombi
β Usambazaji wa atomiki
Suluhisho lingine ambalo lilitusaidia kufikia mfumo wa uwekaji wa viwango vingi lilikuwa uwekaji wa atomiki.
Kabla ya kutumia usambazaji wa atomiki, kila uwekaji unaweza kusababisha idadi kubwa ya ujumbe wa makosa. Ukweli ni kwamba mchakato wa kunakili faili mpya kwa seva za uzalishaji haukuwa wa atomiki. Hii ilisababisha dirisha fupi la muda ambapo msimbo ulioita vitendaji vipya ulipatikana kabla ya vitendaji vyenyewe kupatikana. Nambari kama hiyo ilipopigiwa simu, ilisababisha makosa ya ndani kurejeshwa. Hili lilijidhihirisha katika maombi yasiyofanikiwa ya API na kurasa za wavuti zilizovunjika.
Timu iliyoshughulikia tatizo hili ilitatua kwa kuanzisha dhana ya saraka za "moto" na "baridi". Nambari katika saraka ya moto inawajibika kwa usindikaji wa trafiki ya uzalishaji. Na katika saraka za "baridi", msimbo, wakati mfumo unaendelea, unatayarishwa tu kwa matumizi. Wakati wa kupeleka, msimbo mpya unakiliwa kwenye saraka baridi isiyotumiwa. Kisha, wakati hakuna michakato inayotumika kwenye seva, swichi ya saraka ya papo hapo inafanywa.
1. Kufungua msimbo wa maombi kwenye saraka "baridi". 2. Kubadilisha mfumo kwa saraka ya "baridi", ambayo inakuwa "moto" (operesheni ya atomiki)
Matokeo: kuhama kwa msisitizo hadi kutegemewa
Mnamo mwaka wa 2018, mradi ulikua kwa kiwango ambacho upelekaji wa haraka sana ulianza kudhuru uthabiti wa bidhaa. Tulikuwa na mfumo wa hali ya juu sana wa kupeleka ambao tuliwekeza muda mwingi na juhudi. Tulichohitaji kufanya ni kujenga upya na kuboresha michakato yetu ya kupeleka. Tumekua kampuni kubwa, ambayo maendeleo yake yametumika ulimwenguni kote kuandaa mawasiliano yasiyokatizwa na kutatua shida muhimu. Kwa hivyo, kuegemea ikawa lengo la umakini wetu.
Tulihitaji kufanya mchakato wa kupeleka matoleo mapya ya Slack salama zaidi. Hitaji hili lilituongoza kuboresha mfumo wetu wa kupeleka. Kwa kweli, tulijadili mfumo huu ulioboreshwa hapo juu. Katika kina cha mfumo, tunaendelea kutumia teknolojia ya uwekaji wa haraka na wa atomiki. Njia ya kusambaza inafanywa imebadilika. Mfumo wetu mpya umeundwa ili kupeleka msimbo mpya hatua kwa hatua katika viwango tofauti, katika mazingira tofauti. Sasa tunatumia zana za usaidizi za kina zaidi na zana za ufuatiliaji wa mfumo kuliko hapo awali. Hii inatupa uwezo wa kupata na kurekebisha makosa muda mrefu kabla ya kupata nafasi ya kufikia mtumiaji wa mwisho.
Lakini hatutaishia hapo. Tunaboresha mfumo huu kila wakati, kwa kutumia zana za usaidizi za hali ya juu zaidi na zana za otomatiki za kazi.
Ndugu wasomaji! Je, mchakato wa kupeleka matoleo mapya ya mradi hufanya kazi vipi mahali unapofanya kazi?
Chanzo: mapenzi.com