Sehemu ya 1: Wavuti/Android
Kumbuka: makala hii ni tafsiri katika Kirusi ya makala ya awali Hata hivyo, vielelezo vyote, viungo, nukuu na maneno yanahifadhiwa katika lugha ya asili ili kuepuka upotovu wa maana unapotafsiriwa kwa Kirusi. Nakutakia furaha ya kusoma!
Hivi sasa, utaalam wa DevOps ni moja wapo inayohitajika sana katika tasnia ya IT. Ukifungua tovuti maarufu za utafutaji wa kazi na kuchuja kwa mshahara, utaona kwamba kazi zinazohusiana na DevOps ziko juu ya orodha. Hata hivyo, ni muhimu kuelewa kwamba hii inahusu hasa nafasi ya 'Mkubwa', ambayo ina maana kwamba mgombea ana kiwango cha juu cha ujuzi, ujuzi wa teknolojia na zana. Hii pia inakuja na kiwango cha juu cha uwajibikaji unaohusishwa na uendeshaji usiokatizwa wa uzalishaji. Walakini, tulianza kusahau DevOps ni nini. Hapo awali, haikuwa mtu au idara maalum. Ikiwa tutatafuta ufafanuzi wa neno hili, tutapata nomino nyingi nzuri na sahihi, kama vile mbinu, mazoea, falsafa ya kitamaduni, kikundi cha dhana, na kadhalika.
Utaalam wangu ni mhandisi wa otomatiki wa majaribio (mhandisi wa otomatiki wa QA), lakini ninaamini kuwa haipaswi kuhusishwa tu na uandishi wa majaribio ya kiotomatiki au kuunda usanifu wa mfumo wa majaribio. Mnamo 2020, ujuzi wa miundombinu ya otomatiki pia ni muhimu. Hii hukuruhusu kupanga mchakato wa kiotomatiki mwenyewe, kutoka kwa kufanya majaribio hadi kutoa matokeo kwa washikadau wote kwa mujibu wa malengo yako. Kwa hivyo, ujuzi wa DevOps ni wa lazima ili kukamilisha kazi. Na hii yote ni nzuri, lakini, kwa bahati mbaya, kuna shida (spoiler: makala hii inajaribu kurahisisha tatizo hili) Jambo ni kwamba DevOps ni ngumu. Na hii ni dhahiri, kwa sababu makampuni hayatalipa mengi kwa kitu ambacho ni rahisi kufanya ... Katika ulimwengu wa DevOps, kuna idadi kubwa ya zana, masharti, na mazoea ambayo yanahitaji kuwa mastered. Hii ni ngumu sana mwanzoni mwa kazi na inategemea uzoefu wa kiufundi uliokusanywa.
Chanzo:
Hapa labda tutamaliza na sehemu ya utangulizi na kuzingatia madhumuni ya kifungu hiki.
Makala hii inahusu nini?
Katika nakala hii, nitashiriki uzoefu wangu wa kujenga miundombinu ya otomatiki ya majaribio. Kuna vyanzo vingi vya habari kwenye mtandao kuhusu zana mbalimbali na jinsi ya kuzitumia, lakini ningependa kuziangalia tu katika muktadha wa otomatiki. Ninaamini kuwa wahandisi wengi wa otomatiki wanajua hali hiyo wakati hakuna mtu isipokuwa wewe anayeendesha majaribio yaliyotengenezwa au anayejali kuvitunza. Kwa hivyo, majaribio hupitwa na wakati na itabidi utumie wakati kusasisha. Tena, mwanzoni mwa kazi, hii inaweza kuwa kazi ngumu sana: kuamua kwa busara ni zana zipi zinapaswa kusaidia kuondoa shida fulani, jinsi ya kuchagua, kusanidi na kudumisha. Wajaribu wengine hugeukia DevOps (wanadamu) kwa usaidizi na, hebu tuwe waaminifu, mbinu hii inafanya kazi. Katika hali nyingi hii inaweza kuwa chaguo pekee kwani hatuna mwonekano katika vitegemezi vyote. Lakini kama tunavyojua, DevOps wana shughuli nyingi sana, kwa sababu wanapaswa kufikiria juu ya miundombinu ya kampuni nzima, upelekaji, ufuatiliaji, huduma ndogo na kazi zingine zinazofanana kulingana na shirika/timu. Kama kawaida, otomatiki sio kipaumbele. Katika hali kama hiyo, lazima tujaribu kufanya kila linalowezekana kutoka mwanzo hadi mwisho. Hii itapunguza utegemezi, kuharakisha mtiririko wa kazi, kuboresha ujuzi wetu na kuturuhusu kuona picha kubwa ya kile kinachotokea.
Kifungu kinawasilisha zana maarufu na maarufu na inaonyesha jinsi ya kuzitumia kujenga miundombinu ya otomatiki hatua kwa hatua. Kila kikundi kinawakilishwa na zana ambazo zimejaribiwa kupitia uzoefu wa kibinafsi. Lakini hiyo haimaanishi kwamba unapaswa kutumia kitu kimoja. Zana zenyewe sio muhimu, zinaonekana na kuwa za kizamani. Kazi yetu ya uhandisi ni kuelewa kanuni za msingi: kwa nini tunahitaji kikundi hiki cha zana na matatizo gani ya kazi tunaweza kutatua kwa msaada wao. Ndiyo maana mwisho wa kila sehemu ninaacha viungo vya zana zinazofanana ambazo zinaweza kutumika katika shirika lako.
Nini si katika makala hii
Ninarudia tena kwamba kifungu hicho sio juu ya zana maalum, kwa hivyo hakutakuwa na viingilio vya msimbo kutoka kwa nyaraka na maelezo ya amri maalum. Lakini mwisho wa kila sehemu ninaacha viungo kwa ajili ya utafiti wa kina.
Hii inafanywa kwa sababu:
- nyenzo hii ni rahisi sana kupata katika vyanzo mbalimbali (nyaraka, vitabu, kozi za video);
- ikiwa tutaanza kwenda zaidi, tutalazimika kuandika sehemu 10, 20, 30 za kifungu hiki (wakati mipango ni 2-3);
- Sitaki tu kupoteza muda wako kwani unaweza kutaka kutumia zana zingine kufikia malengo sawa.
Mazoezi
Ningependa sana nyenzo hii iwe na manufaa kwa kila msomaji, na sio tu kusoma na kusahau. Katika utafiti wowote, mazoezi ni sehemu muhimu sana. Kwa hili nimeandaa. Pia kuna kazi ya nyumbani inayokungoja ili kuhakikisha kuwa haukili bila akili mistari ya amri unazotekeleza.
Mpango
Hatua ya
Teknolojia
Zana
1
Uendeshaji wa ndani (tayarisha majaribio ya onyesho ya wavuti / android na uiendeshe karibu nawe)
Node.js, Selenium, Apium
2
Mifumo ya kudhibiti toleo
kwenda
3
Kuweka vyombo
Docker, gridi ya Selenium, Selenoid (Mtandao, Android)
4
CI/CD
Gitlab CI
5
Majukwaa ya wingu
Jukwaa la Wingu la Google
6
Uchezaji
Mabernet
7
Miundombinu kama kanuni (IaC)
Terraform, Ansible
Muundo wa kila sehemu
Ili kuweka simulizi wazi, kila sehemu imeelezewa kulingana na muhtasari ufuatao:
- maelezo mafupi ya teknolojia,
- thamani ya miundombinu ya otomatiki,
- kielelezo cha hali ya sasa ya miundombinu,
- viungo vya kusoma,
- zana zinazofanana.
1. Fanya majaribio ndani ya nchi
Maelezo mafupi ya teknolojia
Hii ni hatua ya maandalizi ya kufanya majaribio ya onyesho ndani ya nchi na kuthibitisha kuwa yamefaulu. Katika sehemu ya vitendo, Node.js hutumiwa, lakini lugha ya programu na jukwaa pia sio muhimu na unaweza kutumia wale ambao hutumiwa katika kampuni yako.
Walakini, kama zana za otomatiki, ninapendekeza kutumia Selenium WebDriver kwa majukwaa ya wavuti na Appium ya jukwaa la Android, mtawaliwa, kwani katika hatua zinazofuata tutatumia picha za Docker ambazo zimeundwa kufanya kazi haswa na zana hizi. Aidha, kwa kurejelea mahitaji ya kazi, zana hizi ndizo zinazohitajika zaidi sokoni.
Kama umeona, tunazingatia tu majaribio ya wavuti na Android. Kwa bahati mbaya, iOS ni hadithi tofauti kabisa (asante Apple). Ninapanga kuonyesha suluhisho na mazoea yanayohusiana na IOS katika sehemu zijazo.
Thamani ya miundombinu ya otomatiki
Kwa mtazamo wa miundombinu, kukimbia ndani ya nchi hakutoi thamani yoyote. Unaangalia tu kwamba majaribio yanaendeshwa kwenye mashine ya ndani katika vivinjari vya ndani na viigaji. Lakini kwa hali yoyote, hii ni hatua muhimu ya kuanzia.
Mchoro wa hali ya sasa ya miundombinu
Viungo vya kuchunguza
Zana zinazofanana
- lugha yoyote ya programu unayopenda kwa kushirikiana na vipimo vya Selenium/Appium;
- mitihani yoyote;
- mkimbiaji yeyote wa mtihani.
2. Mifumo ya udhibiti wa toleo (Git)
Maelezo mafupi ya teknolojia
Haitakuwa ufunuo mkubwa kwa mtu yeyote nikisema kwamba udhibiti wa toleo ni sehemu muhimu sana ya maendeleo, katika timu na kibinafsi. Kulingana na vyanzo anuwai, ni salama kusema kwamba Git ndiye mwakilishi maarufu zaidi. Mfumo wa kudhibiti toleo hutoa manufaa mengi, kama vile kushiriki msimbo, kuhifadhi matoleo, kurejesha kwenye matawi yaliyotangulia, kufuatilia historia ya mradi na hifadhi rudufu. Hatutajadili kila hoja kwa undani, kwa kuwa nina hakika kwamba unaifahamu sana na unaitumia katika kazi yako ya kila siku. Lakini ikiwa sio ghafla, basi napendekeza kusitisha kusoma nakala hii na kujaza pengo hili haraka iwezekanavyo.
Thamani ya miundombinu ya otomatiki
Na hapa unaweza kuuliza swali linalofaa: "Kwa nini anatuambia kuhusu Git? Kila mtu anajua hili na huitumia kwa msimbo wa ukuzaji na kwa msimbo wa jaribio la kiotomatiki. Utakuwa sahihi kabisa, lakini katika makala hii tunazungumza kuhusu miundombinu na sehemu hii inafanya kazi kama hakikisho la sehemu ya 7: "Miundombinu kama Kanuni (IaC)". Kwetu sisi, hii ina maana kwamba miundombinu yote, ikiwa ni pamoja na majaribio, imefafanuliwa kwa njia ya msimbo, kwa hivyo tunaweza pia kutumia mifumo ya matoleo kwake na kupata manufaa sawa na ya usanidi na msimbo wa otomatiki.
Tutaangalia IaC kwa undani zaidi katika Hatua ya 7, lakini hata sasa unaweza kuanza kutumia Git ndani ya nchi kwa kuunda hazina ya ndani. Picha kubwa itapanuliwa tutakapoongeza hazina ya mbali kwenye miundombinu.
Mchoro wa hali ya sasa ya miundombinu
Viungo vya kuchunguza
Zana zinazofanana
3. Uwekaji wa vyombo (Docker)
Maelezo mafupi ya teknolojia
Ili kuonyesha jinsi uwekaji vyombo kumebadilisha sheria za mchezo, hebu turudi nyuma miongo michache iliyopita. Wakati huo, watu walinunua na kutumia mashine za seva kuendesha programu. Lakini katika hali nyingi, rasilimali zinazohitajika za kuanza hazikujulikana mapema. Matokeo yake, makampuni yalitumia pesa kwa ununuzi wa seva za gharama kubwa, zenye nguvu, lakini baadhi ya uwezo huu haukutumiwa kabisa.
Hatua inayofuata ya mageuzi ilikuwa mashine za kawaida (VMs), ambazo zilitatua tatizo la kupoteza pesa kwenye rasilimali zisizotumiwa. Teknolojia hii ilifanya iwezekane kuendesha programu kwa kujitegemea kutoka kwa kila mmoja ndani ya seva moja, ikitenga nafasi iliyotengwa kabisa. Lakini, kwa bahati mbaya, teknolojia yoyote ina vikwazo vyake. Kuendesha VM kunahitaji mfumo kamili wa uendeshaji, ambao hutumia CPU, RAM, hifadhi na, kulingana na OS, gharama za leseni zinahitajika kuzingatiwa. Sababu hizi huathiri kasi ya upakiaji na kufanya kubebeka kuwa ngumu.
Na sasa tunakuja kwenye kontena. Kwa mara nyingine tena, teknolojia hii hutatua tatizo la awali, kwani vyombo havitumii OS kamili, ambayo hufungua kiasi kikubwa cha rasilimali na hutoa ufumbuzi wa haraka na rahisi wa kubebeka.
Kwa kweli, teknolojia ya uwekaji vyombo sio mpya na ilianzishwa kwanza mwishoni mwa miaka ya 70. Katika siku hizo, utafiti mwingi, maendeleo, na majaribio yalifanywa. Lakini ni Docker iliyorekebisha teknolojia hii na kuifanya ipatikane kwa urahisi na watu wengi. Siku hizi, tunapozungumza juu ya vyombo, katika hali nyingi tunamaanisha Docker. Tunapozungumza juu ya vyombo vya Docker, tunamaanisha vyombo vya Linux. Tunaweza kutumia mifumo ya Windows na macOS kuendesha vyombo, lakini ni muhimu kuelewa kwamba katika kesi hii safu ya ziada inaonekana. Kwa mfano, Docker kwenye Mac huendesha vyombo kimyakimya ndani ya Linux VM nyepesi. Tutarudi kwenye mada hii tunapojadili kuendesha emulators za Android ndani ya vyombo, kwa hiyo hapa kuna nuance muhimu sana ambayo inahitaji kujadiliwa kwa undani zaidi.
Thamani ya miundombinu ya otomatiki
Tuligundua kuwa uwekaji wa vyombo na Docker ni nzuri. Hebu tuangalie hili katika muktadha wa otomatiki, kwa sababu kila chombo au teknolojia inahitaji kutatua tatizo. Wacha tuangazie shida dhahiri za otomatiki ya majaribio katika muktadha wa majaribio ya UI:
- idadi kubwa ya utegemezi wakati wa kufunga Selenium na haswa Apium;
- matatizo ya utangamano kati ya matoleo ya vivinjari, simulators na madereva;
- ukosefu wa nafasi ya pekee kwa vivinjari / simulators, ambayo ni muhimu sana kwa uendeshaji sambamba;
- vigumu kudhibiti na kudumisha ikiwa unahitaji kuendesha vivinjari 10, 50, 100 au hata 1000 kwa wakati mmoja.
Lakini kwa kuwa Selenium ndio zana maarufu ya kiotomatiki na Docker ndio zana maarufu zaidi ya uwekaji vyombo, haipaswi kushangaza kwamba mtu amejaribu kuzichanganya ili kuunda zana yenye nguvu ya kutatua shida zilizotajwa hapo juu. Wacha tuchunguze suluhisho kama hizo kwa undani zaidi.
Gridi ya selenium kwenye docker
Zana hii ndiyo maarufu zaidi katika ulimwengu wa Selenium kwa kuendesha vivinjari vingi kwenye mashine nyingi na kuzisimamia kutoka kwa kituo kikuu. Kuanza, unahitaji kusajili angalau sehemu 2: Hub na Node (s). Hub ni nodi kuu inayopokea maombi yote kutoka kwa majaribio na kuyasambaza kwa Nodi zinazofaa. Kwa kila Node tunaweza kusanidi usanidi maalum, kwa mfano, kwa kutaja kivinjari kinachohitajika na toleo lake. Hata hivyo, bado tunahitaji kutunza madereva ya kivinjari yanayolingana sisi wenyewe na kuziweka kwenye Nodes zinazohitajika. Kwa sababu hii, gridi ya Selenium haitumiwi kwa fomu yake safi, isipokuwa wakati tunahitaji kufanya kazi na vivinjari ambavyo haziwezi kusakinishwa kwenye Linux OS. Kwa visa vingine vyote, suluhisho linalobadilika na sahihi litakuwa kutumia picha za Docker kuendesha Kitovu cha gridi ya Selenium na Nodi. Mbinu hii hurahisisha sana usimamizi wa nodi, kwani tunaweza kuchagua picha tunayohitaji na matoleo yanayolingana ya vivinjari na viendeshi vilivyosakinishwa tayari.
Licha ya mapitio mabaya kuhusu utulivu, hasa wakati wa kuendesha idadi kubwa ya Nodes sambamba, gridi ya Selenium bado ni chombo maarufu zaidi cha kuendesha vipimo vya Selenium kwa sambamba. Ni muhimu kutambua kwamba maboresho mbalimbali na marekebisho ya chombo hiki yanaonekana mara kwa mara katika chanzo-wazi, ambacho kinapambana na vikwazo mbalimbali.
Selenoid kwa Wavuti
Zana hii ni mafanikio katika ulimwengu wa Selenium kwani inafanya kazi nje ya boksi na imerahisisha maisha ya wahandisi wengi wa otomatiki. Kwanza kabisa, hii sio marekebisho mengine ya gridi ya Selenium. Badala yake, watengenezaji waliunda toleo jipya kabisa la Selenium Hub huko Golang, ambayo, pamoja na picha za Docker nyepesi kwa vivinjari mbalimbali, ilitoa msukumo kwa maendeleo ya automatisering ya mtihani. Aidha, katika kesi ya Gridi ya Selenium, tunapaswa kuamua vivinjari vyote vinavyohitajika na matoleo yao mapema, ambayo sio tatizo wakati wa kufanya kazi na kivinjari kimoja tu. Lakini inapokuja kwa vivinjari vingi vinavyotumika, Selenoid ndio suluhisho nambari moja kutokana na kipengele chake cha 'kivinjari kinachohitajika'. Yote ambayo inahitajika kwetu ni kupakua picha zinazohitajika na vivinjari mapema na kusasisha faili ya usanidi ambayo Selenoid inaingiliana nayo. Baada ya Selenoid kupokea ombi kutoka kwa vipimo, itazindua kiotomatiki chombo kinachohitajika na kivinjari unachotaka. Jaribio likikamilika, Selenoid itarejesha kontena, na hivyo kutoa rasilimali kwa maombi ya siku zijazo. Mbinu hii huondoa kabisa shida inayojulikana ya 'uharibifu wa nodi' ambayo mara nyingi tunakutana nayo kwenye gridi ya Selenium.
Lakini, ole, Selenoid bado sio risasi ya fedha. Tulipata kipengele cha 'kivinjari kinachohitajika', lakini kipengele cha 'rasilimali zinazohitajika' bado hakipatikani. Ili kutumia Selenoid, ni lazima tuiweke kwenye maunzi halisi au kwenye VM, ambayo ina maana kwamba ni lazima tujue mapema ni rasilimali ngapi zinahitajika kutengwa. Nadhani hili sio shida kwa miradi midogo inayoendesha vivinjari 10, 20 au hata 30 sambamba. Lakini vipi ikiwa tunahitaji 100, 500, 1000 na zaidi? Haina maana kutunza na kulipia rasilimali nyingi kila wakati. Katika sehemu ya 5 na 6 ya kifungu hiki, tutajadili suluhisho zinazokuruhusu kuongeza kiwango, na hivyo kupunguza kwa kiasi kikubwa gharama za kampuni.
Selenoid kwa Android
Baada ya mafanikio ya Selenoid kama zana ya otomatiki ya wavuti, watu walitaka kitu kama hicho kwa Android. Na ikawa - Selenoid ilitolewa kwa usaidizi wa Android. Kutoka kwa mtazamo wa mtumiaji wa kiwango cha juu, kanuni ya uendeshaji ni sawa na automatisering ya mtandao. Tofauti pekee ni kwamba badala ya vyombo vya kivinjari, Selenoid huendesha vyombo vya emulator ya Android. Kwa maoni yangu, hii kwa sasa ndiyo zana yenye nguvu zaidi ya bure ya kuendesha majaribio ya Android sambamba.
Kwa kweli nisingependa kuongelea vipengele hasi vya chombo hiki, kwani ninakipenda sana. Lakini bado, kuna hasara sawa zinazotumika kwa automatisering ya mtandao na zinahusishwa na kuongeza. Mbali na hili, tunahitaji kuzungumza juu ya kizuizi kimoja zaidi ambacho kinaweza kushangaza ikiwa tunaweka chombo kwa mara ya kwanza. Ili kuendesha picha za Android, tunahitaji mashine halisi au VM iliyo na usaidizi wa uboreshaji wa kiota. Katika mwongozo wa jinsi ya, ninaonyesha jinsi ya kuwezesha hii kwenye Linux VM. Walakini, ikiwa wewe ni mtumiaji wa MacOS na unataka kupeleka Selenoid ndani ya nchi, basi hii haitawezekana kufanya majaribio ya Android. Lakini unaweza kuendesha Linux VM kila wakati na 'uboreshaji wa kiota' uliosanidiwa na kupeleka Selenoid ndani.
Mchoro wa hali ya sasa ya miundombinu
Katika muktadha wa kifungu hiki, tutaongeza zana 2 ili kuonyesha miundombinu. Hizi ni gridi ya Selenium kwa majaribio ya wavuti na Selenoid ya majaribio ya Android. Katika mafunzo ya GitHub, nitakuonyesha pia jinsi ya kutumia Selenoid kuendesha majaribio ya wavuti.
Viungo vya kuchunguza
Zana zinazofanana
- Kuna zana zingine za uwekaji vyombo, lakini Docker ndiye maarufu zaidi. Ikiwa ungependa kujaribu kitu kingine, kumbuka kwamba zana ambazo tumeshughulikia za kuendesha majaribio ya Selenium sambamba hazitafanya kazi nje ya kisanduku.
- Kama ilivyosemwa tayari, kuna marekebisho mengi ya gridi ya Selenium, kwa mfano,.
4.CI/CD
Maelezo mafupi ya teknolojia
Kitendo cha ujumuishaji unaoendelea ni maarufu sana katika maendeleo na ni sawa na mifumo ya udhibiti wa toleo. Pamoja na hayo, nahisi kuna mkanganyiko katika istilahi. Katika aya hii ningependa kuelezea marekebisho 3 ya teknolojia hii kwa mtazamo wangu. Kwenye mtandao utapata makala nyingi na tafsiri tofauti, na ni kawaida kabisa ikiwa maoni yako yanatofautiana. Jambo muhimu zaidi ni kwamba uko kwenye ukurasa mmoja na wenzako.
Kwa hiyo, kuna maneno 3: CI - Ushirikiano unaoendelea, CD - Utoaji unaoendelea na tena CD - Usambazaji unaoendelea. (Hapo chini nitatumia maneno haya kwa Kiingereza) Kila urekebishaji huongeza hatua kadhaa za ziada kwenye bomba lako la usanidi. Lakini neno kuendelea (inayoendelea) ni jambo muhimu zaidi. Katika muktadha huu, tunamaanisha kitu kinachotokea kutoka mwanzo hadi mwisho, bila kukatizwa au kuingilia kati kwa mikono. Wacha tuangalie CI & CD na CD katika muktadha huu.
- Kuendelea Kuunganishwa hii ni hatua ya awali ya mageuzi. Baada ya kuwasilisha msimbo mpya kwa seva, tunatarajia kupokea maoni ya haraka kwamba mabadiliko yetu ni sawa. Kwa kawaida, CI inajumuisha kuendesha zana za uchanganuzi wa msimbo tuli na majaribio ya API ya kitengo/ndani. Hii huturuhusu kupata maelezo kuhusu msimbo wetu ndani ya sekunde/dakika chache.
- Uwasilishaji unaoendelea ni hatua ya juu zaidi ambapo tunafanya majaribio ya ujumuishaji/UI. Walakini, katika hatua hii hatupati matokeo haraka kama vile CI. Kwanza, aina hizi za majaribio huchukua muda mrefu kukamilika. Pili, kabla ya kuzindua, ni lazima tupeleke mabadiliko yetu kwenye mazingira ya majaribio/ya jukwaa. Kwa kuongezea, ikiwa tunazungumza juu ya ukuzaji wa rununu, basi hatua ya ziada inaonekana kuunda muundo wa programu yetu.
- Kuendelea kupelekwa inachukulia kuwa tunatoa mabadiliko yetu kwa toleo la umma kiotomatiki ikiwa majaribio yote ya kukubalika yamepitishwa katika hatua za awali. Kando na hayo, baada ya hatua ya uchapishaji, unaweza kusanidi hatua mbalimbali, kama vile kufanya majaribio ya moshi kwenye uzalishaji na kukusanya vipimo vya maslahi. Usambazaji Unaoendelea unawezekana tu kwa ufikiaji mzuri kwa majaribio ya kiotomatiki. Ikiwa uingiliaji wowote wa mwongozo unahitajika, ikiwa ni pamoja na kupima, basi hii haipo tena Kuendelea (kuendelea). Kisha tunaweza kusema kwamba bomba yetu inakubaliana tu na mazoezi ya Utoaji Unaoendelea.
Thamani ya miundombinu ya otomatiki
Katika sehemu hii, ninafaa kufafanua kwamba tunapozungumza kuhusu majaribio ya kiolesura cha mwisho hadi mwisho, inamaanisha kwamba tunapaswa kupeleka mabadiliko na huduma zetu zinazohusiana na mazingira ya majaribio. Ujumuishaji Unaoendelea - mchakato hautumiki kwa kazi hii na ni lazima tuchukue tahadhari ya kutekeleza angalau mazoea ya Uwasilishaji Endelevu. Usambazaji Unaoendelea pia unaeleweka katika muktadha wa majaribio ya UI ikiwa tutayaendesha katika toleo la umma.
Na kabla ya kuangalia kielelezo cha mabadiliko ya usanifu, nataka kusema maneno machache kuhusu GitLab CI. Tofauti na zana zingine za CI/CD, GitLab hutoa hazina ya mbali na vipengele vingine vingi vya ziada. Kwa hivyo, GitLab ni zaidi ya CI. Inajumuisha usimamizi wa msimbo wa chanzo, usimamizi wa Agile, mabomba ya CI/CD, zana za kukata miti na ukusanyaji wa vipimo nje ya boksi. Usanifu wa GitLab unajumuisha Gitlab CI/CD na GitLab Runner. Hapa kuna maelezo mafupi kutoka kwa wavuti rasmi:
Gitlab CI/CD ni programu ya wavuti iliyo na API ambayo huhifadhi hali yake katika hifadhidata, kudhibiti miradi/kujenga na kutoa kiolesura cha mtumiaji. GitLab Runner ni programu ambayo michakato huunda. Inaweza kutumwa kando na kufanya kazi na GitLab CI/CD kupitia API. Kwa majaribio yanayoendelea unahitaji mfano wa Gitlab na Runner.
Mchoro wa hali ya sasa ya miundombinu
Viungo vya kuchunguza
Zana zinazofanana
- Na wengine wengi
5. Majukwaa ya wingu
Maelezo mafupi ya teknolojia
Katika sehemu hii tutazungumza juu ya mtindo maarufu unaoitwa 'mawingu ya umma'. Licha ya manufaa makubwa ambayo teknolojia ya uboreshaji na uwekaji vyombo vilivyoelezwa hapo juu hutoa, bado tunahitaji rasilimali za kompyuta. Makampuni yanunua seva za gharama kubwa au kukodisha vituo vya data, lakini katika kesi hii ni muhimu kufanya mahesabu (wakati mwingine yasiyo ya kweli) ya rasilimali ngapi tutahitaji, ikiwa tutazitumia 24/7 na kwa madhumuni gani. Kwa mfano, uzalishaji unahitaji seva inayoendesha XNUMX/XNUMX, lakini je, tunahitaji nyenzo sawa kwa majaribio nje ya saa za kazi? Pia inategemea aina ya upimaji unaofanywa. Mfano unaweza kuwa majaribio ya mzigo/mfadhaiko ambayo tunapanga kufanya wakati wa saa zisizo za kazi ili kupata matokeo siku inayofuata. Lakini kwa hakika upatikanaji wa seva XNUMX/XNUMX hauhitajiki kwa majaribio ya kiotomatiki ya mwisho hadi mwisho na haswa sio kwa mazingira ya majaribio ya mikono. Kwa hali kama hizi, itakuwa vyema kupata rasilimali nyingi kadri inavyohitajika unapohitajika, kuzitumia, na kuacha kulipa wakati hazihitajiki tena. Zaidi ya hayo, itakuwa vyema kuzipokea papo hapo kwa kubofya mara chache kipanya au kuendesha hati kadhaa. Hivi ndivyo mawingu ya umma yanatumika. Wacha tuangalie ufafanuzi:
"Wingu la umma linafafanuliwa kama huduma za kompyuta zinazotolewa na watoa huduma wengine kwenye Mtandao wa umma, na kuzifanya zipatikane kwa mtu yeyote anayetaka kuzitumia au kuzinunua. Zinaweza kuwa za bure au kuuzwa inapohitajika, kuruhusu wateja kulipa tu kwa kila matumizi kwa mizunguko ya CPU, hifadhi, au kipimo data wanachotumia."
Kuna maoni kwamba mawingu ya umma ni ghali. Lakini wazo lao kuu ni kupunguza gharama za kampuni. Kama ilivyoelezwa hapo awali, mawingu ya umma hukuruhusu kupata rasilimali kwa mahitaji na kulipa tu kwa wakati unaotumia. Pia, wakati mwingine tunasahau kuwa wafanyikazi hupokea mishahara, na wataalam pia ni rasilimali ya gharama kubwa. Inapaswa kuzingatiwa kuwa mawingu ya umma hufanya usaidizi wa miundombinu iwe rahisi zaidi, ambayo inaruhusu wahandisi kuzingatia kazi muhimu zaidi.
Thamani ya miundombinu ya otomatiki
Je, ni nyenzo gani mahususi tunazohitaji kwa ajili ya majaribio ya kiolesura cha mwisho hadi mwisho? Kimsingi hizi ni mashine au nguzo pepe (tutazungumza kuhusu Kubernetes katika sehemu inayofuata) ya kuendesha vivinjari na viigizaji. Kadiri vivinjari na viigizaji vingi tunavyotaka kufanya wakati huo huo, ndivyo CPU na kumbukumbu inavyohitajika zaidi na ndivyo tunavyolazimika kulipia pesa nyingi zaidi. Kwa hivyo, mawingu ya umma katika muktadha wa uwekaji kiotomatiki wa majaribio huturuhusu kuendesha idadi kubwa (100, 200, 1000...) ya vivinjari/viigaji tunapohitaji, kupata matokeo ya majaribio haraka iwezekanavyo na kuacha kulipia rasilimali nyingi sana. nguvu.
Watoa huduma za wingu maarufu zaidi ni Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Mwongozo wa jinsi ya kutoa mifano ya jinsi ya kutumia GCP, lakini kwa ujumla haijalishi unatumia nini kwa kazi za otomatiki. Zote hutoa takriban utendakazi sawa. Kwa kawaida, ili kuchagua mtoa huduma, usimamizi huzingatia mahitaji ya miundombinu yote ya kampuni na biashara, ambayo ni zaidi ya upeo wa makala haya. Kwa wahandisi wa otomatiki, itapendeza zaidi kulinganisha matumizi ya watoa huduma za wingu na matumizi ya majukwaa ya wingu mahususi kwa madhumuni ya majaribio, kama vile Sauce Labs, BrowserStack, BitBar, na kadhalika. Basi tuifanye pia! Kwa maoni yangu, Sauce Labs ni shamba maarufu zaidi la kupima wingu, ndiyo sababu niliitumia kwa kulinganisha.
GCP vs Sauce Labs kwa madhumuni ya otomatiki:
Hebu tufikirie kuwa tunahitaji kufanya majaribio 8 ya wavuti na majaribio 8 ya Android kwa wakati mmoja. Kwa hili tutatumia GCP na kuendesha mashine 2 pepe na Selenoid. Kwenye ya kwanza tutainua vyombo 8 na vivinjari. Kwenye pili kuna vyombo 8 vilivyo na emulators. Wacha tuangalie bei:
Ili kuendesha chombo kimoja na Chrome, tunahitaji n1-kiwango-1 gari. Kwa upande wa Android itakuwa n1-kiwango-4 kwa emulator moja. Kwa kweli, njia rahisi na ya bei nafuu zaidi ni kuweka maadili maalum ya mtumiaji kwa CPU/Kumbukumbu, lakini kwa sasa hii si muhimu kwa kulinganisha na Sauce Labs.
Na hapa kuna ushuru wa kutumia Sauce Labs:
Ninaamini tayari umegundua tofauti, lakini bado nitatoa jedwali na mahesabu ya kazi yetu:
Rasilimali zinazohitajika
Kila mwezi
Saa za kazi(8 asubuhi - 8 mchana)
Saa za kazi+ Inayowezekana
GCP kwa Wavuti
n1-kiwango-1 x 8 = n1-kiwango-8
$194.18
Siku 23 * 12h * 0.38 = $ 104.88
Siku 23 * 12h * 0.08 = $ 22.08
Maabara ya Michuzi kwa Wavuti
Majaribio sambamba ya Cloud8
$1.559
-
-
GCP kwa Android
n1-kiwango-4 x 8: n1-kiwango-16
$776.72
Siku 23 * 12h * 1.52 = $ 419.52
Siku 23 * 12h * 0.32 = $ 88.32
Maabara ya Mchuzi kwa Android
Majaribio ya sambamba ya Kifaa cha Wingu 8
$1.999
-
-
Kama unavyoona, tofauti ya gharama ni kubwa, haswa ikiwa unafanya majaribio katika kipindi cha saa kumi na mbili za kazi. Lakini unaweza kupunguza gharama hata zaidi ikiwa unatumia mashine zinazowezekana. Ni nini?
VM inayoweza kutekelezwa ni mfano ambao unaweza kuunda na kuendesha kwa bei ya muchower kuliko hali ya kawaida. Walakini, Injini ya Kuhesabu inaweza kusitisha (kuweka mapema) matukio haya ikiwa inahitaji ufikiaji wa rasilimali hizo kwa kazi zingine. Matukio yanayowezekana ni uwezo wa ziada wa Injini ya Kukokotoa, kwa hivyo upatikanaji wao hutofautiana kulingana na matumizi.
Ikiwa programu zako hazihimili makosa na zinaweza kustahimili vikwazo vinavyowezekana, basi matukio yanayoweza kuepukika yanaweza kupunguza gharama zako za Compute Engine kwa kiasi kikubwa. Kwa mfano, kazi za usindikaji batch zinaweza kufanya kazi katika hali zinazoweza kutekelezwa. Ikiwa baadhi ya matukio hayo yataisha wakati wa usindikaji, kazi hupungua lakini haina kuacha kabisa. Matukio yanayowezekana hukamilisha kazi zako za kuchakata bechi bila kuweka mzigo wa ziada kwenye matukio yako yaliyopo na bila kukuhitaji ulipe bei kamili kwa matukio ya ziada ya kawaida.
Na bado haijaisha! Kwa kweli, nina hakika hakuna mtu anayeendesha vipimo kwa masaa 12 bila kupumzika. Na ikiwa ni hivyo, basi unaweza kuanza moja kwa moja na kusimamisha mashine za kawaida wakati hazihitajiki. Muda halisi wa matumizi unaweza kupunguzwa hadi saa 6 kwa siku. Kisha malipo katika muktadha wa kazi yetu yatapungua hadi $11 kwa mwezi kwa vivinjari 8. Je, hii si ya ajabu? Lakini kwa mashine zinazoweza kuepukika lazima tuwe waangalifu na tujitayarishe kwa kukatizwa na kukosekana kwa utulivu, ingawa hali hizi zinaweza kutolewa na kushughulikiwa katika programu. Ni thamani yake!
Lakini sisemi kamwe 'usitumie mashamba ya majaribio ya wingu'. Wana idadi ya faida. Kwanza kabisa, hii sio tu mashine ya kawaida, lakini suluhisho kamili la otomatiki la majaribio na seti ya utendaji nje ya boksi: ufikiaji wa mbali, kumbukumbu, picha za skrini, kurekodi video, vivinjari anuwai na vifaa vya rununu vya kawaida. Katika hali nyingi, hii inaweza kuwa mbadala muhimu ya chic. Majukwaa ya majaribio ni muhimu sana kwa otomatiki ya IOS, wakati mawingu ya umma yanaweza kutoa mifumo ya Linux/Windows pekee. Lakini tutazungumzia kuhusu iOS katika makala zifuatazo. Ninapendekeza daima kuangalia hali hiyo na kuanzia kazi: katika baadhi ya matukio ni ya bei nafuu na yenye ufanisi zaidi kutumia mawingu ya umma, na kwa wengine majukwaa ya mtihani ni dhahiri ya thamani ya fedha zilizotumiwa.
Mchoro wa hali ya sasa ya miundombinu
Viungo vya kuchunguza
Zana zinazofanana:
6. Okestration
Maelezo mafupi ya teknolojia
Nina habari njema - tuko karibu mwisho wa makala! Kwa sasa, miundombinu yetu ya otomatiki ina majaribio ya wavuti na Android, ambayo tunapitia GitLab CI sambamba, kwa kutumia zana zinazoweza kutumia Docker: gridi ya selenium na Selenoid. Zaidi ya hayo, tunatumia mashine pepe zilizoundwa kupitia GCP kupangisha vyombo vyenye vivinjari na viigizaji. Ili kupunguza gharama, tunaanzisha mashine hizi kwa mahitaji tu na kuzisimamisha wakati majaribio hayafanyiki. Je, kuna kitu kingine chochote ambacho kinaweza kuboresha miundombinu yetu? Jibu ni ndiyo! Kutana na Kubernetes (K8s)!
Kwanza, hebu tuangalie jinsi maneno orchestration, nguzo, na Kubernetes yanahusiana. Katika kiwango cha juu, orchestration ni mfumo unaopeleka na kusimamia programu. Kwa otomatiki ya majaribio, programu zilizo na kontena ni gridi ya Selenium na Selenoid. Docker na K8 zinakamilishana. Ya kwanza inatumika kwa kupeleka maombi, ya pili kwa okestration. Kwa upande wake, K8s ni nguzo. Kazi ya nguzo ni kutumia VM kama Nodi, ambayo hukuruhusu kusakinisha utendakazi, programu na huduma mbalimbali ndani ya seva moja (nguzo). Ikiwa Nodi zozote zitashindwa, Nodi zingine zitachukua, ambayo inahakikisha utendakazi usioingiliwa wa programu yetu. Kwa kuongeza hii, K8s ina utendaji muhimu unaohusiana na kuongeza, shukrani ambayo sisi hupata moja kwa moja kiasi bora cha rasilimali kulingana na mzigo na mipaka iliyowekwa.
Kwa kweli, kupeleka Kubernetes kwa mikono kutoka mwanzo sio kazi ndogo hata kidogo. Nitaacha kiunga cha mwongozo maarufu wa jinsi ya "Kubernetes Njia Ngumu" na ikiwa una nia, unaweza kuifanyia mazoezi. Lakini, kwa bahati nzuri, kuna njia na zana mbadala. Njia rahisi ni kutumia Google Kubernetes Engine (GKE) katika GCP, ambayo itakuruhusu kupata nguzo iliyotengenezwa tayari kwa mibofyo michache. Ninapendekeza kutumia mbinu hii ili kuanza kujifunza, kwani itakuruhusu kuzingatia kujifunza jinsi ya kutumia K8 kwa kazi zako badala ya kujifunza jinsi vijenzi vya ndani vinapaswa kuunganishwa.
Thamani ya miundombinu ya otomatiki
Hebu tuangalie vipengele vichache muhimu ambavyo K8s hutoa:
- uwekaji wa programu: kutumia nguzo ya nodi nyingi badala ya VM;
- kuongeza nguvu: hupunguza gharama ya rasilimali zinazotumika tu kwa mahitaji;
- kujiponya: urejesho wa moja kwa moja wa maganda (kama matokeo ya ambayo vyombo pia hurejeshwa);
- uwasilishaji wa sasisho na urejeshaji wa mabadiliko bila wakati wa chini: zana za kusasisha, vivinjari na viigizaji hakatishi kazi ya watumiaji wa sasa.
Lakini K8 bado si risasi ya fedha. Ili kuelewa faida na mapungufu yote katika muktadha wa zana tunazozingatia (gridi ya Selenium, Selenoid), tutajadili kwa ufupi muundo wa K8s. Nguzo ina aina mbili za Nodi: Nodi Kuu na Nodi za Wafanyakazi. Nodi za Mwalimu zinawajibika kwa usimamizi, upelekaji na upangaji maamuzi. Nodi za wafanyikazi ni mahali ambapo maombi yanazinduliwa. Nodi pia zina mazingira ya kukimbia kwa chombo. Kwa upande wetu, hii ni Docker, ambayo inawajibika kwa shughuli zinazohusiana na kontena. Lakini pia kuna suluhisho mbadala, kwa mfano. Ni muhimu kuelewa kwamba kuongeza au kujiponya hakuhusu moja kwa moja kwenye vyombo. Hii inatekelezwa kwa kuongeza/kupunguza idadi ya maganda, ambayo nayo huwa na vyombo (kwa kawaida chombo kimoja kwa kila ganda, lakini kulingana na kazi kunaweza kuwa na zaidi). Uongozi wa hali ya juu unajumuisha nodi za wafanyikazi, ndani yake kuna maganda, ambayo ndani yake vyombo huinuliwa.
Kipengele cha kuongeza ni muhimu na kinaweza kutumika kwa nodi zote mbili ndani ya nodi ya nguzo na maganda ndani ya nodi. Kuna aina 2 za upanuzi zinazotumika kwa nodi na maganda yote. Aina ya kwanza ni ya mlalo - upanuzi hutokea kwa kuongeza idadi ya nodi/maganda. Aina hii ni bora zaidi. Aina ya pili ni, ipasavyo, wima. Kuongeza unafanywa kwa kuongeza ukubwa wa nodi / maganda, na sio idadi yao.
Sasa hebu tuangalie zana zetu katika muktadha wa maneno hapo juu.
Gridi ya selenium
Kama tulivyosema hapo awali, gridi ya Selenium ni zana maarufu sana, na haishangazi kuwa imewekwa kwenye kontena. Kwa hivyo, haishangazi kwamba gridi ya Selenium inaweza kutumika katika K8s. Mfano wa jinsi ya kufanya hivyo unaweza kupatikana katika hazina rasmi ya K8s. Kama kawaida, ninaambatisha viungo mwishoni mwa sehemu. Kwa kuongeza, mwongozo wa jinsi-ya unaonyesha jinsi ya kufanya hivyo katika Terraform. Pia kuna maagizo ya jinsi ya kuongeza idadi ya maganda ambayo yana vyombo vya kivinjari. Lakini kazi ya kuongeza moja kwa moja katika muktadha wa K8s bado sio kazi dhahiri kabisa. Nilipoanza kujifunza, sikupata mwongozo au mapendekezo yoyote yanayofaa. Baada ya masomo na majaribio kadhaa kwa usaidizi wa timu ya DevOps, tulichagua mbinu ya kuinua vyombo na vivinjari muhimu ndani ya pod moja, ambayo iko ndani ya nodi moja ya mfanyakazi. Njia hii inaruhusu sisi kutumia mkakati wa kuongeza usawa wa nodi kwa kuongeza idadi yao. Natumaini kwamba hii itabadilika katika siku zijazo na tutaona maelezo zaidi na zaidi ya mbinu bora na ufumbuzi tayari, hasa baada ya kutolewa kwa gridi ya Selenium 4 na usanifu wa ndani uliobadilishwa.
Selenoid:
Usambazaji wa Selenoid katika K8s kwa sasa ndio shida kubwa zaidi. Haziendani. Kinadharia, tunaweza kuinua kontena ya Selenoid ndani ya ganda, lakini Selenoid inapoanza kuzindua vyombo vilivyo na vivinjari, bado vitakuwa ndani ya ganda moja. Hii hufanya kuongeza kuwa haiwezekani na, kwa sababu hiyo, kazi ya Selenoid ndani ya nguzo haitatofautiana na kazi ndani ya mashine ya kawaida. Mwisho wa hadithi.
Moon:
Kujua kizuizi hiki wakati wa kufanya kazi na Selenoid, watengenezaji walitoa zana yenye nguvu zaidi inayoitwa Mwezi. Chombo hiki kiliundwa awali kufanya kazi na Kubernetes na, kwa sababu hiyo, kipengele cha kupima kiotomatiki kinaweza na kinapaswa kutumika. Aidha, ningesema kwamba kwa sasa ni pekee zana katika ulimwengu wa Selenium, ambayo ina msaada wa nguzo ya K8s nje ya boksi (haipatikani tena, tazama zana inayofuata ) Vipengele muhimu vya Mwezi vinavyotoa usaidizi huu ni:
Bila utaifa kabisa. Selenoid huhifadhi maelezo ya kumbukumbu kuhusu vipindi vya kivinjari vinavyoendesha kwa sasa. Ikiwa kwa sababu fulani mchakato wake unaanguka - basi vipindi vyote vinavyoendesha vinapotea. Mwezi kinyume chake hauna hali ya ndani na unaweza kuigwa kwenye vituo vya data. Vipindi vya kivinjari hubaki hai hata kama nakala moja au zaidi zitapungua.
Kwa hiyo, Mwezi ni suluhisho kubwa, lakini kuna tatizo moja: sio bure. Bei inategemea idadi ya vikao. Unaweza tu kuendesha vipindi 0-4 bila malipo, ambayo sio muhimu sana. Lakini, kuanzia kipindi cha tano, utalazimika kulipa $5 kwa kila moja. Hali inaweza kutofautiana kutoka kwa kampuni hadi kampuni, lakini kwa upande wetu, kutumia Mwezi haina maana. Kama nilivyoelezea hapo juu, tunaweza kuendesha VM na Gridi ya Selenium kwa mahitaji au kuongeza idadi ya Nodi kwenye nguzo. Kwa takriban bomba moja, tunazindua vivinjari 500 na kusimamisha nyenzo zote baada ya majaribio kukamilika. Ikiwa tungetumia Mwezi, tungelazimika kulipa 500 x 5 = $2500 za ziada kwa mwezi, bila kujali ni mara ngapi tunafanya majaribio. Tena, sisemi usitumie Mwezi. Kwa kazi zako, hili linaweza kuwa suluhisho la lazima, kwa mfano, ikiwa una miradi/timu nyingi katika shirika lako na unahitaji nguzo kubwa ya kawaida kwa kila mtu. Kama kawaida, ninaacha kiunga mwishoni na kupendekeza kufanya mahesabu yote muhimu katika muktadha wa kazi yako.
Callisto: (Makini! Hii haiko katika nakala ya asili na iko tu katika tafsiri ya Kirusi)
Kama nilivyosema, Selenium ni zana maarufu sana, na uwanja wa IT unakua haraka sana. Nilipokuwa nikifanya kazi ya kutafsiri, chombo kipya cha kuahidi kiitwacho Callisto kilionekana kwenye wavuti (hello Cypress na wauaji wengine wa Selenium). Inafanya kazi asili na K8s na hukuruhusu kuendesha kontena za Selenoid kwenye maganda, zinazosambazwa kote kwenye Nodi. Kila kitu hufanya kazi nje ya boksi, pamoja na kuongeza kasi kiotomatiki. Ajabu, lakini inahitaji kupimwa. Tayari nimeweza kupeleka zana hii na kuendesha majaribio kadhaa. Lakini ni mapema sana kufanya hitimisho, baada ya kupokea matokeo kwa umbali mrefu, labda nitafanya mapitio katika makala zijazo. Kwa sasa ninaacha viungo vya utafiti wa kujitegemea pekee.
Mchoro wa hali ya sasa ya miundombinu
Viungo vya kuchunguza
Zana zinazofanana
7. Miundombinu kama Kanuni (IaC)
Maelezo mafupi ya teknolojia
Na sasa tunakuja kwenye sehemu ya mwisho. Kwa kawaida, teknolojia hii na kazi zinazohusiana sio wajibu wa wahandisi wa automatisering. Na kuna sababu za hii. Kwanza, katika mashirika mengi, masuala ya miundombinu yako chini ya udhibiti wa idara ya DevOps na timu za maendeleo hazijali kabisa ni nini hufanya bomba lifanye kazi na jinsi kila kitu kinachohusiana nalo kinahitaji kuungwa mkono. Pili, tuseme ukweli, mazoezi ya Miundombinu kama Kanuni (IaC) bado hayajapitishwa katika makampuni mengi. Lakini kwa hakika imekuwa mwenendo maarufu na ni muhimu kujaribu kuhusika katika taratibu, mbinu na zana zinazohusiana nayo. Au angalau usasishe.
Wacha tuanze na motisha ya kutumia njia hii. Tayari tumejadili kwamba ili kufanya majaribio katika GitlabCI, tutahitaji angalau rasilimali ili kuendesha Gitlab Runner. Na ili kuendesha vyombo na vivinjari/viigaji, tunahitaji kuhifadhi VM au nguzo. Mbali na rasilimali za kupima, tunahitaji kiasi kikubwa cha uwezo wa kusaidia maendeleo, uwekaji, mazingira ya uzalishaji, ambayo pia yanajumuisha hifadhidata, ratiba za kiotomatiki, usanidi wa mtandao, visawazishaji vya mizigo, haki za mtumiaji, na kadhalika. Suala kuu ni juhudi zinazohitajika kuunga mkono yote. Kuna njia kadhaa tunaweza kufanya mabadiliko na kusambaza masasisho. Kwa mfano, katika muktadha wa GCP, tunaweza kutumia kiweko cha UI kwenye kivinjari na kufanya vitendo vyote kwa kubofya vitufe. Njia mbadala itakuwa kutumia simu za API kuingiliana na huluki za wingu, au kutumia matumizi ya mstari wa amri ya gcloud kutekeleza upotoshaji unaotaka. Lakini kwa idadi kubwa sana ya vyombo tofauti na vipengele vya miundombinu, inakuwa vigumu au hata haiwezekani kufanya shughuli zote kwa mikono. Aidha, vitendo hivi vyote vya mwongozo haviwezi kudhibitiwa. Hatuwezi kuziwasilisha ili zikaguliwe kabla ya kutekelezwa, kutumia mfumo wa udhibiti wa toleo, na kurudisha nyuma kwa haraka mabadiliko yaliyosababisha tukio. Ili kutatua matatizo hayo, wahandisi waliunda na kuunda maandishi ya bash / shell moja kwa moja, ambayo si bora zaidi kuliko njia za awali, kwa kuwa si rahisi sana kusoma haraka, kuelewa, kudumisha na kurekebisha kwa mtindo wa utaratibu.
Katika nakala hii na jinsi ya mwongozo, ninatumia zana 2 zinazohusiana na mazoezi ya IaC. Hizi ni Terraform na Ansible. Watu wengine wanaamini kuwa haina maana kuzitumia kwa wakati mmoja, kwani utendaji wao ni sawa na unaweza kubadilishana. Lakini ukweli ni kwamba mwanzoni wanapewa kazi tofauti kabisa. Na ukweli kwamba zana hizi zinafaa kukamilishana ulithibitishwa katika wasilisho la pamoja na wasanidi wanaowakilisha HashiCorp na RedHat. Tofauti ya kimawazo ni kwamba Terraform ni chombo cha utoaji cha kusimamia seva zenyewe. Wakati Ansible ni zana ya usimamizi wa usanidi ambayo kazi yake ni kusakinisha, kusanidi na kudhibiti programu kwenye seva hizi.
Kipengele kingine muhimu cha kutofautisha cha zana hizi ni mtindo wa kuweka coding. Tofauti na bash na Ansible, Terraform hutumia mtindo wa kutangaza kulingana na maelezo ya hali ya mwisho inayotarajiwa kupatikana kutokana na utekelezaji. Kwa mfano, ikiwa tutaunda VM 10 na kutumia mabadiliko kupitia Terraform, basi tutapata VM 10. Ikiwa tutaendesha hati tena, hakuna kitakachofanyika kwa kuwa tayari tuna VM 10, na Terraform inajua kuhusu hili kwa sababu huhifadhi hali ya sasa ya miundombinu katika faili ya serikali. Lakini Ansible hutumia mbinu ya kiutaratibu na, ikiwa utaiuliza kuunda VM 10, basi kwenye uzinduzi wa kwanza tutapata VM 10, sawa na Terraform. Lakini baada ya kuanza tena tutakuwa na VM 20. Hii ndiyo tofauti muhimu. Kwa mtindo wa utaratibu, hatuhifadhi hali ya sasa na kuelezea tu mlolongo wa hatua ambazo lazima zifanyike. Bila shaka, tunaweza kushughulikia hali mbalimbali, kuongeza hundi kadhaa kwa kuwepo kwa rasilimali na hali ya sasa, lakini hakuna maana katika kupoteza muda wetu na kuweka jitihada katika kudhibiti mantiki hii. Kwa kuongeza, hii huongeza hatari ya kufanya makosa.
Kwa muhtasari wa yote yaliyo hapo juu, tunaweza kuhitimisha kuwa Terraform na nukuu tangazo ni zana inayofaa zaidi kwa utoaji wa seva. Lakini ni bora kukabidhi kazi ya usimamizi wa usanidi kwa Ansible. Kwa hiyo nje ya njia, wacha tuangalie kesi za utumiaji katika muktadha wa otomatiki.
Thamani ya miundombinu ya otomatiki
Jambo la muhimu tu kuelewa hapa ni kwamba miundombinu ya otomatiki ya majaribio inapaswa kuzingatiwa kama sehemu ya miundombinu yote ya kampuni. Hii ina maana kwamba mazoea yote ya IaC lazima yatumike kimataifa kwa rasilimali za shirika zima. Nani anawajibika kwa hili inategemea michakato yako. Timu ya DevOps ina uzoefu zaidi katika masuala haya, wanaona picha nzima ya kile kinachotokea. Hata hivyo, wahandisi wa QA wanahusika zaidi katika mchakato wa kujenga automatisering na muundo wa bomba, ambayo huwawezesha kuona vizuri mabadiliko yote yanayohitajika na fursa za kuboresha. Chaguo bora ni kufanya kazi pamoja, kubadilishana ujuzi na mawazo ili kufikia matokeo yanayotarajiwa.
Hapa kuna mifano michache ya kutumia Terraform na Ansible katika muktadha wa otomatiki wa majaribio na zana tulizojadili hapo awali:
1. Eleza sifa na vigezo muhimu vya VM na makundi kwa kutumia Terraform.
2. Kwa kutumia Ansible, sakinisha zana zinazohitajika kwa ajili ya majaribio: docker, Selenoid, Selenium Gridi na upakue matoleo yanayohitajika ya vivinjari/emulators.
3. Kwa kutumia Terraform, eleza sifa za VM ambayo GitLab Runner itazinduliwa.
4. Sakinisha GitLab Runner na zana muhimu zinazoambatana kwa kutumia Ansible, weka mipangilio na usanidi.
Mchoro wa hali ya sasa ya miundombinu
Viungo vya kuchunguza:
Zana zinazofanana
Hebu tufanye muhtasari!
Hatua ya
Teknolojia
Zana
Thamani ya miundombinu ya otomatiki
1
Uendeshaji wa ndani
Node.js, Selenium, Apium
- Zana maarufu zaidi za wavuti na rununu
- Inasaidia lugha na majukwaa mengi (pamoja na Node.js)
2
Mifumo ya kudhibiti toleo
kwenda
- Faida sawa na msimbo wa usanidi
3
Kuweka vyombo
Docker, gridi ya Selenium, Selenoid (Mtandao, Android)
- Kuendesha majaribio kwa sambamba
- Mazingira yaliyotengwa
- Maboresho rahisi na yanayonyumbulika
- Inasimamisha rasilimali ambazo hazijatumika
- Rahisi kuanzisha
4
CI/CD
Gitlab CI
- Inajaribu sehemu ya bomba
- Maoni ya Haraka
- Mwonekano wa kampuni/timu nzima
5
Majukwaa ya wingu
Jukwaa la Wingu la Google
- Rasilimali kwa mahitaji (tunalipa inapohitajika tu)
- Rahisi kusimamia na kusasisha
- Kuonekana na udhibiti wa rasilimali zote
6
Uchezaji
Mabernet
Katika muktadha wa vyombo vilivyo na vivinjari/emulator ndani ya maganda:
- Kuongeza/kuongeza otomatiki
- Kujiponya
- Masasisho na urejeshaji nyuma bila kukatizwa
7
Miundombinu kama kanuni (IaC)
Terraform, Ansible
- Faida sawa na miundombinu ya maendeleo
- Faida zote za toleo la msimbo
- Rahisi kufanya mabadiliko na kudumisha
- Imejiendesha kikamilifu
Michoro ya ramani ya akili: mageuzi ya miundombinu
hatua ya 1: ya ndani
Hatua ya 2: VCS
Hatua ya 3: Kuweka vyombo
hatua ya 4: CI/CD
hatua ya 5: Majukwaa ya Wingu
hatua ya 6: Ochestration
hatua ya 7: IaC
Nini hapo?
Kwa hiyo, huu ndio mwisho wa makala. Lakini kwa kumalizia, ningependa kuanzisha makubaliano na wewe.
Kutoka upande wako
Kama nilivyosema mwanzoni, ningependa makala hiyo iwe ya matumizi ya vitendo na kukusaidia kutumia ujuzi unaopatikana katika kazi halisi. Naongeza tena.
Lakini hata baada ya hayo, usisimame, fanya mazoezi, soma viungo na vitabu vinavyofaa, ujue jinsi inavyofanya kazi katika kampuni yako, pata maeneo ambayo yanaweza kuboreshwa na ushiriki ndani yake. Bahati njema!
Kutoka upande wangu
Kutoka kwa kichwa unaweza kuona kwamba hii ilikuwa sehemu ya kwanza tu. Licha ya ukweli kwamba iligeuka kuwa kubwa sana, mada muhimu bado hayajashughulikiwa hapa. Katika sehemu ya pili, ninapanga kuangalia miundombinu ya otomatiki katika muktadha wa IOS. Kwa sababu ya vizuizi vya Apple vya kuendesha simulators za iOS tu kwenye mifumo ya macOS, anuwai ya suluhisho zetu zimepunguzwa. Kwa mfano, hatuwezi kutumia Docker kuendesha kiigaji au mawingu ya umma kuendesha mashine pepe. Lakini hii haina maana kwamba hakuna njia nyingine mbadala. Nitajaribu kukuweka hadi sasa na ufumbuzi wa juu na zana za kisasa!
Pia, sijataja mada kubwa kabisa zinazohusiana na ufuatiliaji. Katika Sehemu ya 3, nitaangalia zana maarufu zaidi za ufuatiliaji wa miundombinu na data na metriki za kuzingatia.
Na hatimaye. Katika siku zijazo, ninapanga kutoa kozi ya video juu ya ujenzi wa miundombinu ya majaribio na zana maarufu. Hivi sasa, kuna kozi na mihadhara kadhaa kwenye DevOps kwenye Mtandao, lakini nyenzo zote zinawasilishwa katika muktadha wa maendeleo, sio otomatiki ya majaribio. Kuhusu suala hili, ninahitaji maoni kuhusu kama kozi kama hiyo itakuwa ya kuvutia na yenye thamani kwa jumuiya ya wajaribu na wahandisi wa otomatiki. Asante!
Chanzo: mapenzi.com