1-qism: Veb/Android
nota: ushbu maqola asl maqolaning rus tiliga tarjimasi Biroq, rus tiliga tarjima qilinganda ma'noni buzmaslik uchun barcha rasmlar, havolalar, tirnoq va atamalar asl tilda saqlanadi. Sizga baxtli o'qish tilayman!
Hozirgi vaqtda DevOps ixtisosligi IT sohasida eng ko'p talab qilinadigan mutaxassisliklardan biridir. Agar siz mashhur ish qidirish saytlarini ochsangiz va maosh bo'yicha filtrlasangiz, DevOps bilan bog'liq ishlar ro'yxatning yuqori qismida ekanligini ko'rasiz. Biroq, bu, asosan, nomzodning yuqori darajadagi ko'nikmalari, texnologiya va vositalarni bilishini nazarda tutuvchi "Yuqori" lavozimga tegishli ekanligini tushunish muhimdir. Bu, shuningdek, ishlab chiqarishning uzluksiz ishlashi bilan bog'liq yuqori darajadagi mas'uliyat bilan birga keladi. Biroq, biz DevOps nima ekanligini unuta boshladik. Dastlab, bu biron bir aniq shaxs yoki bo'lim emas edi. Agar biz ushbu atamaning ta'riflarini izlasak, metodologiya, amaliyot, madaniyat falsafasi, tushunchalar guruhi va boshqalar kabi juda ko'p chiroyli va to'g'ri otlarni topamiz.
Mening ixtisosligim sinovlarni avtomatlashtirish muhandisi (QA avtomatlashtirish muhandisi), lekin men buni faqat avtomatik testlarni yozish yoki test tizimi arxitekturasini ishlab chiqish bilan bog'liq bo'lmasligi kerak deb hisoblayman. 2020 yilda avtomatlashtirish infratuzilmasini bilish ham muhim ahamiyatga ega. Bu sizga avtomatlashtirish jarayonini o'zingiz tashkil qilish imkonini beradi, testlarni o'tkazishdan tortib barcha manfaatdor tomonlarga maqsadlaringizga muvofiq natijalarni taqdim etishgacha. Natijada DevOps ko'nikmalari ishni bajarish uchun zarurdir. Va bularning barchasi yaxshi, lekin, afsuski, muammo bor (spoyler: ushbu maqola ushbu muammoni soddalashtirishga harakat qiladi). Gap shundaki, DevOps juda qiyin. Va bu aniq, chunki kompaniyalar qilish oson bo'lgan narsa uchun ko'p pul to'lamaydi ... DevOps dunyosida o'zlashtirilishi kerak bo'lgan juda ko'p vositalar, atamalar va amaliyotlar mavjud. Bu, ayniqsa, martaba boshida qiyin va to'plangan texnik tajribaga bog'liq.
Manba:
Bu erda, ehtimol, kirish qismi bilan yakunlaymiz va ushbu maqolaning maqsadiga e'tibor qaratamiz.
Ushbu maqola nima haqida?
Ushbu maqolada men sinovlarni avtomatlashtirish infratuzilmasini yaratish bo'yicha tajribam bilan o'rtoqlashmoqchiman. Internetda turli xil vositalar va ulardan qanday foydalanish haqida ko'plab ma'lumotlar manbalari mavjud, ammo men ularni faqat avtomatlashtirish kontekstida ko'rib chiqmoqchiman. O'ylaymanki, ko'plab avtomatlashtirish muhandislari sizdan boshqa hech kim ishlab chiqilgan testlarni o'tkazmasa yoki ularni saqlab qolish haqida qayg'urmasa, vaziyat bilan tanish. Natijada, testlar eskiradi va ularni yangilash uchun vaqt sarflashingiz kerak bo'ladi. Shunga qaramay, martaba boshida bu juda qiyin vazifa bo'lishi mumkin: qaysi vositalar berilgan muammoni bartaraf etishga yordam berishi kerakligini, ularni qanday tanlash, sozlash va saqlashni oqilona hal qilish. Ba'zi testerlar yordam uchun DevOps (odamlar) ga murojaat qilishadi va rostini aytsam, bu yondashuv ishlaydi. Ko'p hollarda bu yagona variant bo'lishi mumkin, chunki biz barcha bog'liqliklarni ko'ra olmaymiz. Ammo biz bilganimizdek, DevOps juda band yigitlar, chunki ular tashkilot/jamoaga qarab butun kompaniya infratuzilmasi, joylashtirish, monitoring, mikroservislar va shunga o'xshash boshqa vazifalar haqida o'ylashlari kerak. Odatdagidek, avtomatlashtirish ustuvor ahamiyatga ega emas. Bunday holatda, biz boshidan oxirigacha o'z tomonimizdan hamma narsani qilishga harakat qilishimiz kerak. Bu bog'liqlikni kamaytiradi, ish jarayonini tezlashtiradi, ko'nikmalarimizni oshiradi va sodir bo'layotgan voqealarning kengroq rasmini ko'rish imkonini beradi.
Maqolada eng ommabop va ommabop vositalar taqdim etilgan va ularni bosqichma-bosqich avtomatlashtirish infratuzilmasini qurish uchun qanday ishlatish ko'rsatilgan. Har bir guruh shaxsiy tajriba orqali sinovdan o'tgan vositalar bilan ifodalanadi. Ammo bu siz xuddi shu narsani ishlatishingiz kerak degani emas. Asboblarning o'zi muhim emas, ular paydo bo'ladi va eskiradi. Bizning muhandislik vazifamiz asosiy tamoyillarni tushunishdir: nima uchun biz ushbu vositalar guruhiga muhtojmiz va ularning yordami bilan qanday ish muammolarini hal qilishimiz mumkin. Shuning uchun har bir bo'lim oxirida men tashkilotingizda ishlatilishi mumkin bo'lgan shunga o'xshash vositalarga havolalar qoldiraman.
Ushbu maqolada nima yo'q
Yana bir bor takror aytamanki, maqola aniq vositalar haqida emas, shuning uchun hujjatlardan kod qo'shimchalari va aniq buyruqlar tavsifi bo'lmaydi. Ammo har bir bo'limning oxirida men batafsil o'rganish uchun havolalarni qoldiraman.
Bu amalga oshiriladi, chunki:
- ushbu materialni turli manbalarda (hujjatlar, kitoblar, video kurslar) topish juda oson;
- agar chuqurroq kirishni boshlasak, ushbu maqolaning 10, 20, 30 qismini yozishga to'g'ri keladi (rejalar 2-3 bo'lsa);
- Men shunchaki vaqtingizni behuda sarflashni xohlamayman, chunki siz bir xil maqsadlarga erishish uchun boshqa vositalardan foydalanishni xohlashingiz mumkin.
Amaliyot
Men haqiqatan ham ushbu material har bir o'quvchi uchun foydali bo'lishini istardim, shunchaki o'qigan va unutilgan. Har qanday tadqiqotda amaliyot juda muhim komponent hisoblanadi. Buning uchun men tayyorladim. Siz bajarayotgan buyruqlar qatorlarini o'ylamay nusxa ko'chirmasligingizga ishonch hosil qilish uchun sizni uy vazifasi ham kutmoqda.
Reja
qadam
texnologiya
Asboblar
1
Mahalliy ishga tushirish (veb/android demo testlarini tayyorlang va uni mahalliy sifatida ishga tushiring)
Node.js, Selenium, Appium
2
Versiyalarni boshqarish tizimlari
borib
3
Konteynerlash
Docker, Selenium grid, Selenoid (veb, Android)
4
CI/CD
Gitlab CI
5
Bulutli platformalar
Google Cloud Platform
6
Orkestratsiya
Kubernetes
7
Infratuzilma kod sifatida (IaC)
Terraform, Ansible
Har bir bo'limning tuzilishi
Hikoya aniq bo'lishi uchun har bir bo'lim quyidagi sxema bo'yicha tavsiflanadi:
- texnologiyaning qisqacha tavsifi,
- avtomatlashtirish infratuzilmasi qiymati,
- infratuzilmaning hozirgi holatini tasvirlash,
- o'qish uchun havolalar,
- shunga o'xshash vositalar.
1. Mahalliy testlarni o'tkazing
Texnologiyaning qisqacha tavsifi
Bu mahalliy demo testlarni o'tkazish va ularning o'tganligini tekshirish uchun tayyorgarlik bosqichidir. Amaliy qismda Node.js ishlatiladi, lekin dasturlash tili va platformasi ham muhim emas va siz o'z kompaniyangizda qo'llaniladiganlaridan foydalanishingiz mumkin.
Biroq, avtomatlashtirish vositalari sifatida men mos ravishda veb-platformalar uchun Selenium WebDriver va Android platformasi uchun Appium-dan foydalanishni tavsiya qilaman, chunki keyingi bosqichlarda biz ushbu vositalar bilan ishlashga moslashtirilgan Docker tasvirlaridan foydalanamiz. Bundan tashqari, ish talablaridan kelib chiqqan holda, ushbu vositalar bozorda eng ko'p talabga ega.
Siz sezganingizdek, biz faqat veb va Android testlarini ko'rib chiqamiz. Afsuski, iOS butunlay boshqacha hikoya (Apple uchun rahmat). Men kelgusi qismlarda IOS bilan bog'liq echimlar va amaliyotlarni namoyish qilishni rejalashtirmoqdaman.
Avtomatlashtirish infratuzilmasi uchun qiymat
Infratuzilma nuqtai nazaridan, mahalliy darajada ishlash hech qanday qiymat bermaydi. Siz sinovlar faqat mahalliy brauzer va simulyatorlarda mahalliy mashinada ishlashini tekshirasiz. Lekin har holda, bu zaruriy boshlang'ich nuqtadir.
Infratuzilmaning hozirgi holatini tasvirlash
Tadqiq qilish uchun havolalar
Shunga o'xshash vositalar
- Selenium/Appium testlari bilan birgalikda sizga yoqqan har qanday dasturlash tili;
- har qanday testlar;
- har qanday sinovchi.
2. Versiyalarni boshqarish tizimlari (Git)
Texnologiyaning qisqacha tavsifi
Agar men versiyani boshqarish jamoada ham, individual ravishda ham rivojlanishning juda muhim qismidir, desam, bu hech kim uchun katta vahiy bo'lmaydi. Turli manbalarga asoslanib, Git eng mashhur vakil deb aytish mumkin. Versiyalarni boshqarish tizimi kod almashish, versiyalarni saqlash, oldingi filiallarga tiklash, loyiha tarixini kuzatish va zaxira nusxalari kabi ko'plab afzalliklarni beradi. Biz har bir nuqtani batafsil muhokama qilmaymiz, chunki siz u bilan juda yaxshi tanish ekanligingizga va kundalik ishingizda foydalanishingizga aminman. Ammo to'satdan bo'lmasa, men ushbu maqolani o'qishni to'xtatib turishni va imkon qadar tezroq bu bo'shliqni to'ldirishni maslahat beraman.
Avtomatlashtirish infratuzilmasi uchun qiymat
Va bu erda siz oqilona savol berishingiz mumkin: βNega u bizga Git haqida gapiryapti? Buni hamma biladi va uni ishlab chiqish kodi uchun ham, avtomatik sinov kodi uchun ham ishlatadi. Siz mutlaqo haqsiz, lekin ushbu maqolada biz infratuzilma haqida gapiramiz va ushbu bo'lim 7-bo'lim uchun oldindan ko'rish vazifasini bajaradi: "Infratuzilma kod sifatida (IaC)". Biz uchun bu butun infratuzilma, shu jumladan test kod shaklida tasvirlanganligini anglatadi, shuning uchun biz unga versiya tizimlarini qo'llashimiz va ishlab chiqish va avtomatlashtirish kodiga o'xshash imtiyozlarga ega bo'lishimiz mumkin.
Biz 7-bosqichda IaC-ni batafsil ko'rib chiqamiz, ammo hozir ham siz mahalliy ombor yaratish orqali Git-dan mahalliy sifatida foydalanishni boshlashingiz mumkin. Infratuzilmaga masofaviy omborni qo'shganimizda katta rasm kengaytiriladi.
Infratuzilmaning hozirgi holatini tasvirlash
Tadqiq qilish uchun havolalar
Shunga o'xshash vositalar
3. Konteynerlashtirish (Docker)
Texnologiyaning qisqacha tavsifi
Konteynerlashtirish o'yin qoidalarini qanday o'zgartirganini ko'rsatish uchun keling, bir necha o'n yilliklarga qaytaylik. O'sha paytda odamlar ilovalarni ishga tushirish uchun server mashinalarini sotib olishgan va ishlatishgan. Ammo ko'p hollarda kerakli boshlang'ich resurslari oldindan ma'lum emas edi. Natijada, kompaniyalar qimmat, kuchli serverlarni sotib olishga pul sarfladilar, ammo bu imkoniyatlarning bir qismi to'liq ishlatilmadi.
Evolyutsiyaning keyingi bosqichi virtual mashinalar (VM) bo'lib, foydalanilmagan resurslarga pul sarflash muammosini hal qildi. Ushbu texnologiya bir xil serverda ilovalarni bir-biridan mustaqil ravishda ishga tushirishga imkon berdi, bu esa butunlay izolyatsiya qilingan joyni ajratdi. Ammo, afsuski, har qanday texnologiyaning kamchiliklari bor. VM ni ishga tushirish uchun protsessor, operativ xotira, saqlash va operatsion tizimga qarab litsenziya xarajatlarini hisobga oladigan toβliq operatsion tizim talab qilinadi. Bu omillar yuklash tezligiga ta'sir qiladi va ko'chirishni qiyinlashtiradi.
Va endi biz konteynerlashtirishga keldik. Yana bir bor, ushbu texnologiya avvalgi muammoni hal qiladi, chunki konteynerlar to'liq OS dan foydalanmaydi, bu katta hajmdagi resurslarni bo'shatadi va portativlik uchun tez va moslashuvchan echimni ta'minlaydi.
Albatta, konteynerlashtirish texnologiyasi yangi narsa emas va birinchi marta 70-yillarning oxirida kiritilgan. O'sha kunlarda ko'plab tadqiqotlar, ishlanmalar va urinishlar amalga oshirildi. Ammo aynan Docker bu texnologiyani moslashtirgan va uni ommaga osonlik bilan ochiq qilib qoβygan. Hozirgi vaqtda konteynerlar haqida gapirganda, aksariyat hollarda biz Dockerni nazarda tutamiz. Docker konteynerlari haqida gapirganda, biz Linux konteynerlarini nazarda tutamiz. Konteynerlarni ishga tushirish uchun Windows va macOS tizimlaridan foydalanishimiz mumkin, ammo bu holda qo'shimcha qatlam paydo bo'lishini tushunish muhimdir. Masalan, Macβdagi Docker yengil Linux VM ichida konteynerlarni jimgina boshqaradi. Konteynerlar ichida Android emulyatorlarini ishga tushirishni muhokama qilganimizda biz ushbu mavzuga qaytamiz, shuning uchun bu erda batafsilroq muhokama qilinishi kerak bo'lgan juda muhim nuance bor.
Avtomatlashtirish infratuzilmasi uchun qiymat
Biz konteynerlashtirish va Docker ajoyib ekanligini bilib oldik. Keling, buni avtomatlashtirish kontekstida ko'rib chiqaylik, chunki har bir vosita yoki texnologiya muammoni hal qilishi kerak. Keling, UI testlari kontekstida testlarni avtomatlashtirishning aniq muammolarini sanab o'tamiz:
- Selenium va ayniqsa Appiumni o'rnatishda juda ko'p bog'liqliklar;
- brauzerlar, simulyatorlar va drayverlarning versiyalari o'rtasidagi muvofiqlik muammolari;
- brauzerlar/simulyatorlar uchun ajratilgan joy yo'qligi, bu ayniqsa parallel ishlash uchun juda muhimdir;
- Agar siz bir vaqtning o'zida 10, 50, 100 yoki hatto 1000 ta brauzerni ishga tushirishingiz kerak bo'lsa, uni boshqarish va saqlash qiyin.
Ammo Selenium eng mashhur avtomatlashtirish vositasi va Docker eng mashhur konteynerlashtirish vositasi bo'lganligi sababli, kimdir yuqorida aytib o'tilgan muammolarni hal qilish uchun kuchli vosita yaratish uchun ularni birlashtirishga harakat qilgani ajablanarli emas. Keling, bunday echimlarni batafsil ko'rib chiqaylik.
Dockerdagi selenli panjara
Ushbu vosita bir nechta mashinalarda bir nechta brauzerlarni ishga tushirish va ularni markaziy markazdan boshqarish uchun Selenium dunyosida eng mashhur hisoblanadi. Boshlash uchun siz kamida 2 qismni ro'yxatdan o'tkazishingiz kerak: Hub va tugun(lar). Hub - bu testlardan barcha so'rovlarni qabul qiladigan va ularni tegishli tugunlarga tarqatadigan markaziy tugun. Har bir tugun uchun biz ma'lum bir konfiguratsiyani sozlashimiz mumkin, masalan, kerakli brauzer va uning versiyasini belgilash orqali. Biroq, biz hali ham mos keladigan brauzer drayverlari haqida o'zimiz g'amxo'rlik qilishimiz va ularni kerakli tugunlarga o'rnatishimiz kerak. Shu sababli, Selenium grid o'zining sof ko'rinishida ishlatilmaydi, faqat Linux operatsion tizimida o'rnatib bo'lmaydigan brauzerlar bilan ishlash kerak bo'lganda. Boshqa barcha holatlar uchun Selenium grid Hub va tugunlarini ishga tushirish uchun Docker tasvirlaridan foydalanish sezilarli darajada moslashuvchan va to'g'ri echim bo'ladi. Ushbu yondashuv tugunlarni boshqarishni sezilarli darajada osonlashtiradi, chunki biz allaqachon o'rnatilgan brauzerlar va drayverlarning mos versiyalari bilan kerakli tasvirni tanlashimiz mumkin.
Barqarorlik haqidagi salbiy sharhlarga qaramay, ayniqsa ko'p sonli tugunlarni parallel ravishda ishga tushirishda, Selenium grid hali ham Selenium testlarini parallel ravishda bajarish uchun eng mashhur vositadir. Shuni ta'kidlash kerakki, ushbu vositaning turli xil yaxshilanishlari va modifikatsiyalari doimiy ravishda ochiq manbalarda paydo bo'lib, ular turli xil qiyinchiliklarga qarshi kurashadilar.
Veb uchun selenoid
Ushbu vosita Selenyum olamidagi yutuqdir, chunki u to'g'ridan-to'g'ri qutidan ishlaydi va ko'plab avtomatlashtirish muhandislarining hayotini ancha osonlashtirdi. Birinchidan, bu Selenium panjarasining yana bir modifikatsiyasi emas. Buning o'rniga ishlab chiquvchilar Golangda Selenium Hub-ning mutlaqo yangi versiyasini yaratdilar, bu turli xil brauzerlar uchun engil Docker tasvirlari bilan birgalikda testlarni avtomatlashtirishni rivojlantirishga turtki berdi. Bundan tashqari, Selenium Grid holatida biz barcha kerakli brauzerlarni va ularning versiyalarini oldindan aniqlashimiz kerak, bu faqat bitta brauzer bilan ishlashda muammo emas. Ammo bir nechta qo'llab-quvvatlanadigan brauzerlar haqida gap ketganda, Selenoid "talab bo'yicha brauzer" xususiyati tufayli birinchi o'rinda turadi. Bizdan talab qilinadigan narsa bu brauzerlar bilan kerakli rasmlarni oldindan yuklab olish va Selenoid bilan o'zaro aloqada bo'lgan konfiguratsiya faylini yangilashdir. Selenoid testlardan so'rovni olgandan so'ng, u avtomatik ravishda kerakli brauzer bilan kerakli konteynerni ishga tushiradi. Sinov tugagach, Selenoid konteynerni bekor qiladi va shu bilan kelajakdagi so'rovlar uchun resurslarni bo'shatadi. Ushbu yondashuv Selenium tarmog'ida tez-tez uchrab turadigan "tugun degradatsiyasi" muammosini butunlay yo'q qiladi.
Ammo, afsuski, Selenoid hali ham kumush o'q emas. Bizda βtalab boβyicha brauzerβ funksiyasi mavjud, biroq βtalab boβyicha resurslarβ funksiyasi hali ham mavjud emas. Selenoid-dan foydalanish uchun biz uni jismoniy uskunada yoki VM-da joylashtirishimiz kerak, ya'ni biz qancha resurslarni ajratish kerakligini oldindan bilishimiz kerak. O'ylaymanki, bu 10, 20 yoki hatto 30 ta brauzerni parallel ravishda ishlaydigan kichik loyihalar uchun muammo emas. Ammo bizga 100, 500, 1000 va undan ko'p kerak bo'lsa nima bo'ladi? Har doim juda ko'p resurslarni saqlash va to'lash mantiqqa to'g'ri kelmaydi. Ushbu maqolaning 5 va 6-bo'limlarida biz o'lchovni kengaytirishga imkon beruvchi echimlarni muhokama qilamiz va shu bilan kompaniya xarajatlarini sezilarli darajada kamaytiradi.
Android uchun selenoid
Selenoid veb-avtomatlashtirish vositasi sifatida muvaffaqiyat qozonganidan so'ng, odamlar Android uchun shunga o'xshash narsani xohlashdi. Va bu sodir bo'ldi - Selenoid Android qo'llab-quvvatlashi bilan chiqarildi. Yuqori darajadagi foydalanuvchi nuqtai nazaridan, ishlash printsipi veb-avtomatlashtirishga o'xshaydi. Yagona farq shundaki, brauzer konteynerlari o'rniga Selenoid Android emulyator konteynerlarini boshqaradi. Menimcha, bu hozirda Android testlarini parallel ravishda bajarish uchun eng kuchli bepul vositadir.
Men ushbu vositaning salbiy tomonlari haqida gapirishni xohlamayman, chunki bu menga juda yoqadi. Ammo shunga qaramay, veb-avtomatlashtirishga tegishli va masshtablash bilan bog'liq bo'lgan bir xil kamchiliklar mavjud. Bunga qo'shimcha ravishda, agar biz ushbu vositani birinchi marta o'rnatayotgan bo'lsak, ajablantiradigan yana bir cheklov haqida gapirishimiz kerak. Android tasvirlarini ishga tushirish uchun bizga ichki virtualizatsiya yordamiga ega jismoniy mashina yoki VM kerak. Qo'llanmada men buni Linux VM-da qanday yoqishni ko'rsataman. Biroq, agar siz macOS foydalanuvchisi bo'lsangiz va Selenoid-ni mahalliy sifatida o'rnatmoqchi bo'lsangiz, Android testlarini o'tkazib bo'lmaydi. Lekin siz har doim "ichiga o'rnatilgan virtualizatsiya" sozlangan Linux VM ni mahalliy sifatida ishga tushirishingiz va Selenoidni ichkariga joylashtirishingiz mumkin.
Infratuzilmaning hozirgi holatini tasvirlash
Ushbu maqola kontekstida biz infratuzilmani tasvirlash uchun 2 ta vositani qo'shamiz. Bular veb-testlar uchun Selenium grid va Android testlari uchun Selenoid. GitHub o'quv qo'llanmasida men sizga Selenoiddan veb testlarni o'tkazish uchun qanday foydalanishni ham ko'rsataman.
Tadqiq qilish uchun havolalar
Shunga o'xshash vositalar
- Boshqa konteynerlash vositalari mavjud, ammo Docker eng mashhur hisoblanadi. Agar siz boshqa narsani sinab ko'rmoqchi bo'lsangiz, Selenium testlarini parallel ravishda o'tkazish uchun biz ko'rib chiqqan vositalar qutidan ishlamasligini yodda tuting.
- Yuqorida aytib o'tilganidek, Selenium panjarasining ko'plab modifikatsiyalari mavjud, masalan,.
4.CI/CD
Texnologiyaning qisqacha tavsifi
Uzluksiz integratsiya amaliyoti ishlab chiqishda juda mashhur va versiyalarni boshqarish tizimlari bilan tengdir. Shunga qaramay, men terminologiyada chalkashlik borligini his qilaman. Ushbu paragrafda men ushbu texnologiyaning 3 ta modifikatsiyasini o'z nuqtai nazarimdan tasvirlamoqchiman. Internetda siz turli xil talqinlarga ega ko'plab maqolalarni topasiz va sizning fikringiz boshqacha bo'lsa, bu mutlaqo normaldir. Eng muhimi, siz hamkasblaringiz bilan bir sahifadasiz.
Shunday qilib, 3 ta atama mavjud: CI - Uzluksiz integratsiya, CD - Uzluksiz yetkazib berish va yana CD - Uzluksiz joylashtirish. (Quyida men ushbu atamalarni ingliz tilida ishlataman). Har bir o'zgartirish sizning rivojlanish quvuringizga bir nechta qo'shimcha qadamlar qo'shadi. Lekin so'z Doimiy (uzluksiz) eng muhim narsadir. Shu nuqtai nazardan, biz boshidan oxirigacha, uzilishlarsiz yoki qo'l aralashuvisiz sodir bo'ladigan narsani nazarda tutamiz. Keling, ushbu kontekstda CI & CD va CDni ko'rib chiqaylik.
- Doimiy integratsiya bu evolyutsiyaning dastlabki bosqichidir. Serverga yangi kodni yuborganimizdan so'ng, biz o'zgarishlarimiz yaxshi ekanligi haqida tezkor fikr-mulohaza olishni kutamiz. Odatda, CI statik kodni tahlil qilish vositalarini va birlik/ichki API testlarini o'z ichiga oladi. Bu bizga kodimiz haqida bir necha soniya/daqiqada ma'lumot olish imkonini beradi.
- Har doim yetkazib berish integratsiya/UI testlarini o'tkazadigan yanada rivojlangan qadamdir. Biroq, bu bosqichda biz CI bilan bo'lgani kabi tez natijalarga erisha olmaymiz. Birinchidan, bu turdagi testlarni bajarish uchun ko'proq vaqt talab etiladi. Ikkinchidan, ishga tushirishdan oldin biz o'zgartirishlarimizni sinov/sahna muhitiga joylashtirishimiz kerak. Bundan tashqari, agar biz mobil telefonni ishlab chiqish haqida gapiradigan bo'lsak, unda bizning ilovamizni yaratish uchun qo'shimcha qadam paydo bo'ladi.
- Doimiy tarqatish Agar barcha qabul qilish sinovlari oldingi bosqichlarda o'tgan bo'lsa, biz avtomatik ravishda ishlab chiqarishga o'zgartirishlarimizni qo'yib beramiz deb taxmin qiladi. Bunga qo'shimcha ravishda, chiqarish bosqichidan so'ng siz ishlab chiqarishda tutun testlarini o'tkazish va qiziqish ko'rsatkichlarini yig'ish kabi turli bosqichlarni sozlashingiz mumkin. Uzluksiz joylashtirish faqat avtomatlashtirilgan testlar bilan yaxshi qamrab olingan holda mumkin. Agar har qanday qo'lda aralashuvlar, shu jumladan testlar talab etilsa, bu endi bo'lmaydi Davomiy (davomiy). Keyin aytishimiz mumkinki, bizning quvurimiz faqat Uzluksiz etkazib berish amaliyotiga mos keladi.
Avtomatlashtirish infratuzilmasi uchun qiymat
Ushbu bo'limda men UI sinovlari haqida gapiradigan bo'lsak, bu bizning o'zgarishlarimiz va tegishli xizmatlarni sinov muhitiga joylashtirishimiz kerakligini anglatadi. Uzluksiz integratsiya - jarayon bu vazifa uchun qo'llanilmaydi va biz hech bo'lmaganda Continuous Deliver amaliyotlarini amalga oshirish haqida g'amxo'rlik qilishimiz kerak. Uzluksiz joylashtirish, agar biz ularni ishlab chiqarishda ishlatmoqchi bo'lsak, UI testlari kontekstida ham mantiqiy bo'ladi.
Arxitektura o'zgarishining rasmini ko'rishdan oldin, men GitLab CI haqida bir necha so'z aytmoqchiman. Boshqa CI/CD vositalaridan farqli o'laroq, GitLab masofaviy ombor va boshqa ko'plab qo'shimcha funktsiyalarni taqdim etadi. Shunday qilib, GitLab CI dan ko'proq. U manba kodini boshqarish, Agile boshqaruvi, CI/CD quvurlari, ro'yxatga olish vositalari va qutidan tashqari o'lchovlar to'plamini o'z ichiga oladi. GitLab arxitekturasi Gitlab CI/CD va GitLab Runner dan iborat. Rasmiy veb-saytdan qisqacha tavsif:
Gitlab CI/CD - bu API-ga ega veb-ilova bo'lib, uning holatini ma'lumotlar bazasida saqlaydi, loyihalarni/qurilishlarni boshqaradi va foydalanuvchi interfeysini ta'minlaydi. GitLab Runner - bu qurilishlarni qayta ishlaydigan dastur. U alohida joylashtirilishi mumkin va API orqali GitLab CI/CD bilan ishlaydi. Ishlayotgan testlar uchun sizga Gitlab misoli va Runner kerak.
Infratuzilmaning hozirgi holatini tasvirlash
Tadqiq qilish uchun havolalar
Shunga o'xshash vositalar
- Va boshqalar
5. Bulutli platformalar
Texnologiyaning qisqacha tavsifi
Ushbu bo'limda biz "ommaviy bulutlar" deb nomlangan mashhur tendentsiya haqida gapiramiz. Yuqorida tavsiflangan virtualizatsiya va konteynerlashtirish texnologiyalarining ulkan afzalliklariga qaramay, biz hali ham hisoblash resurslariga muhtojmiz. Kompaniyalar qimmat serverlarni sotib olishadi yoki ma'lumotlar markazlarini ijaraga olishadi, ammo bu holda bizga qancha resurslar kerak bo'lishi, biz ulardan 24/7 kun foydalanamizmi va qanday maqsadlarda foydalanamizmi, hisob-kitoblarni (ba'zan haqiqiy emas) qilish kerak. Misol uchun, ishlab chiqarish XNUMX/XNUMX ishlaydigan serverni talab qiladi, ammo ish vaqtidan tashqari sinov uchun shunga o'xshash resurslar kerakmi? Bu, shuningdek, amalga oshirilayotgan test turiga bog'liq. Masalan, biz keyingi kun natijalarni olish uchun ishlamaydigan soatlarda o'tkazishni rejalashtirgan yuk/stress testlari bo'lishi mumkin. Lekin, albatta, XNUMX/XNUMX server mavjudligi oxirigacha avtomatlashtirilgan testlar uchun talab qilinmaydi va ayniqsa qo'lda sinov muhitlari uchun emas. Bunday vaziyatlarda talab bo'yicha zarur bo'lgan resurslarni olish, ulardan foydalanish va kerak bo'lmaganda to'lashni to'xtatish yaxshi bo'lardi. Bundan tashqari, sichqonchani bir necha marta bosish yoki bir nechta skriptlarni ishga tushirish orqali ularni darhol qabul qilish ajoyib bo'lar edi. Ommaviy bulutlardan aynan shu maqsadda foydalaniladi. Keling, ta'rifni ko'rib chiqaylik:
βOmmaviy bulut deganda uchinchi tomon provayderlari tomonidan umumiy Internet orqali taklif qilinadigan, ulardan foydalanishni yoki sotib olishni istagan har bir kishi foydalanishi mumkin boβlgan hisoblash xizmatlari tushuniladi. Ular bepul bo'lishi yoki talab bo'yicha sotilishi mumkin, bu esa mijozlarga faqat protsessor davrlari, xotira yoki o'tkazish qobiliyati uchun har bir foydalanish uchun to'lash imkonini beradi."
Ommaviy bulutlar qimmat degan fikr bor. Ammo ularning asosiy g'oyasi kompaniya xarajatlarini kamaytirishdir. Yuqorida aytib o'tilganidek, ommaviy bulutlar sizga resurslarni talab bo'yicha olish va faqat ulardan foydalangan vaqtingiz uchun to'lash imkonini beradi. Bundan tashqari, ba'zida biz xodimlarning ish haqi olishlarini unutamiz va mutaxassislar ham qimmat manbadir. Shuni hisobga olish kerakki, ommaviy bulutlar infratuzilmani qo'llab-quvvatlashni ancha osonlashtiradi, bu esa muhandislarga muhimroq vazifalarga e'tibor qaratish imkonini beradi.
Avtomatlashtirish infratuzilmasi uchun qiymat
UI sinovlari uchun bizga qanday maxsus resurslar kerak? Asosan, bu virtual mashinalar yoki klasterlar (keyingi bo'limda Kubernetes haqida gaplashamiz) brauzerlar va emulyatorlarni ishga tushirish uchun. Biz bir vaqtning o'zida qancha ko'p brauzer va emulyatorlar ishlamoqchi bo'lsak, shunchalik ko'p protsessor va xotira talab qilinadi va biz buning uchun ko'proq pul to'lashimiz kerak. Shunday qilib, sinovlarni avtomatlashtirish kontekstidagi ommaviy bulutlar bizga talab bo'yicha ko'p sonli (100, 200, 1000...) brauzerlar/emulatorlarni ishga tushirish, test natijalarini imkon qadar tezroq olish va bunday aql bovar qilmaydigan darajada resurs talab qiladigan xizmatlar uchun to'lashni to'xtatish imkonini beradi. kuch.
Eng mashhur bulutli provayderlar - Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Qo'llanmada GCP dan qanday foydalanishga oid misollar keltirilgan, lekin umuman olganda, avtomatlashtirish vazifalari uchun nimadan foydalanish muhim emas. Ularning barchasi taxminan bir xil funktsiyani ta'minlaydi. Odatda, provayderni tanlash uchun menejment kompaniyaning umumiy infratuzilmasi va biznes talablariga e'tibor qaratadi, bu ushbu maqola doirasidan tashqarida. Avtomatlashtirish muhandislari uchun bulutli provayderlardan foydalanishni bulutli platformalardan, masalan, Sauce Labs, BrowserStack, BitBar va boshqalar kabi sinov maqsadlarida foydalanish bilan solishtirish qiziqroq bo'ladi. Shunday ekan, keling, buni ham qilaylik! Menimcha, Sauce Labs - bu eng mashhur bulutli sinov fermasi, shuning uchun men uni taqqoslash uchun ishlatganman.
Avtomatlashtirish maqsadlari uchun GCP va Sauce Labs:
Tasavvur qilaylik, biz bir vaqtning o'zida 8 ta veb-test va 8 ta Android testini o'tkazishimiz kerak. Buning uchun biz GCP dan foydalanamiz va Selenoid bilan 2 ta virtual mashinani ishga tushiramiz. Birinchisida biz brauzerlar bilan 8 ta konteynerni ko'taramiz. Ikkinchisida emulyatorli 8 ta konteyner mavjud. Keling, narxlarni ko'rib chiqaylik:
Chrome bilan bitta konteynerni ishga tushirish uchun bizga kerak n1-standart-1 mashina. Android holatida shunday bo'ladi n1-standart-4 bitta emulyator uchun. Aslida, yanada moslashuvchan va arzonroq usul bu CPU/xotira uchun ma'lum foydalanuvchi qiymatlarini o'rnatishdir, ammo hozirda bu Sauce Labs bilan taqqoslash uchun muhim emas.
Va sous laboratoriyalaridan foydalanish tariflari:
O'ylaymanki, siz allaqachon farqni sezgansiz, lekin men hali ham vazifamiz uchun hisob-kitoblar bilan jadvalni taqdim etaman:
Kerakli resurslar
Oylik
Ish vaqti(8:8 - XNUMX:XNUMX)
Ish vaqti+ Imtiyozli
Veb uchun GCP
n1-standart-1 x 8 = n1-standart-8
$194.18
23 kun * 12 soat * 0.38 = $104.88
23 kun * 12 soat * 0.08 = $22.08
Veb uchun sous laboratoriyalari
Virtual Cloud8 parallel sinovlari
$1.559
-
-
Android uchun GCP
n1-standart-4 x 8: n1-standart-16
$776.72
23 kun * 12 soat * 1.52 = $419.52
23 kun * 12 soat * 0.32 = $88.32
Android uchun sous laboratoriyalari
Real Device Cloud 8 parallel sinovlari
$1.999
-
-
Ko'rib turganingizdek, narxdagi farq juda katta, ayniqsa siz sinovlarni faqat o'n ikki soatlik ish davrida o'tkazsangiz. Biroq, agar siz imtiyozli mashinalardan foydalansangiz, xarajatlarni yanada kamaytirishingiz mumkin. Bu nima?
Imtiyozli VM - bu oddiy nusxalarga qaraganda ancha arzonroq narxda yaratishingiz va ishga tushirishingiz mumkin bo'lgan namunadir. Biroq, Compute Engine boshqa vazifalar uchun ushbu resurslarga kirishni talab qilsa, bu misollarni tugatishi (oldindan o'tkazishi) mumkin. Imtiyozli misollar ortiqcha Compute Engine sigβimidir, shuning uchun ularning mavjudligi foydalanishga qarab farq qiladi.
Agar ilovalaringiz nosozliklarga chidamli boΚ»lsa va mumkin boΚ»lgan namunaviy imtiyozlarga bardosh bera olsa, imtiyozli misollar Compute Engine xarajatlarini sezilarli darajada kamaytirishi mumkin. Misol uchun, ommaviy qayta ishlash vazifalari imtiyozli misollarda ishlashi mumkin. Agar ushbu holatlardan ba'zilari ishlov berish jarayonida tugasa, ish sekinlashadi, lekin to'liq to'xtamaydi. Imtiyozli misollar mavjud nusxalaringizga qo'shimcha ish yukini yuklamasdan va qo'shimcha oddiy misollar uchun to'liq narxni to'lashni talab qilmasdan, ommaviy qayta ishlash vazifalaringizni bajaradi.
Va hali tugamadi! Aslida, aminmanki, hech kim 12 soat davomida tanaffussiz testlarni o'tkazmaydi. Agar shunday bo'lsa, virtual mashinalarni kerak bo'lmaganda avtomatik ravishda ishga tushirishingiz va to'xtatishingiz mumkin. Haqiqiy foydalanish vaqti kuniga 6 soatgacha qisqartirilishi mumkin. Keyin bizning vazifamiz kontekstida to'lov 11 ta brauzer uchun oyiga $ 8 gacha kamayadi. Bu ajoyib emasmi? Biroq, ustun mashinalar bilan biz ehtiyot bo'lishimiz va uzilishlar va beqarorlikka tayyor bo'lishimiz kerak, garchi bu holatlar dasturiy ta'minotda ta'minlanishi va hal qilinishi mumkin. Bunga arziydi!
Lekin men "hech qachon bulutli sinov fermalaridan foydalanmang" demayman. Ular bir qator afzalliklarga ega. Avvalo, bu shunchaki virtual mashina emas, balki qutidan tashqarida mavjud bo'lgan funktsiyalar to'plamiga ega bo'lgan to'liq huquqli sinov avtomatlashtirish yechimi: masofadan kirish, jurnallar, skrinshotlar, video yozuvlar, turli xil brauzerlar va jismoniy mobil qurilmalar. Ko'pgina hollarda, bu juda muhim alternativa bo'lishi mumkin. Sinov platformalari, ayniqsa, ommaviy bulutlar faqat Linux/Windows tizimlarini taklif qila oladigan bo'lsa, IOS avtomatizatsiyasi uchun foydalidir. Ammo iOS haqida keyingi maqolalarda gaplashamiz. Men har doim vaziyatga qarashni va vazifalardan boshlashni maslahat beraman: ba'zi hollarda ommaviy bulutlardan foydalanish arzonroq va samaraliroq, boshqalarida esa sinov platformalari, albatta, sarflangan pulga arziydi.
Infratuzilmaning hozirgi holatini tasvirlash
Tadqiq qilish uchun havolalar
Shunga o'xshash vositalar:
6. Orkestratsiya
Texnologiyaning qisqacha tavsifi
Menda yaxshi yangilik bor - biz deyarli maqolaning oxiridamiz! Ayni paytda bizning avtomatlashtirish infratuzilmamiz veb va Android testlaridan iborat bo'lib, biz ularni GitLab CI orqali parallel ravishda Docker-ni qo'llab-quvvatlaydigan vositalardan foydalanamiz: Selenium grid va Selenoid. Bundan tashqari, biz brauzerlar va emulyatorlar bilan konteynerlarni joylashtirish uchun GCP orqali yaratilgan virtual mashinalardan foydalanamiz. Xarajatlarni kamaytirish uchun biz ushbu virtual mashinalarni faqat talab bo'yicha ishga tushiramiz va sinov o'tkazilmaganda ularni to'xtatamiz. Bizning infratuzilmamizni yaxshilaydigan boshqa narsa bormi? Javob ha! Kubernetes (K8s) bilan tanishing!
Birinchidan, orkestratsiya, klaster va Kubernetes so'zlari bir-biri bilan qanday bog'liqligini ko'rib chiqaylik. Yuqori darajada, orkestratsiya - bu ilovalarni joylashtiradigan va boshqaradigan tizim. Sinovni avtomatlashtirish uchun bunday konteynerli ilovalar Selenium grid va Selenoid hisoblanadi. Docker va K8 bir-birini to'ldiradi. Birinchisi dasturni joylashtirish uchun, ikkinchisi orkestratsiya uchun ishlatiladi. O'z navbatida, K8s klasterdir. Klasterning vazifasi bir server (klaster) ichida turli funksiyalarni, dasturlarni va xizmatlarni o'rnatish imkonini beruvchi VM-larni tugunlar sifatida ishlatishdir. Agar tugunlardan birortasi ishlamay qolsa, boshqa tugunlar ishga tushadi, bu bizning ilovamizning uzluksiz ishlashini ta'minlaydi. Bunga qo'shimcha ravishda, K8s masshtablash bilan bog'liq muhim funksionallikka ega, buning yordamida biz yuk va cheklovlar asosida avtomatik ravishda resurslarning optimal miqdorini olamiz.
Darhaqiqat, Kubernetes-ni noldan qo'lda joylashtirish umuman ahamiyatsiz ish emas. Men mashhur "Kubernetes The Hard Way" qo'llanmasiga havola qoldiraman va agar qiziqsangiz, uni mashq qilishingiz mumkin. Ammo, xayriyatki, muqobil usullar va vositalar mavjud. Eng oson yo'li - GCP-da Google Kubernetes Engine (GKE) dan foydalanish, bu sizga bir necha marta bosish orqali tayyor klasterni olish imkonini beradi. Men o'rganishni boshlash uchun ushbu yondashuvdan foydalanishni tavsiya etaman, chunki bu ichki komponentlar bir-biri bilan qanday integratsiya qilinishini o'rganish o'rniga, K8-larni o'z vazifalaringiz uchun qanday ishlatishni o'rganishga e'tibor qaratishga imkon beradi.
Avtomatlashtirish infratuzilmasi uchun qiymat
Keling, K8s taqdim etadigan bir nechta muhim xususiyatlarni ko'rib chiqaylik:
- ilovalarni joylashtirish: VMlar o'rniga ko'p tugunli klasterdan foydalanish;
- dinamik masshtablash: faqat talab bo'yicha foydalaniladigan resurslar narxini pasaytiradi;
- o'z-o'zini davolash: podlarni avtomatik ravishda tiklash (buning natijasida konteynerlar ham tiklanadi);
- yangilanishlarni ishga tushirish va o'zgarishlarni uzilishlarsiz qaytarish: asboblar, brauzerlar va emulyatorlarni yangilash joriy foydalanuvchilarning ishini to'xtatmaydi
Ammo K8s hali ham kumush o'q emas. Biz ko'rib chiqayotgan vositalar (Selenium grid, Selenoid) kontekstidagi barcha afzalliklar va cheklovlarni tushunish uchun biz K8 ning tuzilishini qisqacha muhokama qilamiz. Klaster ikkita turdagi tugunlarni o'z ichiga oladi: asosiy tugunlar va ishchi tugunlar. Asosiy tugunlar boshqaruv, joylashtirish va rejalashtirish qarorlari uchun javobgardir. Ishchi tugunlari ilovalar ishga tushiriladigan joydir. Tugunlarda konteynerning ishlash vaqti muhiti ham mavjud. Bizning holatda, bu konteyner bilan bog'liq operatsiyalar uchun javobgar bo'lgan Docker. Ammo, masalan, muqobil echimlar ham mavjud. O'lchov yoki o'z-o'zini davolash to'g'ridan-to'g'ri idishlarga taalluqli emasligini tushunish muhimdir. Bu o'z navbatida konteynerlarni o'z ichiga olgan podalar sonini qo'shish/kamaytirish orqali amalga oshiriladi (odatda har bir podda bitta idish, lekin vazifaga qarab ko'proq bo'lishi mumkin). Yuqori darajadagi ierarxiya ishchi tugunlardan iborat bo'lib, ularning ichida podalar mavjud bo'lib, ular ichida konteynerlar ko'tariladi.
Masshtablash xususiyati asosiy hisoblanadi va uni klasterdagi tugunlar havzasidagi ikkala tugunga ham, tugun ichidagi podkalarga ham qo'llash mumkin. Ham tugunlar, ham podalar uchun qo'llaniladigan 2 turdagi masshtablash mavjud. Birinchi tur gorizontal - masshtablash tugunlar/podlar sonini ko'paytirish orqali sodir bo'ladi. Ushbu turga ko'proq afzallik beriladi. Ikkinchi tur, shunga ko'ra, vertikaldir. Masshtablash tugunlar/podkalar sonini emas, balki hajmini oshirish orqali amalga oshiriladi.
Endi yuqoridagi atamalar kontekstida bizning vositalarimizni ko'rib chiqamiz.
Selenli tarmoq
Yuqorida aytib o'tganimizdek, Selenli panjara juda mashhur vosita bo'lib, uning konteynerlanganligi ajablanarli emas. Shuning uchun, Selenium tarmog'ini K8-larda joylashtirish mumkinligi ajablanarli emas. Buni qanday qilish kerakligi haqidagi misolni rasmiy K8s omborida topish mumkin. Odatdagidek, men bo'lim oxirida havolalarni biriktiraman. Bunga qo'shimcha ravishda, Terraformda buni qanday qilish kerakligi ko'rsatmasi ko'rsatilgan. Brauzer konteynerlarini o'z ichiga olgan podalar sonini qanday o'lchash bo'yicha ko'rsatmalar ham mavjud. Ammo K8 kontekstida avtomatik masshtablash funktsiyasi hali ham to'liq aniq vazifa emas. Men o'qishni boshlaganimda hech qanday amaliy yo'l-yo'riq yoki tavsiyalarni topa olmadim. DevOps jamoasi ko'magida bir nechta tadqiqotlar va tajribalardan so'ng biz bitta ishchi tugun ichida joylashgan bitta pod ichidagi kerakli brauzerlar bilan konteynerlarni ko'tarish yondashuvini tanladik. Bu usul tugunlarning sonini ko'paytirish orqali gorizontal masshtablash strategiyasini qo'llash imkonini beradi. Umid qilamanki, bu kelajakda o'zgaradi va biz yanada yaxshi yondashuvlar va tayyor echimlarning tavsiflarini ko'ramiz, ayniqsa Selenium grid 4 o'zgartirilgan ichki arxitektura bilan chiqarilgandan keyin.
Selenoid:
K8-larda selenoidni joylashtirish hozirda eng katta umidsizlikdir. Ular mos kelmaydi. Nazariy jihatdan, biz Selenoid konteynerini podning ichida ko'tarishimiz mumkin, ammo Selenoid brauzerlar bilan konteynerlarni ishga tushirganda, ular hali ham bir xil pod ichida bo'ladi. Bu masshtablashni imkonsiz qiladi va natijada klaster ichidagi Selenoid ishi virtual mashina ichidagi ishdan farq qilmaydi. Hikoyaning oxiri.
oy:
Selenoid bilan ishlashda ushbu muammoni bilib, ishlab chiquvchilar Moon deb nomlangan yanada kuchli vositani chiqardilar. Ushbu vosita dastlab Kubernetes bilan ishlash uchun mo'ljallangan va natijada avtomatik o'lchov xususiyatidan foydalanish mumkin va kerak. Qolaversa, hozirda shunday deyman yakka Selen dunyosidagi K8s klasterini qo'llab-quvvatlaydigan vosita (endi mavjud emas, keyingi vositaga qarang ). Ushbu yordamni ta'minlaydigan Oyning asosiy xususiyatlari:
To'liq fuqaroligi yo'q. Selenoid hozirda ishlayotgan brauzer seanslari haqidagi ma'lumotlarni xotirada saqlaydi. Agar biron sababga ko'ra uning jarayoni ishlamay qolsa - barcha ishlaydigan seanslar yo'qoladi. Oy, aksincha, ichki holatga ega emas va uni ma'lumotlar markazlarida ko'paytirish mumkin. Brauzer seanslari bir yoki bir nechta replika ishlamay qolsa ham tirik qoladi.
Shunday qilib, Oy - bu ajoyib yechim, lekin bitta muammo bor: u bepul emas. Narx seanslar soniga bog'liq. Siz faqat 0-4 seansni bepul bajarishingiz mumkin, bu ayniqsa foydali emas. Ammo, beshinchi sessiyadan boshlab, har biri uchun 5 dollar to'lashingiz kerak bo'ladi. Vaziyat kompaniyadan kompaniyaga farq qilishi mumkin, ammo bizning holatlarimizda Oydan foydalanish ma'nosizdir. Yuqorida aytib o'tganimdek, biz talabga binoan Selenium Grid bilan VM-larni ishga tushirishimiz yoki klasterdagi tugunlar sonini ko'paytirishimiz mumkin. Taxminan bitta quvur liniyasi uchun biz 500 ta brauzerni ishga tushiramiz va sinovlar tugagandan so'ng barcha resurslarni to'xtatamiz. Agar biz Oydan foydalansak, testlarni qanchalik tez-tez o'tkazmasak ham, oyiga qo'shimcha 500 x 5 = 2500 dollar to'lashimiz kerak edi. Yana, men Oyni ishlatmang, demayman. Sizning vazifalaringiz uchun bu ajralmas yechim bo'lishi mumkin, masalan, tashkilotingizda ko'plab loyihalar/jamoalar mavjud bo'lsa va sizga hamma uchun katta umumiy klaster kerak bo'lsa. Har doimgidek, men oxirida havolani qoldiraman va sizning vazifangiz kontekstida barcha kerakli hisob-kitoblarni bajarishni tavsiya qilaman.
Callisto(Diqqat! Bu asl maqolada emas va faqat rus tilidagi tarjimada mavjud)
Aytganimdek, Selenium juda mashhur vosita va IT sohasi juda tez rivojlanmoqda. Men tarjima ustida ishlayotganimda, Internetda Callisto deb nomlangan yangi istiqbolli vosita paydo bo'ldi (salom Cypress va boshqa Selenium qotillari). U K8 bilan ishlaydi va Selenoid konteynerlarini tugunlar bo'ylab taqsimlangan podlarda ishlatishga imkon beradi. Avtomatik o'lchovni o'z ichiga olgan holda, hamma narsa darhol ishlaydi. Ajoyib, lekin sinab ko'rish kerak. Men allaqachon ushbu vositani ishga tushirishga va bir nechta tajribalarni o'tkazishga muvaffaq bo'ldim. Ammo uzoq masofadan natijalarni olgandan so'ng, xulosa chiqarishga hali erta, ehtimol men keyingi maqolalarda ko'rib chiqaman. Hozircha men faqat mustaqil tadqiqot uchun havolalarni qoldiraman.
Infratuzilmaning hozirgi holatini tasvirlash
Tadqiq qilish uchun havolalar
Shunga o'xshash vositalar
7. Infratuzilma kod sifatida (IaC)
Texnologiyaning qisqacha tavsifi
Va endi biz oxirgi qismga keldik. Odatda, bu texnologiya va tegishli vazifalar avtomatlashtirish muhandislarining mas'uliyati emas. Va buning sabablari bor. Birinchidan, ko'pgina tashkilotlarda infratuzilma masalalari DevOps bo'limining nazorati ostida va ishlab chiqish guruhlari quvurni nima qilishiga va u bilan bog'liq bo'lgan hamma narsani qanday qo'llab-quvvatlashga muhtojligi haqida umuman ahamiyat bermaydilar. Ikkinchidan, rostini aytsam, Infratuzilmani Kodeks (IaC) amaliyoti hali ko'p kompaniyalarda qabul qilinmagan. Ammo bu, albatta, mashhur tendentsiyaga aylandi va u bilan bog'liq jarayonlar, yondashuvlar va vositalarda ishtirok etishga harakat qilish muhimdir. Yoki hech bo'lmaganda yangiliklardan xabardor bo'ling.
Keling, ushbu yondashuvdan foydalanish motivatsiyasidan boshlaylik. Biz allaqachon GitlabCI-da testlarni o'tkazish uchun Gitlab Runner-ni ishga tushirish uchun hech bo'lmaganda resurslar kerak bo'lishini muhokama qildik. Brauzerlar/emulatorlar bilan konteynerlarni ishga tushirish uchun biz VM yoki klasterni zaxiralashimiz kerak. Resurslarni sinab ko'rishdan tashqari, ishlab chiqish, bosqichma-bosqich, ishlab chiqarish muhitini qo'llab-quvvatlash uchun katta hajmdagi imkoniyatlarga muhtojmiz, ular shuningdek ma'lumotlar bazalari, avtomatik jadvallar, tarmoq konfiguratsiyalari, yuk balanslari, foydalanuvchi huquqlari va boshqalarni o'z ichiga oladi. Asosiy masala - bularning barchasini qo'llab-quvvatlash uchun zarur bo'lgan harakat. O'zgartirishlar kiritish va yangilanishlarni chiqarishning bir necha yo'li mavjud. Masalan, GCP kontekstida biz brauzerda UI konsolidan foydalanishimiz va tugmalarni bosish orqali barcha amallarni bajarishimiz mumkin. Bulutli ob'ektlar bilan ishlash uchun API qo'ng'iroqlaridan foydalanish yoki kerakli manipulyatsiyalarni bajarish uchun gcloud buyruq qatori yordam dasturidan foydalanish alternativa bo'ladi. Ammo haqiqatan ham juda ko'p turli xil ob'ektlar va infratuzilma elementlari bilan barcha operatsiyalarni qo'lda bajarish qiyin yoki hatto imkonsiz bo'lib qoladi. Bundan tashqari, ushbu qo'lda bajariladigan barcha harakatlar boshqarilmaydi. Biz ularni bajarishdan oldin ko'rib chiqish uchun yubora olmaymiz, versiyani boshqarish tizimidan foydalana olmaymiz va voqeaga olib kelgan o'zgarishlarni tezda qaytarib bera olmaymiz. Bunday muammolarni hal qilish uchun muhandislar oldingi usullardan unchalik yaxshi bo'lmagan avtomatik bash/shell skriptlarini yaratdilar va yaratadilar, chunki ularni protsessual uslubda tez o'qish, tushunish, saqlash va o'zgartirish oson emas.
Ushbu maqolada va qanday qilish bo'yicha qo'llanmada men IaC amaliyotiga tegishli 2 ta vositadan foydalanaman. Bular Terraform va Ansible. Ba'zi odamlar ularni bir vaqtning o'zida ishlatishning ma'nosi yo'q deb hisoblashadi, chunki ularning funksionalligi o'xshash va ular bir-birini almashtiradi. Ammo haqiqat shundaki, dastlab ularga mutlaqo boshqa vazifalar beriladi. Va bu vositalar bir-birini to'ldirishi kerakligi HashiCorp va RedHat kompaniyasini ishlab chiquvchilarning qo'shma taqdimotida tasdiqlandi. Kontseptual farq shundaki, Terraform serverlarning o'zini boshqarish uchun ta'minlovchi vositadir. Ansible konfiguratsiyani boshqarish vositasi bo'lib, uning vazifasi ushbu serverlarda dasturiy ta'minotni o'rnatish, sozlash va boshqarishdir.
Ushbu vositalarning yana bir asosiy farqlovchi xususiyati kodlash uslubidir. Bash va Ansible'dan farqli o'laroq, Terraform ijro etish natijasida erishiladigan istalgan yakuniy holat tavsifiga asoslangan deklarativ uslubdan foydalanadi. Misol uchun, agar biz 10 ta VM yaratmoqchi bo'lsak va o'zgarishlarni Terraform orqali qo'llamoqchi bo'lsak, u holda biz 10 VM olamiz. Agar biz skriptni qayta ishga tushirsak, hech narsa sodir bo'lmaydi, chunki bizda allaqachon 10 ta VM bor va Terraform bu haqda biladi, chunki u infratuzilmaning joriy holatini davlat faylida saqlaydi. Ammo Ansible protsessual yondashuvdan foydalanadi va agar siz undan 10 ta VM yaratishni so'rasangiz, birinchi ishga tushirishda biz Terraformga o'xshash 10 ta VMni olamiz. Ammo qayta ishga tushirgandan so'ng bizda allaqachon 20 ta VM bo'ladi. Bu muhim farq. Protsessual uslubda biz joriy holatni saqlamaymiz va shunchaki bajarilishi kerak bo'lgan qadamlar ketma-ketligini tasvirlaymiz. Albatta, biz turli vaziyatlarni hal qila olamiz, resurslar mavjudligi va hozirgi holat uchun bir nechta tekshiruvlarni qo'shamiz, ammo vaqtimizni behuda sarflash va bu mantiqni boshqarish uchun kuch sarflashning ma'nosi yo'q. Bundan tashqari, bu xato qilish xavfini oshiradi.
Yuqorida aytilganlarning barchasini umumlashtirib, biz Terraform va deklarativ yozuvlar serverlarni tayyorlash uchun qulayroq vositadir, degan xulosaga kelishimiz mumkin. Ammo konfiguratsiyani boshqarish bo'yicha ishlarni Ansible-ga topshirish yaxshiroqdir. Bu yo'ldan tashqarida, keling, avtomatlashtirish kontekstida foydalanish holatlarini ko'rib chiqaylik.
Avtomatlashtirish infratuzilmasi uchun qiymat
Bu erda tushunish kerak bo'lgan yagona muhim narsa shundaki, sinovni avtomatlashtirish infratuzilmasi butun kompaniya infratuzilmasining bir qismi sifatida ko'rib chiqilishi kerak. Bu shuni anglatadiki, barcha IaC amaliyotlari butun tashkilotning resurslariga global miqyosda qo'llanilishi kerak. Buning uchun kim javobgar bo'lishi sizning jarayonlaringizga bog'liq. DevOps jamoasi bu masalalarda ko'proq tajribaga ega, ular sodir bo'layotgan voqealarning butun rasmini ko'rishadi. Biroq, QA muhandislari qurilishni avtomatlashtirish va quvur liniyasi tuzilishi jarayonida ko'proq ishtirok etadilar, bu ularga barcha kerakli o'zgarishlar va takomillashtirish imkoniyatlarini yaxshiroq ko'rish imkonini beradi. Kutilgan natijaga erishish uchun birgalikda ishlash, bilim va fikr almashish eng yaxshi variantdir.
Testlarni avtomatlashtirish kontekstida Terraform va Ansible-dan foydalanishning bir nechta misollari va biz avval muhokama qilgan vositalar:
1. Terraform yordamida VM va klasterlarning kerakli xarakteristikalari va parametrlarini tavsiflang.
2. Ansible-dan foydalanib, sinov uchun zarur bo'lgan asboblarni o'rnating: docker, Selenoid, Selenium Grid va brauzerlar/emulatorlarning kerakli versiyalarini yuklab oling.
3. Terraform-dan foydalanib, GitLab Runner ishga tushiriladigan VM xususiyatlarini tasvirlab bering.
4. Ansible yordamida GitLab Runner va kerakli qo'shimcha vositalarni o'rnating, sozlamalar va konfiguratsiyalarni o'rnating.
Infratuzilmaning hozirgi holatini tasvirlash
Tadqiq qilish uchun havolalar:
Shunga o'xshash vositalar
Keling, xulosa qilaylik!
qadam
texnologiya
Asboblar
Avtomatlashtirish infratuzilmasi uchun qiymat
1
Mahalliy yugurish
Node.js, Selenium, Appium
- Veb va mobil qurilmalar uchun eng mashhur vositalar
- Ko'p tillar va platformalarni qo'llab-quvvatlaydi (shu jumladan Node.js)
2
Versiyalarni boshqarish tizimlari
borib
- Rivojlanish kodi bilan o'xshash imtiyozlar
3
Konteynerlash
Docker, Selenium grid, Selenoid (veb, Android)
- Testlarni parallel ravishda o'tkazish
- Izolyatsiya qilingan muhitlar
- Oddiy, moslashuvchan versiyani yangilash
- Ishlatilmagan resurslarni dinamik ravishda to'xtatish
- O'rnatish oson
4
CI/CD
Gitlab CI
- Quvurning bir qismini sinovdan o'tkazadi
- Bystraya obratnaya svyaz
- Butun kompaniya/jamoa uchun ko'rinish
5
Bulutli platformalar
Google Cloud Platform
- Talab bo'yicha manbalar (faqat kerak bo'lganda to'laymiz)
- Boshqarish va yangilash oson
- Barcha resurslarni ko'rish va nazorat qilish
6
Orkestratsiya
Kubernetes
Podlar ichidagi brauzerlar/emulatorlar bo'lgan konteynerlar kontekstida:
- Masshtablash/avtomatik masshtablash
- O'z-o'zini davolash
- Uzluksiz yangilanishlar va orqaga qaytarish
7
Infratuzilma kod sifatida (IaC)
Terraform, Ansible
- Rivojlanish infratuzilmasi bilan o'xshash imtiyozlar
- Kod versiyasini yaratishning barcha afzalliklari
- O'zgartirishlar kiritish va saqlash oson
- To'liq avtomatlashtirilgan
Aql xaritasi diagrammalari: infratuzilma evolyutsiyasi
1-qadam: Mahalliy
2-qadam: VCS
3-qadam: konteynerlashtirish
4-qadam: CI/CD
5-qadam: Bulutli platformalar
6-qadam: Orkestratsiya
7-qadam: IaC
Keyin nima?
Shunday qilib, bu maqolaning oxiri. Lekin xulosa qilib, men siz bilan ba'zi shartnomalar tuzmoqchiman.
Siz tomondan
Boshida aytganimdek, maqola amaliy ahamiyatga ega bo'lishini va olingan bilimlarni haqiqiy ishda qo'llashingizga yordam berishini istardim. Yana qo'shaman.
Ammo bundan keyin ham to'xtamang, mashq qiling, tegishli havolalar va kitoblarni o'rganing, kompaniyangizda qanday ishlashini bilib oling, yaxshilanishi mumkin bo'lgan joylarni toping va unda ishtirok eting. Omad!
Men tomondan
Sarlavhadan bu faqat birinchi qism ekanligini ko'rishingiz mumkin. Bu juda katta bo'lganiga qaramay, bu erda hali ham muhim mavzular yoritilmagan. Ikkinchi qismda men IOS kontekstida avtomatlashtirish infratuzilmasini ko'rib chiqishni rejalashtirmoqdaman. Apple tomonidan iOS simulyatorlarini faqat macOS tizimlarida ishga tushirish cheklovlari tufayli yechimlarimiz doirasi toraydi. Masalan, biz simulyatorni ishlatish uchun Docker-dan yoki virtual mashinalarni ishga tushirish uchun umumiy bulutlardan foydalana olmaymiz. Ammo bu boshqa alternativalar yo'q degani emas. Men sizni ilg'or echimlar va zamonaviy vositalar bilan xabardor qilishga harakat qilaman!
Bundan tashqari, men monitoring bilan bog'liq juda katta mavzularni eslatmadim. 3-qismda men eng mashhur infratuzilma monitoringi vositalarini va qanday ma'lumotlar va ko'rsatkichlarni hisobga olishni ko'rib chiqaman.
Va nihoyat. Kelajakda men test infratuzilmasi va ommabop vositalarni yaratish bo'yicha video kurs chiqarishni rejalashtirmoqdaman. Hozirda Internetda DevOps bo'yicha juda ko'p kurslar va ma'ruzalar mavjud, ammo barcha materiallar testlarni avtomatlashtirish emas, balki ishlab chiqish kontekstida taqdim etiladi. Ushbu masala bo'yicha menga bunday kurs sinovchilar va avtomatlashtirish muhandislari jamoasi uchun qiziqarli va qimmatli bo'ladimi yoki yo'qmi degan fikr-mulohazalarga muhtojman. Oldindan rahmat!
Manba: www.habr.com