Bahagi 1: Web/Android
Nota: ang artikulong ito ay pagsasalin sa Russian ng orihinal na artikulo Gayunpaman, ang lahat ng mga guhit, link, quote at termino ay pinapanatili sa orihinal na wika upang maiwasan ang pagbaluktot ng kahulugan kapag isinalin sa Russian. Nais kong masaya ka sa pag-aaral!
Sa kasalukuyan, ang espesyalidad ng DevOps ay isa sa pinaka-in demand sa industriya ng IT. Kung magbubukas ka ng mga sikat na site sa paghahanap ng trabaho at mag-filter ayon sa suweldo, makikita mo na ang mga trabahong nauugnay sa DevOps ay nasa tuktok ng listahan. Gayunpaman, mahalagang maunawaan na ito ay pangunahing tumutukoy sa isang 'Senior' na posisyon, na nagpapahiwatig na ang kandidato ay may mataas na antas ng kasanayan, kaalaman sa teknolohiya at mga kasangkapan. Ito rin ay may mataas na antas ng responsibilidad na nauugnay sa walang patid na operasyon ng produksyon. Gayunpaman, sinimulan naming kalimutan kung ano ang DevOps. Noong una, hindi ito anumang partikular na tao o departamento. Kung hahanapin natin ang mga depinisyon ng terminong ito, makakakita tayo ng maraming maganda at wastong pangngalan, tulad ng metodolohiya, kasanayan, pilosopiyang kultural, grupo ng mga konsepto, at iba pa.
Ang aking espesyalisasyon ay isang test automation engineer (QA automation engineer), ngunit naniniwala ako na hindi ito dapat iugnay lamang sa pagsusulat ng mga auto-test o pagbuo ng arkitektura ng framework ng pagsubok. Sa 2020, ang kaalaman sa imprastraktura ng automation ay mahalaga din. Nagbibigay-daan ito sa iyo na ayusin ang proseso ng automation nang mag-isa, mula sa pagpapatakbo ng mga pagsubok hanggang sa pagbibigay ng mga resulta sa lahat ng stakeholder alinsunod sa iyong mga layunin. Bilang resulta, ang mga kasanayan sa DevOps ay kinakailangan upang magawa ang trabaho. At lahat ng ito ay mabuti, ngunit, sa kasamaang-palad, may problema (spoiler: sinusubukan ng artikulong ito na gawing simple ang problemang ito). Ang punto ay mahirap ang DevOps. At ito ay malinaw, dahil ang mga kumpanya ay hindi magbabayad ng malaki para sa isang bagay na madaling gawin... Sa mundo ng DevOps, mayroong isang malaking bilang ng mga tool, tuntunin, at kasanayan na kailangang ma-master. Ito ay lalong mahirap sa simula ng isang karera at depende sa naipon na teknikal na karanasan.
Pinagmulan:
Dito marahil ay tatapusin natin ang panimulang bahagi at tututukan ang layunin ng artikulong ito.
Tungkol saan ang artikulong ito?
Sa artikulong ito, ibabahagi ko ang aking karanasan sa pagbuo ng isang pagsubok na imprastraktura ng automation. Mayroong maraming mga mapagkukunan ng impormasyon sa Internet tungkol sa iba't ibang mga tool at kung paano gamitin ang mga ito, ngunit nais kong tingnan ang mga ito sa konteksto ng automation. Naniniwala ako na maraming mga inhinyero ng automation ang pamilyar sa sitwasyon kung saan walang sinuman maliban sa iyo ang nagpapatakbo ng mga binuo na pagsubok o nagmamalasakit sa pagpapanatili sa kanila. Bilang resulta, luma na ang mga pagsusulit at kailangan mong gumugol ng oras sa pag-update sa kanila. Muli, sa simula ng isang karera, ito ay maaaring maging isang mahirap na gawain: matalinong pagpapasya kung aling mga tool ang dapat makatulong na maalis ang isang partikular na problema, kung paano piliin, i-configure at panatilihin ang mga ito. Ang ilang mga tester ay bumaling sa DevOps (mga tao) para sa tulong at, maging tapat tayo, gumagana ang diskarteng ito. Sa maraming kaso, maaaring ito lang ang opsyon dahil wala kaming visibility sa lahat ng dependencies. Ngunit tulad ng alam natin, ang mga DevOps ay masyadong abala, dahil kailangan nilang isipin ang tungkol sa buong imprastraktura ng kumpanya, pag-deploy, pagsubaybay, microservice at iba pang katulad na mga gawain depende sa organisasyon/pangkat. Gaya ng karaniwang nangyayari, hindi priyoridad ang automation. Sa ganoong kaso, dapat nating subukang gawin ang lahat ng posible sa ating bahagi mula simula hanggang wakas. Babawasan nito ang mga dependency, pabilisin ang daloy ng trabaho, pagbutihin ang aming mga kasanayan at magbibigay-daan sa amin na makita ang mas malaking larawan ng kung ano ang nangyayari.
Ang artikulo ay nagpapakita ng pinakasikat at sikat na mga tool at nagpapakita kung paano gamitin ang mga ito upang bumuo ng isang automation na imprastraktura nang sunud-sunod. Ang bawat pangkat ay kinakatawan ng mga tool na nasubok sa pamamagitan ng personal na karanasan. Ngunit hindi iyon nangangahulugan na kailangan mong gumamit ng parehong bagay. Ang mga tool mismo ay hindi mahalaga, lumilitaw ang mga ito at nagiging lipas na. Ang aming gawain sa engineering ay unawain ang mga pangunahing prinsipyo: kung bakit kailangan namin ang pangkat ng mga tool na ito at kung anong mga problema sa trabaho ang maaari naming lutasin sa kanilang tulong. Kaya naman sa dulo ng bawat seksyon ay nag-iiwan ako ng mga link sa mga katulad na tool na maaaring gamitin sa iyong organisasyon.
Ano ang wala sa artikulong ito
Uulitin ko muli na ang artikulo ay hindi tungkol sa mga partikular na tool, kaya walang mga pagsingit ng code mula sa dokumentasyon at mga paglalarawan ng mga partikular na utos. Ngunit sa dulo ng bawat seksyon ay nag-iiwan ako ng mga link para sa detalyadong pag-aaral.
Ginagawa ito dahil:
- ang materyal na ito ay napakadaling mahanap sa iba't ibang mga mapagkukunan (dokumentasyon, mga libro, mga kurso sa video);
- kung magsisimula tayong lumalim, kakailanganin nating magsulat ng 10, 20, 30 bahagi ng artikulong ito (habang ang mga plano ay 2-3);
- Hindi ko lang gustong mag-aksaya ng oras dahil baka gusto mong gumamit ng iba pang mga tool upang makamit ang parehong mga layunin.
Pagsasanay
Gusto ko talagang maging kapaki-pakinabang ang materyal na ito sa bawat mambabasa, at hindi basta nabasa at nakalimutan. Sa anumang pag-aaral, ang pagsasanay ay isang napakahalagang bahagi. Para dito inihanda ko. Mayroon ding takdang-aralin na naghihintay para sa iyo upang matiyak na hindi mo basta-basta kinokopya ang mga linya ng mga utos na iyong isinasagawa.
Plano
Hakbang
Teknolohiya
Kagamitan
1
Lokal na pagtakbo (maghanda ng mga pagsubok sa web / android demo at patakbuhin ito nang lokal)
Node.js, Selenium, Appium
2
Mga sistema ng kontrol sa bersyon
pumunta
3
Containerization
Docker, Selenium grid, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Mga platform ng ulap
Google Cloud Platform
6
Orkestrasyon
Kubernetes
7
Imprastraktura bilang isang code (IaC)
Terraform, Ansible
Istraktura ng bawat seksyon
Upang panatilihing malinaw ang salaysay, ang bawat seksyon ay inilalarawan ayon sa sumusunod na balangkas:
- maikling paglalarawan ng teknolohiya,
- halaga para sa imprastraktura ng automation,
- paglalarawan ng kasalukuyang kalagayan ng imprastraktura,
- mga link sa pag-aaral,
- katulad na mga kasangkapan.
1. Magpatakbo ng mga pagsusulit nang lokal
Maikling paglalarawan ng teknolohiya
Isa lamang itong hakbang sa paghahanda upang lokal na patakbuhin ang mga demo test at i-verify na pumasa ang mga ito. Sa praktikal na bahagi, ginagamit ang Node.js, ngunit hindi rin mahalaga ang programming language at platform at magagamit mo ang mga ginagamit sa iyong kumpanya.
Gayunpaman, bilang mga tool sa automation, inirerekumenda ko ang paggamit ng Selenium WebDriver para sa mga web platform at Appium para sa Android platform, ayon sa pagkakabanggit, dahil sa mga susunod na hakbang ay gagamitin namin ang mga imahe ng Docker na iniakma upang gumana nang partikular sa mga tool na ito. Bukod dito, tinutukoy ang mga kinakailangan sa trabaho, ang mga tool na ito ay ang pinaka-in demand sa merkado.
Tulad ng maaaring napansin mo, isinasaalang-alang lang namin ang mga pagsubok sa web at Android. Sa kasamaang palad, ang iOS ay isang ganap na naiibang kuwento (salamat sa Apple). Plano kong ipakita ang mga solusyon at kasanayang nauugnay sa IOS sa mga paparating na bahagi.
Halaga para sa imprastraktura ng automation
Mula sa pananaw sa imprastraktura, ang pagpapatakbo nang lokal ay hindi nagbibigay ng anumang halaga. Tinitingnan mo lamang na ang mga pagsubok ay tumatakbo sa lokal na makina sa mga lokal na browser at simulator. Ngunit sa anumang kaso, ito ay isang kinakailangang panimulang punto.
Ilustrasyon ng kasalukuyang kalagayan ng imprastraktura
Mga link upang galugarin
Mga katulad na kasangkapan
- anumang programming language na gusto mo kasabay ng mga pagsubok sa Selenium/Appium;
- anumang mga pagsubok;
- anumang test runner.
2. Version control system (Git)
Maikling paglalarawan ng teknolohiya
Hindi ito magiging isang malaking paghahayag sa sinuman kung sasabihin kong ang kontrol sa bersyon ay isang napakahalagang bahagi ng pag-unlad, kapwa sa isang koponan at indibidwal. Batay sa iba't ibang mga mapagkukunan, ligtas na sabihin na ang Git ang pinakasikat na kinatawan. Ang isang bersyon ng control system ay nagbibigay ng maraming benepisyo, tulad ng pagbabahagi ng code, pag-iimbak ng mga bersyon, pagpapanumbalik sa mga nakaraang sangay, pagsubaybay sa kasaysayan ng proyekto, at pag-backup. Hindi namin tatalakayin ang bawat punto nang detalyado, dahil sigurado ako na pamilyar ka dito at ginagamit mo ito sa iyong pang-araw-araw na gawain. Ngunit kung biglang hindi, pagkatapos ay inirerekumenda kong ihinto ang pagbabasa ng artikulong ito at punan ang puwang na ito sa lalong madaling panahon.
Halaga para sa imprastraktura ng automation
At dito maaari kang magtanong ng isang makatwirang tanong: "Bakit niya sinasabi sa amin ang tungkol sa Git? Alam ito ng lahat at ginagamit ito kapwa para sa development code at para sa auto-test code." Magiging tama ka, ngunit sa artikulong ito ay pinag-uusapan natin ang tungkol sa imprastraktura at ang seksyong ito ay nagsisilbing preview para sa seksyon 7: "Infrastructure bilang Code (IaC)". Para sa amin, nangangahulugan ito na ang buong imprastraktura, kabilang ang pagsubok, ay inilalarawan sa anyo ng code, kaya maaari rin naming ilapat ang mga sistema ng pag-bersyon dito at makakuha ng katulad na mga benepisyo tulad ng para sa pag-develop at automation code.
Titingnan natin ang IaC nang mas detalyado sa Hakbang 7, ngunit kahit ngayon ay maaari mong simulan ang paggamit ng Git nang lokal sa pamamagitan ng paglikha ng isang lokal na imbakan. Ang malaking larawan ay lalawak kapag nagdagdag kami ng malayong imbakan sa imprastraktura.
Ilustrasyon ng kasalukuyang kalagayan ng imprastraktura
Mga link upang galugarin
Mga katulad na kasangkapan
3. Containerization (Docker)
Maikling paglalarawan ng teknolohiya
Upang ipakita kung paano binago ng containerization ang mga panuntunan ng laro, bumalik tayo sa nakalipas na ilang dekada. Noon, ang mga tao ay bumili at gumamit ng mga server machine para magpatakbo ng mga application. Ngunit sa karamihan ng mga kaso, ang mga kinakailangang mapagkukunan ng startup ay hindi alam nang maaga. Bilang resulta, ang mga kumpanya ay gumastos ng pera sa pagbili ng mga mahal, makapangyarihang mga server, ngunit ang ilan sa kapasidad na ito ay hindi ganap na nagamit.
Ang susunod na yugto ng ebolusyon ay ang mga virtual machine (VM), na lumutas sa problema ng pag-aaksaya ng pera sa hindi nagamit na mga mapagkukunan. Ginawang posible ng teknolohiyang ito na magpatakbo ng mga application nang hiwalay sa isa't isa sa loob ng parehong server, na naglalaan ng ganap na nakahiwalay na espasyo. Ngunit, sa kasamaang-palad, ang anumang teknolohiya ay may mga kakulangan nito. Ang pagpapatakbo ng VM ay nangangailangan ng isang buong operating system, na kumukonsumo ng CPU, RAM, storage at, depende sa OS, kailangang isaalang-alang ang mga gastos sa lisensya. Ang mga salik na ito ay nakakaapekto sa bilis ng pag-load at nagpapahirap sa portability.
At ngayon tayo ay dumating sa containerization. Muli, nilulutas ng teknolohiyang ito ang nakaraang problema, dahil ang mga lalagyan ay hindi gumagamit ng isang buong OS, na nagpapalaya ng malaking halaga ng mga mapagkukunan at nagbibigay ng mabilis at nababaluktot na solusyon para sa portability.
Siyempre, ang teknolohiya ng containerization ay hindi bago at unang ipinakilala noong huling bahagi ng dekada 70. Noong mga panahong iyon, maraming pananaliksik, pagpapaunlad, at pagtatangka ang isinagawa. Ngunit ang Docker ang umangkop sa teknolohiyang ito at ginawa itong madaling ma-access ng masa. Sa ngayon, kapag pinag-uusapan natin ang tungkol sa mga lalagyan, sa karamihan ng mga kaso, ang ibig nating sabihin ay Docker. Kapag pinag-uusapan natin ang tungkol sa mga lalagyan ng Docker, ang ibig nating sabihin ay mga lalagyan ng Linux. Maaari naming gamitin ang Windows at macOS system para magpatakbo ng mga container, ngunit mahalagang maunawaan na sa kasong ito ay may lalabas na karagdagang layer. Halimbawa, si Docker sa Mac ay tahimik na nagpapatakbo ng mga container sa loob ng isang magaan na Linux VM. Babalik tayo sa paksang ito kapag tinalakay natin ang pagpapatakbo ng mga Android emulator sa loob ng mga lalagyan, kaya narito mayroong isang napakahalagang nuance na kailangang talakayin nang mas detalyado.
Halaga para sa imprastraktura ng automation
Nalaman namin na cool ang containerization at Docker. Tingnan natin ito sa konteksto ng automation, dahil ang bawat tool o teknolohiya ay kailangang lutasin ang isang problema. Ibalangkas natin ang mga halatang problema ng pag-automate ng pagsubok sa konteksto ng mga pagsubok sa UI:
- isang malaking bilang ng mga dependency kapag nag-i-install ng Selenium at lalo na ang Appium;
- mga problema sa compatibility sa pagitan ng mga bersyon ng mga browser, simulator at driver;
- kakulangan ng nakahiwalay na espasyo para sa mga browser/simulator, na partikular na kritikal para sa parallel na pagtakbo;
- mahirap pamahalaan at mapanatili kung kailangan mong magpatakbo ng 10, 50, 100 o kahit 1000 browser nang sabay.
Ngunit dahil ang Selenium ay ang pinakasikat na tool sa automation at ang Docker ay ang pinakasikat na tool sa containerization, hindi dapat nakakagulat na may sumubok na pagsamahin ang mga ito upang lumikha ng isang mahusay na tool upang malutas ang mga nabanggit na problema. Isaalang-alang natin ang mga naturang solusyon nang mas detalyado.
Selenium grid sa docker
Ang tool na ito ay ang pinakasikat sa mundo ng Selenium para sa pagpapatakbo ng maraming browser sa maraming machine at pamamahala sa mga ito mula sa isang central hub. Upang magsimula, kailangan mong magparehistro ng hindi bababa sa 2 bahagi: Hub at (mga) Node. Ang Hub ay isang sentral na node na tumatanggap ng lahat ng mga kahilingan mula sa mga pagsubok at ipinamamahagi ang mga ito sa naaangkop na mga Node. Para sa bawat Node maaari naming i-configure ang isang partikular na configuration, halimbawa, sa pamamagitan ng pagtukoy sa nais na browser at ang bersyon nito. Gayunpaman, kailangan pa rin nating pangalagaan ang mga katugmang browser driver at i-install ang mga ito sa nais na Node. Para sa kadahilanang ito, ang Selenium grid ay hindi ginagamit sa purong anyo nito, maliban kung kailangan nating magtrabaho sa mga browser na hindi mai-install sa Linux OS. Para sa lahat ng iba pang mga kaso, ang isang makabuluhang flexible at tamang solusyon ay ang paggamit ng mga imahe ng Docker upang patakbuhin ang Selenium grid Hub at Nodes. Ang diskarte na ito ay lubos na pinasimple ang pamamahala ng node, dahil maaari naming piliin ang imahe na kailangan namin sa mga katugmang bersyon ng mga browser at driver na naka-install na.
Sa kabila ng mga negatibong review tungkol sa katatagan, lalo na kapag nagpapatakbo ng malaking bilang ng mga Node nang magkatulad, ang Selenium grid ay ang pinakasikat na tool para sa pagpapatakbo ng mga pagsubok sa Selenium nang magkatulad. Mahalagang tandaan na ang iba't ibang mga pagpapabuti at pagbabago ng tool na ito ay patuloy na lumalabas sa open-source, na lumalaban sa iba't ibang mga bottleneck.
Selenoid para sa Web
Ang tool na ito ay isang pambihirang tagumpay sa mundo ng Selenium dahil ito ay gumagana sa labas ng kahon at ginawang mas madali ang buhay ng maraming automation engineer. Una sa lahat, hindi ito isa pang pagbabago ng Selenium grid. Sa halip, ang mga developer ay lumikha ng isang ganap na bagong bersyon ng Selenium Hub sa Golang, na, na sinamahan ng magaan na mga imahe ng Docker para sa iba't ibang mga browser, ay nagbigay ng lakas sa pagbuo ng pagsubok na automation. Bukod dito, sa kaso ng Selenium Grid, dapat nating matukoy ang lahat ng kinakailangang mga browser at ang kanilang mga bersyon nang maaga, na hindi isang problema kapag nagtatrabaho sa isang browser lamang. Ngunit pagdating sa maraming sinusuportahang browser, ang Selenoid ang numero unong solusyon salamat sa tampok na 'browser on demand' nito. Ang kailangan lang sa amin ay i-download nang maaga ang mga kinakailangang larawan gamit ang mga browser at i-update ang configuration file kung saan nakikipag-ugnayan ang Selenoid. Pagkatapos makatanggap ang Selenoid ng kahilingan mula sa mga pagsubok, awtomatiko nitong ilulunsad ang gustong lalagyan na may gustong browser. Kapag nakumpleto na ang pagsubok, ireretiro ng Selenoid ang lalagyan, at sa gayon ay magpapalaya ng mga mapagkukunan para sa mga kahilingan sa hinaharap. Ang diskarteng ito ay ganap na nag-aalis ng kilalang problema ng 'node degradation' na madalas nating nararanasan sa Selenium grid.
Pero, sayang, hindi pa rin silver bullet si Selenoid. Nakuha namin ang feature na 'browser on demand', ngunit hindi pa rin available ang feature na 'resources on demand'. Upang magamit ang Selenoid, dapat nating i-deploy ito sa pisikal na hardware o sa isang VM, na nangangahulugang dapat nating malaman nang maaga kung gaano karaming mga mapagkukunan ang kailangang ilaan. Sa palagay ko hindi ito problema para sa maliliit na proyekto na nagpapatakbo ng 10, 20 o kahit na 30 browser nang magkatulad. Ngunit paano kung kailangan natin ng 100, 500, 1000 o higit pa? Walang saysay na panatilihin at bayaran ang napakaraming mapagkukunan sa lahat ng oras. Sa seksyon 5 at 6 ng artikulong ito, tatalakayin namin ang mga solusyon na nagbibigay-daan sa iyo upang sukatin, sa gayon ay makabuluhang binabawasan ang mga gastos ng kumpanya.
Selenoid para sa Android
Pagkatapos ng tagumpay ng Selenoid bilang isang web automation tool, gusto ng mga tao ang isang bagay na katulad para sa Android. At nangyari ito - Inilabas ang Selenoid na may suporta sa Android. Mula sa isang mataas na antas ng pananaw ng gumagamit, ang prinsipyo ng pagpapatakbo ay katulad ng pag-automate ng web. Ang pagkakaiba lang ay sa halip na mga lalagyan ng browser, ang Selenoid ay nagpapatakbo ng mga lalagyan ng Android emulator. Sa palagay ko, ito ang kasalukuyang pinakamakapangyarihang libreng tool para sa pagpapatakbo ng mga pagsubok sa Android nang magkatulad.
Talagang ayaw kong pag-usapan ang mga negatibong aspeto ng tool na ito, dahil talagang gusto ko ito. Ngunit gayon pa man, may mga parehong disadvantages na nalalapat sa web automation at nauugnay sa pag-scale. Bilang karagdagan dito, kailangan nating pag-usapan ang tungkol sa isa pang limitasyon na maaaring maging sorpresa kung ise-set up natin ang tool sa unang pagkakataon. Upang magpatakbo ng mga larawan sa Android, kailangan namin ng pisikal na makina o VM na may nested na suporta sa virtualization. Sa gabay kung paano, ipinapakita ko kung paano ito paganahin sa isang Linux VM. Gayunpaman, kung isa kang macOS user at gustong mag-deploy ng Selenoid nang lokal, hindi ito magiging posible na magpatakbo ng mga pagsubok sa Android. Ngunit maaari kang palaging magpatakbo ng isang Linux VM nang lokal na may 'nested virtualization' na na-configure at i-deploy ang Selenoid sa loob.
Ilustrasyon ng kasalukuyang kalagayan ng imprastraktura
Sa konteksto ng artikulong ito, magdaragdag kami ng 2 tool upang ilarawan ang imprastraktura. Ito ang Selenium grid para sa mga pagsubok sa web at Selenoid para sa mga pagsubok sa Android. Sa tutorial sa GitHub, ipapakita ko rin sa iyo kung paano gamitin ang Selenoid para magpatakbo ng mga pagsubok sa web.
Mga link upang galugarin
Mga katulad na kasangkapan
- Mayroong iba pang mga tool sa containerization, ngunit ang Docker ang pinakasikat. Kung gusto mong sumubok ng iba pa, tandaan na ang mga tool na saklaw namin para sa pagpapatakbo ng mga pagsubok sa Selenium nang magkatulad ay hindi gagana sa labas ng kahon.
- Tulad ng nasabi na, maraming mga pagbabago sa Selenium grid, halimbawa,.
4.CI/CD
Maikling paglalarawan ng teknolohiya
Ang pagsasagawa ng tuluy-tuloy na pagsasama ay medyo popular sa pag-unlad at kaayon ng mga version control system. Sa kabila nito, nararamdaman kong may kalituhan sa terminolohiya. Sa talatang ito gusto kong ilarawan ang 3 pagbabago ng teknolohiyang ito mula sa aking pananaw. Sa internet ay makakahanap ka ng maraming artikulo na may iba't ibang interpretasyon, at ito ay ganap na normal kung ang iyong opinyon ay naiiba. Ang pinakamahalagang bagay ay na ikaw ay nasa parehong pahina sa iyong mga kasamahan.
Kaya, mayroong 3 termino: CI - Continuous Integration, CD - Continuous Delivery at muli CD - Continuous Deployment. (Sa ibaba ay gagamitin ko ang mga terminong ito sa Ingles). Ang bawat pagbabago ay nagdaragdag ng ilang karagdagang mga hakbang sa iyong pipeline ng pag-unlad. Ngunit ang salita walang patid (patuloy) ay ang pinakamahalagang bagay. Sa kontekstong ito, ang ibig naming sabihin ay isang bagay na nangyayari mula simula hanggang katapusan, nang walang pagkaantala o manu-manong interbensyon. Tingnan natin ang CI & CD at CD sa kontekstong ito.
- Patuloy na integrasyon ito ang unang hakbang ng ebolusyon. Pagkatapos magsumite ng bagong code sa server, inaasahan naming makatanggap ng mabilis na feedback na ok ang aming mga pagbabago. Karaniwan, kasama sa CI ang pagpapatakbo ng mga tool sa pagsusuri ng static na code at mga pagsubok sa unit/internal na API. Nagbibigay-daan ito sa amin na makakuha ng impormasyon tungkol sa aming code sa loob ng ilang segundo/minuto.
- Patuloy na Paghahatid ay isang mas advanced na hakbang kung saan nagpapatakbo kami ng mga pagsubok sa integration/UI. Gayunpaman, sa yugtong ito hindi kami nakakakuha ng mga resulta nang kasing bilis ng CI. Una, mas matagal bago matapos ang mga ganitong uri ng pagsusulit. Pangalawa, bago ilunsad, dapat nating i-deploy ang ating mga pagbabago sa kapaligiran ng pagsubok/pagtatanghal. Bukod dito, kung pinag-uusapan natin ang tungkol sa pagpapaunlad ng mobile, may lalabas na karagdagang hakbang upang lumikha ng isang build ng aming application.
- Patuloy na Pag-deploy Ipinapalagay na awtomatiko naming ilalabas ang aming mga pagbabago sa produksyon kung ang lahat ng pagsubok sa pagtanggap ay naipasa na sa mga nakaraang yugto. Bilang karagdagan dito, pagkatapos ng yugto ng paglabas, maaari mong i-configure ang iba't ibang yugto, tulad ng pagpapatakbo ng mga pagsubok sa usok sa produksyon at pagkolekta ng mga sukatan ng interes. Ang Tuloy-tuloy na Deployment ay posible lamang kung may mahusay na saklaw sa pamamagitan ng mga automated na pagsubok. Kung kinakailangan ang anumang mga manu-manong interbensyon, kabilang ang pagsubok, hindi na ito Ang patuloy na (tuloy-tuloy). Pagkatapos ay maaari nating sabihin na ang ating pipeline ay sumusunod lamang sa pagsasagawa ng Continuous Delivery.
Halaga para sa imprastraktura ng automation
Sa seksyong ito, dapat kong linawin na kapag pinag-uusapan natin ang tungkol sa mga end-to-end na pagsubok sa UI, nangangahulugan ito na dapat nating i-deploy ang ating mga pagbabago at nauugnay na serbisyo upang subukan ang mga kapaligiran. Patuloy na Pagsasama - hindi naaangkop ang proseso para sa gawaing ito at dapat nating pangalagaan ang pagpapatupad ng hindi bababa sa mga kasanayan sa Continuous Deliver. Ang Continuous Deployment ay may katuturan din sa konteksto ng mga UI test kung papatakbuhin natin ang mga ito sa produksyon.
At bago natin tingnan ang paglalarawan ng pagbabago ng arkitektura, gusto kong magsabi ng ilang salita tungkol sa GitLab CI. Hindi tulad ng iba pang mga tool sa CI/CD, ang GitLab ay nagbibigay ng isang malayuang imbakan at maraming iba pang mga karagdagang tampok. Kaya, ang GitLab ay higit pa sa CI. Kabilang dito ang source code management, Agile management, CI/CD pipelines, logging tools at metrics collection out of the box. Ang arkitektura ng GitLab ay binubuo ng Gitlab CI/CD at GitLab Runner. Narito ang isang maikling paglalarawan mula sa opisyal na website:
Ang Gitlab CI/CD ay isang web application na may API na nag-iimbak ng estado nito sa isang database, namamahala ng mga proyekto/build at nagbibigay ng user interface. Ang GitLab Runner ay isang application na bumubuo ng proseso. Maaari itong i-deploy nang hiwalay at gumagana sa GitLab CI/CD sa pamamagitan ng isang API. Para sa mga pagsubok na tumatakbo kailangan mo ang parehong Gitlab instance at Runner.
Ilustrasyon ng kasalukuyang kalagayan ng imprastraktura
Mga link upang galugarin
Mga katulad na kasangkapan
- At marami pang iba
5. Cloud platform
Maikling paglalarawan ng teknolohiya
Sa seksyong ito ay pag-uusapan natin ang tungkol sa isang sikat na trend na tinatawag na 'mga pampublikong ulap'. Sa kabila ng napakalaking benepisyo na ibinibigay ng virtualization at containerization na mga teknolohiya na inilarawan sa itaas, kailangan pa rin namin ang mga mapagkukunan ng computing. Ang mga kumpanya ay bumibili ng mga mamahaling server o umarkila ng mga sentro ng data, ngunit sa kasong ito ay kinakailangan na gumawa ng mga kalkulasyon (kung minsan ay hindi makatotohanan) kung gaano karaming mga mapagkukunan ang kakailanganin natin, kung gagamitin natin ang mga ito 24/7 at para sa kung anong mga layunin. Halimbawa, ang produksyon ay nangangailangan ng isang server na tumatakbo XNUMX/XNUMX, ngunit kailangan ba natin ng mga katulad na mapagkukunan para sa pagsubok sa labas ng mga oras ng trabaho? Depende din ito sa uri ng pagsubok na ginagawa. Ang isang halimbawa ay ang mga pagsubok sa pag-load/stress na pinaplano naming patakbuhin sa mga oras na walang pasok upang makakuha ng mga resulta sa susunod na araw. Ngunit tiyak na hindi kinakailangan ang XNUMX/XNUMX na pagiging available ng server para sa mga end-to-end na awtomatikong pagsubok at lalo na hindi para sa mga manu-manong kapaligiran sa pagsubok. Para sa mga ganitong sitwasyon, makabubuting kumuha ng maraming mapagkukunan kung kinakailangan, gamitin ang mga ito, at ihinto ang pagbabayad kapag hindi na kailangan ang mga ito. Bukod dito, magiging mahusay na matanggap ang mga ito kaagad sa pamamagitan ng paggawa ng ilang mga pag-click ng mouse o pagpapatakbo ng ilang mga script. Ito ang ginagamit ng mga pampublikong ulap. Tingnan natin ang kahulugan:
βAng pampublikong ulap ay tinukoy bilang mga serbisyo sa pag-compute na inaalok ng mga third-party na provider sa pampublikong Internet, na ginagawang available ang mga ito sa sinumang gustong gamitin o bilhin ang mga ito. Maaaring libre ang mga ito o ibinebenta on-demand, na nagpapahintulot sa mga customer na magbayad lamang sa bawat paggamit para sa mga cycle ng CPU, storage, o bandwidth na kinokonsumo nila."
May isang opinyon na ang mga pampublikong ulap ay mahal. Ngunit ang kanilang pangunahing ideya ay upang bawasan ang mga gastos ng kumpanya. Tulad ng nabanggit kanina, pinapayagan ka ng mga pampublikong ulap na makakuha ng mga mapagkukunan kapag hinihiling at magbayad lamang para sa oras na ginagamit mo ang mga ito. Gayundin, kung minsan ay nakakalimutan natin na ang mga empleyado ay tumatanggap ng mga suweldo, at ang mga espesyalista ay isa ring mamahaling mapagkukunan. Dapat itong isaalang-alang na ang mga pampublikong ulap ay ginagawang mas madali ang suporta sa imprastraktura, na nagpapahintulot sa mga inhinyero na tumuon sa mas mahahalagang gawain.
Halaga para sa imprastraktura ng automation
Anong mga partikular na mapagkukunan ang kailangan namin para sa end-to-end na mga pagsubok sa UI? Karaniwang ito ay mga virtual machine o cluster (pag-uusapan natin ang tungkol sa Kubernetes sa susunod na seksyon) para sa pagpapatakbo ng mga browser at emulator. Kung mas maraming browser at emulator ang gusto nating patakbuhin nang sabay-sabay, mas maraming CPU at memory ang kailangan at mas maraming pera ang kailangan nating bayaran para dito. Kaya, ang mga pampublikong ulap sa konteksto ng pag-aautomat ng pagsubok ay nagbibigay-daan sa amin na magpatakbo ng isang malaking bilang (100, 200, 1000...) ng mga browser/emulator on demand, makakuha ng mga resulta ng pagsubok sa lalong madaling panahon at huminto sa pagbabayad para sa naturang nakakabaliw na mapagkukunan-intensive kapangyarihan.
Ang pinakasikat na cloud provider ay ang Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Ang gabay na paano gawin ay nagbibigay ng mga halimbawa kung paano gamitin ang GCP, ngunit sa pangkalahatan, hindi mahalaga kung ano ang iyong ginagamit para sa mga gawain sa automation. Lahat sila ay nagbibigay ng humigit-kumulang sa parehong pag-andar. Kadalasan, para pumili ng provider, nakatuon ang pamamahala sa pangkalahatang imprastraktura at mga kinakailangan sa negosyo ng kumpanya, na lampas sa saklaw ng artikulong ito. Para sa mga inhinyero ng automation, magiging mas kawili-wiling ihambing ang paggamit ng mga cloud provider sa paggamit ng mga cloud platform partikular para sa mga layunin ng pagsubok, tulad ng Sauce Labs, BrowserStack, BitBar, at iba pa. Kaya gawin din natin! Sa palagay ko, ang Sauce Labs ang pinakasikat na cloud testing farm, kaya naman ginamit ko ito para sa paghahambing.
GCP vs Sauce Labs para sa mga layunin ng automation:
Isipin natin na kailangan nating magpatakbo ng 8 web test at 8 Android test nang sabay-sabay. Para dito gagamitin namin ang GCP at magpapatakbo kami ng 2 virtual machine na may Selenoid. Sa una ay magtataas kami ng 8 container na may mga browser. Sa pangalawa mayroong 8 lalagyan na may mga emulator. Tingnan natin ang mga presyo:
Upang magpatakbo ng isang lalagyan gamit ang Chrome, kailangan namin n1-pamantayan-1 sasakyan. Sa kaso ng Android ito ay magiging n1-pamantayan-4 para sa isang emulator. Sa katunayan, ang isang mas nababaluktot at mas murang paraan ay ang magtakda ng mga partikular na halaga ng user para sa CPU/Memory, ngunit sa ngayon ay hindi ito mahalaga para sa paghahambing sa Sauce Labs.
At narito ang mga taripa para sa paggamit ng Sauce Labs:
Naniniwala ako na napansin mo na ang pagkakaiba, ngunit magbibigay pa rin ako ng isang talahanayan na may mga kalkulasyon para sa aming gawain:
Mga kinakailangang mapagkukunan
buwanan
Oras ng pagtatrabaho(8 am - 8 pm)
Oras ng pagtatrabaho+ Preemptible
GCP para sa Web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 araw * 12h * 0.38 = $104.88
23 araw * 12h * 0.08 = $22.08
Sauce Labs para sa Web
Virtual Cloud8 parallel na mga pagsubok
$1.559
-
-
GCP para sa Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 araw * 12h * 1.52 = $419.52
23 araw * 12h * 0.32 = $88.32
Sauce Labs para sa Android
Real Device Cloud 8 parallel na mga pagsubok
$1.999
-
-
Tulad ng nakikita mo, ang pagkakaiba sa gastos ay napakalaki, lalo na kung nagpapatakbo ka lamang ng mga pagsubok sa loob ng labindalawang oras na panahon ng pagtatrabaho. Ngunit maaari mong bawasan ang mga gastos nang higit pa kung gumagamit ka ng mga preemptible na makina. Ano ito?
Ang preemptible VM ay isang instance na maaari mong gawin at patakbuhin sa mas mataas na presyo kaysa sa mga normal na pagkakataon. Gayunpaman, maaaring wakasan (preempt) ng Compute Engine ang mga pagkakataong ito kung nangangailangan ito ng access sa mga mapagkukunang iyon para sa iba pang mga gawain. Ang mga preemptible na instance ay labis na kapasidad ng Compute Engine, kaya nag-iiba ang kanilang availability sa paggamit.
Kung ang iyong mga app ay fault-tolerant at maaaring makatiis sa mga posibleng pag-preemption ng instance, kung gayon ang mga preemptible na instance ay maaaring mabawasan nang malaki ang iyong mga gastos sa Compute Engine. Halimbawa, ang mga trabaho sa pagpoproseso ng batch ay maaaring tumakbo sa mga preemptible na pagkakataon. Kung ang ilan sa mga pagkakataong iyon ay magwawakas sa panahon ng pagproseso, ang trabaho ay bumagal ngunit hindi ganap na hihinto. Kinukumpleto ng mga preemptible instance ang iyong mga gawain sa pagpoproseso ng batch nang hindi naglalagay ng karagdagang workload sa iyong mga kasalukuyang instance at nang hindi nangangailangan na magbayad ka ng buong presyo para sa mga karagdagang normal na pagkakataon.
At hindi pa rin tapos! Sa katotohanan, sigurado ako na walang nagpapatakbo ng mga pagsusulit sa loob ng 12 oras nang walang pahinga. At kung gayon, maaari mong awtomatikong simulan at ihinto ang mga virtual machine kapag hindi kinakailangan ang mga ito. Ang aktwal na oras ng paggamit ay maaaring bawasan sa 6 na oras bawat araw. Pagkatapos ang pagbabayad sa konteksto ng aming gawain ay bababa sa $11 bawat buwan para sa 8 browser. Hindi ba ito kahanga-hanga? Ngunit sa mga preemptible machine dapat tayong mag-ingat at maghanda para sa mga pagkaantala at kawalang-tatag, bagama't ang mga sitwasyong ito ay maaaring ibigay at pangasiwaan sa software. Sulit ito!
Ngunit hindi ko sinasabing 'huwag gumamit ng cloud test farms'. Mayroon silang isang bilang ng mga pakinabang. Una sa lahat, ito ay hindi lamang isang virtual machine, ngunit isang ganap na solusyon sa pag-automate ng pagsubok na may isang hanay ng mga pag-andar sa labas ng kahon: malayuang pag-access, mga log, mga screenshot, pag-record ng video, iba't ibang mga browser at pisikal na mga mobile device. Sa maraming sitwasyon, maaari itong maging isang mahalagang alternatibong chic. Ang mga platform ng pagsubok ay partikular na kapaki-pakinabang para sa automation ng IOS, kapag ang mga pampublikong ulap ay maaari lamang mag-alok ng mga sistema ng Linux/Windows. Ngunit pag-uusapan natin ang tungkol sa iOS sa mga sumusunod na artikulo. Inirerekomenda ko ang palaging pagtingin sa sitwasyon at simula sa mga gawain: sa ilang mga kaso ay mas mura at mas mahusay na gumamit ng mga pampublikong ulap, at sa iba ang mga platform ng pagsubok ay tiyak na nagkakahalaga ng pera na ginugol.
Ilustrasyon ng kasalukuyang kalagayan ng imprastraktura
Mga link upang galugarin
Mga katulad na tool:
6. Orkestrasyon
Maikling paglalarawan ng teknolohiya
Mayroon akong magandang balita - malapit na tayo sa dulo ng artikulo! Sa ngayon, ang aming imprastraktura ng automation ay binubuo ng mga pagsubok sa web at Android, na pinapatakbo namin sa pamamagitan ng GitLab CI nang magkatulad, gamit ang mga tool na pinagana ng Docker: Selenium grid at Selenoid. Bukod dito, gumagamit kami ng mga virtual machine na ginawa sa pamamagitan ng GCP para mag-host ng mga container na may mga browser at emulator. Upang mabawasan ang mga gastos, sisimulan lang namin ang mga virtual machine na ito kapag hinihiling at ihihinto ang mga ito kapag hindi isinasagawa ang pagsubok. May iba pa bang makakapagpabuti sa ating imprastraktura? Ang sagot ay oo! Kilalanin ang mga Kubernetes (K8s)!
Una, tingnan natin kung paano nauugnay ang mga salitang orchestration, cluster, at Kubernetes sa isa't isa. Sa isang mataas na antas, ang orkestrasyon ay ang system na nagde-deploy at namamahala ng mga application. Para sa pag-automate ng pagsubok, ang mga naturang containerized na application ay Selenium grid at Selenoid. Ang mga Docker at K8 ay umakma sa isa't isa. Ang una ay ginagamit para sa pag-deploy ng application, ang pangalawa para sa orkestrasyon. Sa turn, K8s ay isang kumpol. Ang gawain ng cluster ay gamitin ang mga VM bilang Nodes, na nagbibigay-daan sa iyong mag-install ng iba't ibang functionality, program at serbisyo sa loob ng isang server (cluster). Kung ang alinman sa mga Node ay nabigo, ang ibang mga Node ay kukuha, na nagsisiguro ng walang patid na operasyon ng aming aplikasyon. Bilang karagdagan dito, ang K8s ay may mahalagang functionality na nauugnay sa scaling, salamat sa kung saan awtomatiko naming nakukuha ang pinakamainam na dami ng mga mapagkukunan batay sa pag-load at mga itinakda na limitasyon.
Sa totoo lang, ang manu-manong pag-deploy ng Kubernetes mula sa simula ay hindi isang maliit na gawain. Mag-iiwan ako ng link sa sikat na how-to guide na "Kubernetes The Hard Way" at kung interesado ka, maaari mo itong isagawa. Ngunit, sa kabutihang palad, may mga alternatibong pamamaraan at tool. Ang pinakamadaling paraan ay ang paggamit ng Google Kubernetes Engine (GKE) sa GCP, na magbibigay-daan sa iyong makakuha ng handa na cluster sa ilang pag-click. Inirerekomenda ko ang paggamit ng diskarteng ito upang simulan ang pag-aaral, dahil magbibigay-daan ito sa iyong tumutok sa pag-aaral kung paano gamitin ang mga K8 para sa iyong mga gawain sa halip na pag-aralan kung paano dapat isama ang mga panloob na bahagi sa isa't isa.
Halaga para sa imprastraktura ng automation
Tingnan natin ang ilang makabuluhang feature na ibinibigay ng K8s:
- pag-deploy ng application: gamit ang isang multi-node cluster sa halip na mga VM;
- dynamic scaling: binabawasan ang halaga ng mga mapagkukunan na ginagamit lamang kapag hinihiling;
- pagpapagaling sa sarili: awtomatikong pagbawi ng mga pods (bilang resulta kung saan ang mga lalagyan ay naibalik din);
- rollout ng mga update at rollback ng mga pagbabago nang walang downtime: ang pag-update ng mga tool, browser at emulator ay hindi nakakaabala sa gawain ng mga kasalukuyang user
Ngunit ang mga K8 ay hindi pa rin isang pilak na bala. Upang maunawaan ang lahat ng mga pakinabang at limitasyon sa konteksto ng mga tool na aming isinasaalang-alang (Selenium grid, Selenoid), tatalakayin namin sa madaling sabi ang istruktura ng mga K8. Naglalaman ang Cluster ng dalawang uri ng Node: Master Nodes at Workers Nodes. Ang mga Master Nodes ay may pananagutan para sa mga desisyon sa pamamahala, pag-deploy at pag-iiskedyul. Ang mga node ng manggagawa ay kung saan pinapatakbo ang mga application. Naglalaman din ang mga node ng container runtime environment. Sa aming kaso, ito ang Docker, na responsable para sa mga operasyong nauugnay sa lalagyan. Ngunit mayroon ding mga alternatibong solusyon, halimbawa. Mahalagang maunawaan na ang pag-scale o pagpapagaling sa sarili ay hindi direktang nalalapat sa mga lalagyan. Ito ay ipinapatupad sa pamamagitan ng pagdaragdag/pagbaba ng bilang ng mga pod, na kung saan ay naglalaman ng mga lalagyan (karaniwan ay isang lalagyan bawat pod, ngunit depende sa gawain ay maaaring marami pa). Ang mataas na antas na hierarchy ay binubuo ng mga worker node, sa loob kung saan may mga pod, sa loob kung saan ang mga container ay nakataas.
Ang tampok na pag-scale ay susi at maaaring ilapat sa parehong mga node sa loob ng isang cluster node-pool at mga pod sa loob ng isang node. Mayroong 2 uri ng scaling na nalalapat sa parehong mga node at pod. Ang unang uri ay pahalang - nagaganap ang pag-scale sa pamamagitan ng pagtaas ng bilang ng mga node/pod. Ang ganitong uri ay mas pinipili. Ang pangalawang uri ay, nang naaayon, patayo. Isinasagawa ang pag-scale sa pamamagitan ng pagtaas ng laki ng mga node/pod, at hindi ang kanilang bilang.
Ngayon tingnan natin ang aming mga tool sa konteksto ng mga termino sa itaas.
Selenium grid
Tulad ng nabanggit kanina, ang Selenium grid ay isang napaka-tanyag na tool, at hindi nakakagulat na ito ay na-contained. Samakatuwid, hindi nakakagulat na ang Selenium grid ay maaaring i-deploy sa K8s. Ang isang halimbawa ng kung paano gawin ito ay matatagpuan sa opisyal na imbakan ng K8s. Gaya ng dati, nag-attach ako ng mga link sa dulo ng seksyon. Bilang karagdagan, ipinapakita ng gabay kung paano ito gagawin sa Terraform. Mayroon ding mga tagubilin kung paano sukatin ang bilang ng mga pod na naglalaman ng mga lalagyan ng browser. Ngunit ang awtomatikong pag-andar ng pag-scale sa konteksto ng mga K8 ay hindi pa rin ganap na halatang gawain. Noong nagsimula akong mag-aral, wala akong nakitang praktikal na patnubay o rekomendasyon. Pagkatapos ng ilang pag-aaral at eksperimento na may suporta ng DevOps team, pinili namin ang paraan ng pagtataas ng mga container na may mga kinakailangang browser sa loob ng isang pod, na matatagpuan sa loob ng isang worker node. Ang pamamaraang ito ay nagpapahintulot sa amin na ilapat ang diskarte ng pahalang na pag-scale ng mga node sa pamamagitan ng pagtaas ng kanilang bilang. Umaasa ako na ito ay magbabago sa hinaharap at makakakita tayo ng higit at higit pang mga paglalarawan ng mas mahusay na mga diskarte at mga handa na solusyon, lalo na pagkatapos ng paglabas ng Selenium grid 4 na may binagong panloob na arkitektura.
Selenoid:
Ang pag-deploy ng Selenoid sa K8 ay kasalukuyang pinakamalaking pagkabigo. Hindi sila compatible. Sa teorya, maaari tayong magtaas ng Selenoid container sa loob ng pod, ngunit kapag nagsimulang maglunsad ang Selenoid ng mga container na may mga browser, mananatili pa rin sila sa loob ng parehong pod. Ginagawa nitong imposible ang pag-scale at, bilang resulta, ang gawain ng Selenoid sa loob ng isang cluster ay hindi mag-iiba mula sa trabaho sa loob ng isang virtual machine. Katapusan ng kwento.
Buwan:
Dahil alam ang bottleneck na ito kapag nagtatrabaho sa Selenoid, naglabas ang mga developer ng mas makapangyarihang tool na tinatawag na Moon. Ang tool na ito ay orihinal na idinisenyo upang gumana sa Kubernetes at, bilang resulta, ang tampok na autoscaling ay maaari at dapat gamitin. Bukod dito, sasabihin ko na sa sandaling ito ay solong isang tool sa Selenium world, na mayroong katutubong K8s cluster support out of the box (hindi na magagamit, tingnan ang susunod na tool ). Ang mga pangunahing tampok ng Moon na nagbibigay ng suportang ito ay:
Ganap na walang estado. Nag-iimbak ang Selenoid ng impormasyon sa memorya tungkol sa kasalukuyang tumatakbong mga session ng browser. Kung sa ilang kadahilanan ay nag-crash ang proseso nito β mawawala ang lahat ng tumatakbong session. Ang buwan ay walang panloob na estado at maaaring kopyahin sa mga data center. Nananatiling buhay ang mga session ng browser kahit na bumaba ang isa o higit pang mga replika.
Kaya, ang Moon ay isang mahusay na solusyon, ngunit may isang problema: ito ay hindi libre. Ang presyo ay depende sa bilang ng mga session. Maaari ka lamang magpatakbo ng 0-4 na session nang libre, na hindi partikular na kapaki-pakinabang. Ngunit, simula sa ikalimang session, kailangan mong magbayad ng $5 para sa bawat isa. Maaaring magkaiba ang sitwasyon sa bawat kumpanya, ngunit sa aming kaso, walang kabuluhan ang paggamit ng Moon. Gaya ng inilarawan ko sa itaas, maaari tayong magpatakbo ng mga VM na may Selenium Grid on demand o dagdagan ang bilang ng mga Node sa cluster. Para sa humigit-kumulang isang pipeline, naglulunsad kami ng 500 browser at ihihinto ang lahat ng mapagkukunan pagkatapos makumpleto ang mga pagsubok. Kung ginamit namin ang Moon, kailangan naming magbayad ng karagdagang 500 x 5 = $2500 bawat buwan, gaano man kami kadalas magpatakbo ng mga pagsubok. Muli, hindi ko sinasabing huwag gamitin ang Moon. Para sa iyong mga gawain, ito ay maaaring maging isang kailangang-kailangan na solusyon, halimbawa, kung marami kang proyekto/mga koponan sa iyong organisasyon at kailangan mo ng malaking karaniwang kumpol para sa lahat. Gaya ng dati, nag-iiwan ako ng link sa dulo at inirerekumenda kong gawin ang lahat ng kinakailangang kalkulasyon sa konteksto ng iyong gawain.
Callisto: (Pansin! Wala ito sa orihinal na artikulo at nakapaloob lamang sa pagsasaling Ruso)
Tulad ng sinabi ko, ang Selenium ay isang napaka-tanyag na tool, at ang larangan ng IT ay mabilis na umuunlad. Habang nagtatrabaho ako sa pagsasalin, lumitaw sa web ang isang bagong promising tool na tinatawag na Callisto (hello Cypress at iba pang Selenium killers). Ito ay katutubong gumagana sa mga K8 at nagbibigay-daan sa iyong magpatakbo ng mga Selenoid na lalagyan sa mga pod, na ipinamamahagi sa mga Node. Gumagana ang lahat sa labas ng kahon, kabilang ang autoscaling. Hindi kapani-paniwala, ngunit kailangang masuri. Nagawa ko nang i-deploy ang tool na ito at magpatakbo ng ilang mga eksperimento. Ngunit masyadong maaga upang gumawa ng mga konklusyon, pagkatapos makatanggap ng mga resulta sa isang mahabang distansya, marahil ay gagawa ako ng pagsusuri sa mga susunod na artikulo. Sa ngayon, nag-iiwan lang ako ng mga link para sa independiyenteng pananaliksik.
Ilustrasyon ng kasalukuyang kalagayan ng imprastraktura
Mga link upang galugarin
Mga katulad na kasangkapan
7. Imprastraktura bilang Code (IaC)
Maikling paglalarawan ng teknolohiya
At ngayon ay dumating kami sa huling seksyon. Karaniwan, ang teknolohiyang ito at mga kaugnay na gawain ay hindi responsibilidad ng mga inhinyero ng automation. At may mga dahilan para dito. Una, sa maraming organisasyon, ang mga isyu sa imprastraktura ay nasa ilalim ng kontrol ng departamento ng DevOps at ang mga development team ay walang pakialam sa kung ano ang nagpapagana sa pipeline at kung paano kailangang suportahan ang lahat ng konektado dito. Pangalawa, maging tapat tayo, ang pagsasagawa ng Infrastructure as Code (IaC) ay hindi pa rin pinagtibay sa maraming kumpanya. Ngunit ito ay tiyak na naging isang tanyag na kalakaran at mahalagang subukang makibahagi sa mga proseso, diskarte at mga tool na nauugnay dito. O hindi bababa sa manatiling napapanahon.
Magsimula tayo sa motibasyon sa paggamit ng diskarteng ito. Napag-usapan na namin na upang magpatakbo ng mga pagsubok sa GitlabCI, kakailanganin namin sa pinakamababang mga mapagkukunan upang patakbuhin ang Gitlab Runner. At para magpatakbo ng mga container na may mga browser/emulator, kailangan nating magreserba ng VM o cluster. Bilang karagdagan sa mga mapagkukunan ng pagsubok, kailangan namin ng isang malaking halaga ng kapasidad upang suportahan ang pag-unlad, pagtatanghal, mga kapaligiran ng produksyon, na kinabibilangan din ng mga database, awtomatikong iskedyul, pagsasaayos ng network, mga balanse ng pag-load, mga karapatan ng gumagamit, at iba pa. Ang pangunahing isyu ay ang pagsisikap na kinakailangan upang suportahan ang lahat ng ito. Mayroong ilang mga paraan upang makagawa kami ng mga pagbabago at maglunsad ng mga update. Halimbawa, sa konteksto ng GCP, maaari naming gamitin ang UI console sa browser at isagawa ang lahat ng pagkilos sa pamamagitan ng pag-click sa mga button. Ang isang alternatibo ay ang paggamit ng mga API call upang makipag-ugnayan sa mga cloud entity, o gamitin ang gcloud command line utility upang maisagawa ang mga gustong manipulasyon. Ngunit sa napakalaking bilang ng iba't ibang entity at elemento ng imprastraktura, nagiging mahirap o imposibleng gawin ang lahat ng mga operasyon nang manu-mano. Bukod dito, ang lahat ng mga manu-manong pagkilos na ito ay hindi nakokontrol. Hindi namin maaaring isumite ang mga ito para sa pagsusuri bago isagawa, gumamit ng version control system, at mabilis na ibalik ang mga pagbabagong humantong sa insidente. Upang malutas ang mga naturang problema, ang mga inhinyero ay lumikha at lumikha ng mga awtomatikong bash/shell na script, na hindi gaanong mas mahusay kaysa sa mga nakaraang pamamaraan, dahil ang mga ito ay hindi napakadaling basahin, maunawaan, mapanatili at baguhin sa isang istilo ng pamamaraan.
Sa artikulong ito at kung paano gagabay, gumagamit ako ng 2 tool na nauugnay sa pagsasanay sa IaC. Ito ay ang Terraform at Ansible. Ang ilang mga tao ay naniniwala na walang saysay na gamitin ang mga ito nang sabay-sabay, dahil ang kanilang pag-andar ay magkapareho at sila ay mapagpapalit. Ngunit ang katotohanan ay sa una sila ay binibigyan ng ganap na magkakaibang mga gawain. At ang katotohanan na ang mga tool na ito ay dapat umakma sa isa't isa ay nakumpirma sa isang pinagsamang pagtatanghal ng mga developer na kumakatawan sa HashiCorp at RedHat. Ang pagkakaiba sa konsepto ay ang Terraform ay isang tool sa pagbibigay para sa pamamahala ng mga server mismo. Habang ang Ansible ay isang tool sa pamamahala ng pagsasaayos na ang gawain ay i-install, i-configure at pamahalaan ang software sa mga server na ito.
Ang isa pang mahalagang katangian ng mga tool na ito ay ang coding style. Hindi tulad ng bash at Ansible, gumagamit ang Terraform ng istilong deklaratibo batay sa isang paglalarawan ng nais na estado ng pagtatapos na makakamit bilang resulta ng pagpapatupad. Halimbawa, kung gagawa tayo ng 10 VM at ilalapat ang mga pagbabago sa pamamagitan ng Terraform, makakakuha tayo ng 10 VM. Kung tatakbo tayong muli ng script, walang mangyayari dahil mayroon na tayong 10 VM, at alam ito ng Terraform dahil iniimbak nito ang kasalukuyang estado ng imprastraktura sa isang state file. Ngunit gumagamit ang Ansible ng pamamaraang pamamaraan at, kung hihilingin mo itong lumikha ng 10 VM, pagkatapos ay sa unang paglulunsad ay makakakuha tayo ng 10 VM, katulad ng Terraform. Ngunit pagkatapos mag-restart magkakaroon na tayo ng 20 VMs. Ito ang mahalagang pagkakaiba. Sa istilo ng pamamaraan, hindi namin iniimbak ang kasalukuyang estado at naglalarawan lamang ng pagkakasunod-sunod ng mga hakbang na dapat gawin. Siyempre, maaari nating hawakan ang iba't ibang mga sitwasyon, magdagdag ng ilang mga pagsusuri para sa pagkakaroon ng mga mapagkukunan at ang kasalukuyang estado, ngunit walang punto sa pag-aaksaya ng ating oras at paglalagay ng pagsisikap sa pagkontrol sa lohika na ito. Bilang karagdagan, pinatataas nito ang panganib na magkamali.
Sa pagbubuod ng lahat ng nasa itaas, maaari nating tapusin na ang Terraform at declarative notation ay isang mas angkop na tool para sa provisioning server. Ngunit mas mainam na italaga ang gawain ng pamamahala ng pagsasaayos sa Ansible. Sa kawalan nito, tingnan natin ang mga kaso ng paggamit sa konteksto ng automation.
Halaga para sa imprastraktura ng automation
Ang tanging mahalagang bagay na maunawaan dito ay ang imprastraktura ng pag-aautomat ng pagsubok ay dapat isaalang-alang bilang bahagi ng buong imprastraktura ng kumpanya. Nangangahulugan ito na ang lahat ng mga kasanayan sa IaC ay dapat ilapat sa buong mundo sa mga mapagkukunan ng buong organisasyon. Sino ang may pananagutan dito ay depende sa iyong mga proseso. Ang koponan ng DevOps ay mas may karanasan sa mga isyung ito, nakikita nila ang buong larawan ng kung ano ang nangyayari. Gayunpaman, ang mga inhinyero ng QA ay mas kasangkot sa proseso ng pagbuo ng automation at ang istraktura ng pipeline, na nagbibigay-daan sa kanila na mas mahusay na makita ang lahat ng kinakailangang mga pagbabago at pagkakataon para sa pagpapabuti. Ang pinakamagandang opsyon ay ang magtulungan, makipagpalitan ng kaalaman at ideya para makamit ang inaasahang resulta.
Narito ang ilang halimbawa ng paggamit ng Terraform at Ansible sa konteksto ng pag-automate ng pagsubok at ang mga tool na tinalakay namin dati:
1. Ilarawan ang mga kinakailangang katangian at parameter ng mga VM at cluster gamit ang Terraform.
2. Gamit ang Ansible, i-install ang mga tool na kailangan para sa pagsubok: docker, Selenoid, Selenium Grid at i-download ang mga kinakailangang bersyon ng mga browser/emulator.
3. Gamit ang Terraform, ilarawan ang mga katangian ng VM kung saan ilulunsad ang GitLab Runner.
4. I-install ang GitLab Runner at ang mga kinakailangang kasamang tool gamit ang Ansible, itakda ang mga setting at configuration.
Ilustrasyon ng kasalukuyang kalagayan ng imprastraktura
Mga link upang galugarin:
Mga katulad na kasangkapan
Isa-isahin natin!
Hakbang
Teknolohiya
Kagamitan
Halaga para sa imprastraktura ng automation
1
Lokal na pagtakbo
Node.js, Selenium, Appium
- Ang pinakasikat na tool para sa web at mobile
- Sinusuportahan ang maraming wika at platform (kabilang ang Node.js)
2
Mga sistema ng kontrol sa bersyon
pumunta
- Mga katulad na benepisyo sa development code
3
Containerization
Docker, Selenium grid, Selenoid (Web, Android)
- Pagpapatakbo ng mga pagsubok nang magkatulad
- Mga nakahiwalay na kapaligiran
- Simple, flexible na pag-upgrade ng bersyon
- Dynamic na pagpapahinto sa mga hindi nagamit na mapagkukunan
- Madaling i-set up
4
CI/CD
Gitlab CI
- Sinusuri ang bahagi ng pipeline
- Mabilis na Feedback
- Visibility para sa buong kumpanya/pangkat
5
Mga platform ng ulap
Google Cloud Platform
- Mga mapagkukunan kapag hinihiling (nagbabayad lang kami kapag kinakailangan)
- Madaling pamahalaan at i-update
- Visibility at kontrol ng lahat ng mga mapagkukunan
6
Orkestrasyon
Kubernetes
Sa konteksto ng mga container na may mga browser/emulator sa loob ng mga pod:
- Pag-scale/auto scaling
- Pagpapagaling sa sarili
- Mga update at rollback nang walang pagkaantala
7
Imprastraktura bilang isang code (IaC)
Terraform, Ansible
- Mga katulad na benepisyo sa imprastraktura ng pag-unlad
- Lahat ng mga benepisyo ng code versioning
- Madaling gumawa ng mga pagbabago at mapanatili
- Ganap na awtomatiko
Mga diagram ng mind map: ebolusyon ng imprastraktura
hakbang 1: Lokal
hakbang 2: VCS
hakbang 3: Containerization
hakbang 4: CI/CD
hakbang5: Mga Cloud Platform
hakbang 6: Orkestrasyon
hakbang 7: IaC
Ano ang susunod?
Kaya, ito ang katapusan ng artikulo. Ngunit sa konklusyon, nais kong magtatag ng ilang mga kasunduan sa iyo.
Mula sa iyong tabi
Gaya ng sinabi ko sa simula, nais kong maging praktikal ang paggamit ng artikulo at tulungan kang ilapat ang kaalamang natamo sa totoong gawain. dagdag ko ulit.
Ngunit kahit na pagkatapos nito, huwag huminto, magsanay, mag-aral ng mga nauugnay na link at libro, alamin kung paano ito gumagana sa iyong kumpanya, maghanap ng mga lugar na maaaring mapabuti at makilahok dito. Good luck!
Mula sa aking tabi
Mula sa pamagat ay makikita mo na ito lamang ang unang bahagi. Sa kabila ng katotohanan na ito ay naging medyo malaki, ang mahahalagang paksa ay hindi pa rin sakop dito. Sa ikalawang bahagi, plano kong tingnan ang imprastraktura ng automation sa konteksto ng IOS. Dahil sa mga paghihigpit ng Apple sa pagpapatakbo ng mga iOS simulator lamang sa mga macOS system, ang aming hanay ng mga solusyon ay pinaliit. Halimbawa, hindi namin magagamit ang Docker upang patakbuhin ang simulator o mga pampublikong ulap upang magpatakbo ng mga virtual machine. Ngunit hindi ito nangangahulugan na walang ibang mga alternatibo. Susubukan kong panatilihin kang napapanahon sa mga advanced na solusyon at modernong tool!
At saka, wala pa akong nabanggit na medyo malalaking paksa na may kaugnayan sa pagsubaybay. Sa Bahagi 3, titingnan ko ang pinakasikat na mga tool sa pagsubaybay sa imprastraktura at kung anong data at sukatan ang dapat isaalang-alang.
At sa wakas. Sa hinaharap, plano kong maglabas ng isang video course sa pagbuo ng imprastraktura ng pagsubok at mga sikat na tool. Sa kasalukuyan, may kaunting mga kurso at lektura sa DevOps sa Internet, ngunit ang lahat ng mga materyales ay ipinakita sa konteksto ng pag-unlad, hindi sa pagsubok ng automation. Sa isyung ito, kailangan ko talaga ng feedback kung magiging interesante at mahalaga ang naturang kurso para sa komunidad ng mga tester at automation engineer. Salamat nang maaga!
Pinagmulan: www.habr.com