1-бөлүк: Веб/Android
пикир: бул макала оригиналдуу макаланын орус тилине котормосу Бирок бардык иллюстрациялар, шилтемелер, цитаталар жана терминдер орус тилине которгондо маанисин бурмалоого жол бербөө үчүн түпнуска тилинде сакталган. Мен сага бактылуу окуу каалайм!
Учурда DevOps адистиги IT тармагында эң көп талап кылынган адистиктердин бири. Эгер сиз популярдуу жумуш издөө сайттарын ачып, айлык акы боюнча чыпкаласаңыз, DevOps менен байланышкан жумуштар тизменин башында турганын көрөсүз. Бирок, бул, негизинен, талапкердин шык-жөндөмүнүн, технологиянын жана инструменттердин билиминин жогорку деңгээлине ээ экендигин билдирген "Улук" кызматка тиешелүү экенин түшүнүү маанилүү. Бул да өндүрүштүн үзгүлтүксүз иштеши менен байланышкан жогорку жоопкерчилик менен келет. Бирок, биз DevOps деген эмне экенин унута баштадык. Башында бул кандайдыр бир конкреттүү адам же бөлүм болгон эмес. Бул терминдин аныктамаларын издесек, методология, практика, маданий философия, түшүнүктөр тобу ж.б.у.с көптөгөн кооз жана туура атоочторду табабыз.
Менин адистигим - бул тесттик автоматташтыруу боюнча инженер (QA автоматташтыруу инженери), бирок мен аны автотесттерди жазуу же тест структурасынын архитектурасын иштеп чыгуу менен гана байланыштырбоо керек деп эсептейм. 2020-жылы автоматташтыруу инфраструктурасын билүү да маанилүү. Бул автоматташтыруу процессин өз алдынча уюштурууга мүмкүндүк берет, тесттерди жүргүзүүдөн баштап, бардык кызыкдар тараптарга максаттарыңызга ылайык натыйжаларды берүүгө чейин. Натыйжада, DevOps жөндөмдөрү жумушту бүтүрүү үчүн зарыл. Мунун баары жакшы, бирок, тилекке каршы, көйгөй бар (спойлер: бул макалада бул көйгөйдү жөнөкөйлөтүү аракети). Кеп DevOps кыйын экендигинде. Жана бул айдан ачык, анткени компаниялар оңой жасала турган нерсе үчүн көп акча төлөбөйт... DevOps дүйнөсүндө өздөштүрүү керек болгон көптөгөн куралдар, терминдер жана практикалар бар. Бул мансаптын башында өзгөчө кыйын жана топтолгон техникалык тажрыйбага көз каранды.
Source:
Бул жерде, балким, киришүү бөлүгү менен аяктап, ушул макаланын максатына токтолобуз.
Бул макала эмне жөнүндө?
Бул макалада мен тестти автоматташтыруу инфраструктурасын куруу боюнча тажрыйбам менен бөлүшөм. Интернетте ар кандай инструменттер жана аларды кантип колдонуу керектиги жөнүндө көптөгөн маалымат булактары бар, бирок мен аларды автоматташтыруу контекстинде гана карагым келет. Көптөгөн автоматташтыруу инженерлери сизден башка эч ким иштелип чыккан тесттерди өткөрбөй же аларды сактоого кам көрбөгөн кырдаалды жакшы билишет деп ишенем. Натыйжада, тесттер эскирип, аларды жаңыртууга убакыт коротууга туура келет. Дагы бир жолу, карьеранын башталышында, бул өтө татаал маселе болушу мүмкүн: кайсы куралдар берилген көйгөйдү жоюуга жардам бериши керек, аларды кантип тандоо, конфигурациялоо жана тейлөө керек экендигин акылдуулук менен чечүү. Кээ бир тестерлер DevOps (адамдар) үчүн жардам сурап кайрылышат жана чынын айтсак, бул ыкма иштейт. Көпчүлүк учурларда бул жалгыз вариант болушу мүмкүн, анткени бизде бардык көз карандылыктарды көрүү мүмкүнчүлүгү жок. Бирок биз билгендей, DevOps абдан бош балдар, анткени алар компаниянын инфраструктурасы, жайылтуу, мониторинг, микросервис жана башка ушул сыяктуу милдеттерди уюмга/командага жараша ойлонушу керек. Адатта, автоматташтыруу артыкчылыктуу эмес. Мындай учурда биз башынан аягына чейин өз тарапыбыздан колдон келгендин баарын кылууга аракет кылышыбыз керек. Бул көз карандылыкты азайтат, жумуш процессин тездетет, жөндөмүбүздү өркүндөтөт жана эмне болуп жатканын кененирээк көрүүгө мүмкүнчүлүк берет.
Макалада эң популярдуу жана популярдуу инструменттер берилген жана аларды автоматташтыруу инфраструктурасын этап-этабы менен куруу үчүн кантип колдонуу керектиги көрсөтүлгөн. Ар бир топ жеке тажрыйба аркылуу сыналган куралдар менен көрсөтүлөт. Бирок бул бир эле нерсени колдонуу керек дегенди билдирбейт. Куралдардын өзү маанилүү эмес, алар пайда болуп, эскирип калат. Биздин инженердик милдетибиз негизги принциптерди түшүнүү болуп саналат: бул куралдар тобу эмне үчүн керек жана алардын жардамы менен кандай жумуш көйгөйлөрүн чече алабыз. Ошондуктан ар бир бөлүмдүн аягында мен сиздин уюмда колдонулушу мүмкүн болгон окшош куралдарга шилтемелерди калтырам.
Бул макалада эмне жок
Мен дагы бир жолу кайталайм, макала конкреттүү инструменттер жөнүндө эмес, андыктан документациядан жана конкреттүү буйруктардын сыпаттамаларынан эч кандай коду жок болот. Бирок ар бир бөлүмдүн аягында мен деталдуу изилдөө үчүн шилтемелерди калтырам.
Бул жасалат, анткени:
- бул материалды ар кандай булактардан табуу оңой (документтер, китептер, видео курстар);
- тереңдете баштасак, бул макаланын 10, 20, 30 бөлүгүн жазууга туура келет (пландар 2-3 болсо);
- Мен сиздин убактыңызды текке кетиргим келбейт, анткени сиз ошол эле максаттарга жетүү үчүн башка куралдарды колдонгуңуз келет.
практика
Бул материал жөн эле окуп, унутулуп калбастан, ар бир окурман үчүн пайдалуу болушун каалайт элем. Ар кандай изилдөөдө практика абдан маанилүү компонент болуп саналат. Бул үчүн мен даярдадым. Сиз аткарып жаткан буйруктардын саптарын ойлонбой көчүрүп албашыңыз үчүн үй тапшырмасы дагы бар.
план
кадам
технология
аспаптар
1
Жергиликтүү чуркоо (веб/андроид демо тесттерин даярдап, аны жергиликтүү иштетиңиз)
Node.js, Selenium, Appium
2
Версияларды башкаруу системалары
барып,
3
Контейнерлештирүү
Docker, Selenium тор, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Булут платформалары
Google Cloud Platform
6
айкалыштыруу
Kubernetes
7
Инфраструктура код катары (IaC)
Terraform, Ansible
Ар бир бөлүмдүн түзүмү
Баяндоону так сактоо үчүн, ар бир бөлүм төмөнкү схемага ылайык сүрөттөлөт:
- технологиянын кыскача баяндамасы,
- автоматташтыруу инфраструктурасынын мааниси,
- инфраструктуранын учурдагы абалын чагылдыруу,
- окуу үчүн шилтемелер,
- окшош аспаптар.
1. Тесттерди жергиликтүү түрдө иштетиңиз
Технологиянын кыскача баяндамасы
Бул жергиликтүү демо тесттерди жүргүзүү жана алардын өткөнүн текшерүү үчүн даярдык кадамы. Практикалык бөлүгүндө Node.js колдонулат, бирок программалоо тили жана платформасы да маанилүү эмес жана сиз компанияңызда колдонулгандарды колдоно аласыз.
Бирок, автоматташтыруу куралдары катары мен веб-платформалар үчүн Selenium WebDriver жана Android платформалары үчүн Appium колдонууну сунуштайм, анткени кийинки кадамдарда биз бул куралдар менен атайын иштөөгө ылайыкташтырылган Docker сүрөттөрүн колдонобуз. Мындан тышкары, жумуш талаптарын эске алуу менен, бул аспаптар рынокто суроо-талапка ээ.
Сиз байкагандай, биз веб жана Android тесттерин гана карайбыз. Тилекке каршы, iOS такыр башка окуя (Apple үчүн рахмат). Мен алдыдагы бөлүктөрдө IOS менен байланышкан чечимдерди жана тажрыйбаларды көрсөтүүнү пландап жатам.
Автоматташтыруу инфраструктурасынын мааниси
Инфраструктуралык көз караштан алганда, жергиликтүү иштетүү эч кандай маани бербейт. Сыноолор жергиликтүү браузерлерде жана симуляторлордо жергиликтүү машинада аткарылгандыгын текшересиз. Бирок, кандай болгон күндө да, бул зарыл баштапкы чекит болуп саналат.
Инфраструктуранын учурдагы абалынын иллюстрациясы
Изилдөө үчүн шилтемелер
Окшош куралдар
- Selenium/Appium тесттери менен бирге каалаган программалоо тили;
- ар кандай сыноолор;
- ар кандай сыноочу.
2. Версияларды башкаруу системалары (Git)
Технологиянын кыскача баяндамасы
Эгерде мен версияны башкаруу командада дагы, жекече дагы өнүгүүнүн өтө маанилүү бөлүгү деп айтсам, бул эч кимге чоң ачылыш болбойт. Ар кандай булактардын негизинде Гит эң популярдуу өкүл деп айтууга болот. Версияларды башкаруу системасы кодду бөлүшүү, версияларды сактоо, мурунку бутактарга калыбына келтирүү, долбоордун тарыхын көзөмөлдөө жана резервдик көчүрмөлөр сыяктуу көптөгөн артыкчылыктарды берет. Ар бир пунктту майда-чүйдөсүнө чейин талкуулабайбыз, анткени сиз аны абдан жакшы билесиз жана күнүмдүк ишиңизде колдоносуз деп ишенем. Бирок күтүлбөгөн жерден жок болсо, анда мен бул макаланы окууну токтотуп, мүмкүн болушунча тезирээк бул боштукту толтурууну сунуштайм.
Автоматташтыруу инфраструктурасынын мааниси
Бул жерде сиз акылга сыярлык суроо бере аласыз: "Эмне үчүн ал бизге Гит жөнүндө айтып жатат? Муну баары билет жана аны иштеп чыгуу коду үчүн да, авто-тест коду үчүн да колдонот." Сиз таптакыр туура айтасыз, бирок бул макалада биз инфраструктура жөнүндө сөз кылып жатабыз жана бул бөлүм 7-бөлүмдүн алдын ала көрүү функциясын аткарат: “Инфраструктура код катары (IaC)”. Биз үчүн бул бүткүл инфраструктура, анын ичинде тестирлөө код түрүндө сүрөттөлгөндүгүн билдирет, ошондуктан биз ага версия системаларын колдоно алабыз жана иштеп чыгуу жана автоматташтыруу кодуна окшош артыкчылыктарды ала алабыз.
Биз 7-кадамда IaCды кененирээк карап чыгабыз, бирок азыр да жергиликтүү репозиторийди түзүү менен Gitти жергиликтүү түрдө колдоно баштасаңыз болот. Биз инфраструктурага алыскы репозиторийди кошкондо чоң сүрөт кеңейет.
Инфраструктуранын учурдагы абалынын иллюстрациясы
Изилдөө үчүн шилтемелер
Окшош куралдар
3. Контейнерлештирүү (Докер)
Технологиянын кыскача баяндамасы
Контейнерлөө оюндун эрежелерин кандайча өзгөрткөнүн көрсөтүү үчүн, келгиле, бир нече ондогон жылдарга артка кайрылалы. Ал кезде адамдар тиркемелерди иштетүү үчүн сервердик машиналарды сатып алып, колдонушкан. Бирок көпчүлүк учурларда, талап кылынган баштоо ресурстары алдын ала белгилүү болгон эмес. Натыйжада, компаниялар кымбат, күчтүү серверлерди сатып алууга акча коротушту, бирок бул кубаттуулуктун бир бөлүгү толук пайдаланылган эмес.
Эволюциянын кийинки этабы пайдаланылбаган ресурстарга акчаны ысырап кылуу маселесин чечкен виртуалдык машиналар (VM) болгон. Бул технология толугу менен обочолонгон мейкиндикти бөлүп, бир сервердин ичинде тиркемелерди бири-биринен көз карандысыз иштетүүгө мүмкүндүк берди. Бирок, тилекке каршы, ар кандай технология өзүнүн кемчиликтери бар. VM иштетүү үчүн процессорду, оперативдүү эстутумду, сактагычты сарптаган толук операциялык система талап кылынат жана ОСке жараша лицензиялык чыгымдар эске алынышы керек. Бул факторлор жүктөө ылдамдыгына таасир этет жана көчүрүүнү кыйындатат.
Ал эми азыр биз контейнерлештирүү үчүн келдик. Дагы бир жолу айта кетейин, бул технология мурунку көйгөйдү чечет, анткени контейнерлер толук көлөмдөгү ОСти колдонбойт, бул чоң көлөмдөгү ресурстарды бошотуп, портативдик үчүн тез жана ийкемдүү чечимди камсыз кылат.
Албетте, контейнерлөө технологиясы жаңы эч нерсе эмес жана биринчи жолу 70-жылдардын аягында киргизилген. Ошол күндөрү көптөгөн изилдөөлөр, иштеп чыгуулар, аракеттер жасалды. Бирок бул технологияны ыңгайлаштырган жана аны массага оңой жеткиликтүү кылган Докер болгон. Бүгүнкү күндө биз контейнерлер жөнүндө сөз кылганда, көпчүлүк учурда биз Докерди түшүнөбүз. Docker контейнерлери жөнүндө сөз кылганда, биз Linux контейнерлерин билдирет. Контейнерлерди иштетүү үчүн Windows жана macOS системаларын колдоно алабыз, бирок бул учурда кошумча катмар пайда болорун түшүнүү маанилүү. Мисалы, Macтагы Docker жеңил Linux VM ичиндеги контейнерлерди унчукпай иштетет. Контейнерлердин ичинде Android эмуляторлорун иштетүүнү талкуулаганда биз бул темага кайрылып келебиз, ошондуктан бул жерде кененирээк талкууланышы керек болгон абдан маанилүү нюанс бар.
Автоматташтыруу инфраструктурасынын мааниси
Контейнерлөө жана Докер сонун экенин билдик. Келгиле, муну автоматташтыруу контекстинде карап көрөлү, анткени ар бир инструмент же технология көйгөйдү чечиши керек. Келгиле, UI тесттеринин контекстинде тестти автоматташтыруунун айкын көйгөйлөрүн белгилейли:
- Selenium жана өзгөчө Appium орнотууда көз карандылыктын көп саны;
- браузерлердин, симуляторлордун жана драйверлердин версияларынын ортосундагы шайкештик көйгөйлөрү;
- браузерлер/симуляторлор үчүн обочолонгон мейкиндиктин жоктугу, бул параллелдүү иштөө үчүн өзгөчө маанилүү;
- бир эле учурда 10, 50, 100 же ал тургай 1000 браузерди иштетүү керек болсо, башкаруу жана тейлөө кыйын.
Бирок Selenium эң популярдуу автоматташтыруу куралы жана Docker эң популярдуу контейнерлештирүү куралы болгондуктан, кимдир бирөө жогоруда айтылган көйгөйлөрдү чечүү үчүн күчтүү куралды түзүү үчүн аларды бириктирүүгө аракет кылганы таң калыштуу эмес. Мындай чечимдерди кененирээк карап көрөлү.
Докердеги селен тор
Бул курал бир нече машиналарда бир нече браузерлерди иштетүү жана аларды борбордук борбордон башкаруу үчүн Selenium дүйнөсүндө эң популярдуу. Баштоо үчүн, сиз жок дегенде 2 бөлүктөн каттоодон өтүшүңүз керек: Hub жана Node(лер). Hub - бул тесттерден келген бардык сурамдарды кабыл алган жана аларды тиешелүү Түйүндөргө таратуучу борбордук түйүн. Ар бир түйүн үчүн биз белгилүү бир конфигурацияны конфигурациялай алабыз, мисалы, каалаган браузерди жана анын версиясын көрсөтүү менен. Бирок, биз дагы эле шайкеш келген браузердин драйверлерине өзүбүз кам көрүп, аларды керектүү түйүндөргө орнотушубуз керек. Ушул себептен улам, Selenium тор, Linux OS орнотууга мүмкүн эмес браузерлер менен иштөө үчүн зарыл болгон учурлардан тышкары, анын таза түрүндө колдонулбайт. Башка бардык учурларда, Selenium тордун Hub жана түйүндөрүн иштетүү үчүн Docker сүрөттөрүн колдонуу кыйла ийкемдүү жана туура чечим болмок. Бул ыкма түйүндөрдү башкарууну абдан жөнөкөйлөтөт, анткени биз керектүү сүрөттү мурунтан орнотулган браузерлердин жана драйверлердин шайкеш версиялары менен тандай алабыз.
Туруктуулук жөнүндө терс сын-пикирлерге карабастан, айрыкча көп сандагы түйүндөрдү параллелдүү иштеткенде, Selenium торлору дагы эле Selenium тесттерин параллелдүү жүргүзүү үчүн эң популярдуу курал болуп саналат. Бул инструменттин ар кандай өркүндөтүлүшү жана модификациялары ар кандай тоскоолдуктар менен күрөшкөн ачык булакта дайыма пайда болуп жаткандыгын белгилей кетүү маанилүү.
Веб үчүн Selenoid
Бул курал Selenium дүйнөсүндөгү ачылыш болуп саналат, анткени ал кутудан чыгып иштейт жана көптөгөн автоматика инженерлеринин жашоосун бир топ жеңилдетти. Биринчиден, бул Selenium тордун дагы бир өзгөртүү эмес. Анын ордуна, иштеп чыгуучулар Голангда Selenium Hubтын таптакыр жаңы версиясын түзүштү, ал ар кандай браузерлер үчүн жеңил салмактагы Docker сүрөттөрү менен айкалышып, тесттик автоматташтырууну өнүктүрүүгө түрткү берди. Мындан тышкары, Selenium Grid учурда, биз бардык керектүү браузерлерди жана алардын версияларын алдын ала аныкташыбыз керек, бул бир гана браузер менен иштөөдө көйгөй эмес. Бирок бир нече колдоого алынган браузерлер жөнүндө сөз болгондо, Selenoid "талап боюнча браузер" өзгөчөлүгүнүн аркасында биринчи орунда турат. Бизден талап кылынган нерсе - алдын ала браузерлер менен керектүү сүрөттөрдү жүктөп алуу жана Selenoid менен иштешкен конфигурация файлын жаңыртуу. Selenoid тесттерден суроо-талапты алгандан кийин, ал автоматтык түрдө керектүү контейнерди керектүү браузер менен ишке киргизет. Сыноо аяктагандан кийин, Selenoid контейнерди токтотуп, келечектеги суроо-талаптар үчүн ресурстарды бошотот. Бул ыкма Selenium тармагында биз көп жолуккан "түйүндөрдүн деградациясынын" белгилүү көйгөйүн толугу менен жок кылат.
Бирок, тилекке каршы, Селеноид дагы эле күмүш ок эмес. Биз "талап боюнча браузер" функциясын алдык, бирок "суроо боюнча ресурстар" функциясы дагы эле жеткиликтүү эмес. Selenoidди колдонуу үчүн, биз аны физикалык жабдыкка же VMге жайгаштырышыбыз керек, демек, канча ресурстар бөлүнүшү керектигин алдын ала билишибиз керек. Менимче, бул 10, 20 же 30 браузерди параллелдүү иштеткен чакан долбоорлор үчүн көйгөй эмес. Бирок бизге 100, 500, 1000 же андан көп керек болсочу? Дайыма ушунча көп ресурстарды сактап, төлөөнүн мааниси жок. Бул макаланын 5 жана 6-бөлүктөрүндө биз масштабдуу болууга мүмкүндүк берген чечимдерди талкуулайбыз, ошону менен компаниянын чыгымдарын бир топ кыскартат.
Android үчүн Selenoid
Selenoid веб автоматташтыруу куралы катары ийгилигинен кийин, адамдар Android үчүн окшош нерсени каалашкан. Жана бул болду - Selenoid Android колдоосу менен чыгарылган. Жогорку деңгээлдеги колдонуучулардын көз карашы боюнча, иштөө принциби веб автоматташтырууга окшош. Бир гана айырмасы, браузердин контейнерлеринин ордуна Selenoid Android эмулятор контейнерлерин иштетет. Менин оюмча, бул учурда Android тесттерин параллелдүү жүргүзүү үчүн эң күчтүү акысыз курал.
Мен бул куралдын терс жактары жөнүндө айткым келбейт, анткени мен аны абдан жакшы көрөм. Ошентсе да, веб автоматташтырууга тиешелүү жана масштабдоо менен байланышкан кемчиликтер бар. Мындан тышкары, биз куралды биринчи жолу орнотуп жаткан болсок, таң калыштуу болушу мүмкүн болгон дагы бир чектөө жөнүндө сөз кылышыбыз керек. Android сүрөттөрүн иштетүү үчүн бизге физикалык машина же ички виртуалдаштыруу колдоосу менен VM керек. Кантип көрсөтмөсүндө мен муну Linux VM'де кантип иштетүү керектигин көрсөтөм. Бирок, эгер сиз MacOS колдонуучусу болсоңуз жана Selenoidди локалдык түрдө жайгаштыргыңыз келсе, анда Android тесттерин иштетүү мүмкүн эмес. Бирок сиз ар дайым конфигурацияланган "уяланган виртуалдаштыруу" менен Linux VMди иштетип, ичинде Selenoidди орното аласыз.
Инфраструктуранын учурдагы абалынын иллюстрациясы
Бул макаланын контекстинде биз инфраструктураны иллюстрациялоо үчүн 2 куралды кошобуз. Бул веб-тесттер үчүн Selenium торлору жана Android тесттери үчүн Selenoid. GitHub окуу куралында мен сизге Selenoidди веб тесттерди жүргүзүү үчүн кантип колдонууну көрсөтөм.
Изилдөө үчүн шилтемелер
Окшош куралдар
- Башка контейнерлөө куралдары бар, бирок Docker эң популярдуу. Эгер сиз дагы бир нерсени сынап көргүңүз келсе, Selenium тесттерин параллелдүү жүргүзүү үчүн биз камтылган куралдар кутудан чыкпай турганын унутпаңыз.
- Жогоруда айтылгандай, Selenium торунун көптөгөн модификациялары бар, мисалы,.
4.CI/CD
Технологиянын кыскача баяндамасы
Үзгүлтүксүз интеграция практикасы иштеп чыгууда абдан популярдуу жана версияларды башкаруу системалары менен бирдей. Ошого карабастан терминологияда баш аламандык бар экенин сезем. Бул пунктта мен өз көз карашым боюнча бул технологиянын 3 модификациясын сүрөттөгүм келет. Интернетте сиз ар кандай чечмелөө менен көптөгөн макалаларды таба аласыз жана сиздин пикириңиз башкача болсо, бул нормалдуу көрүнүш. Эң негизгиси кесиптештериңиз менен бир бетке экениңиз.
Ошентип, 3 термин бар: CI - үзгүлтүксүз интеграция, CD - үзгүлтүксүз жеткирүү жана дагы CD - үзгүлтүксүз жайылтуу. (Төмөндө мен бул терминдерди англис тилинде колдоном). Ар бир өзгөртүү сиздин иштеп чыгуу каналыңызга бир нече кошумча кадамдарды кошот. Бирок сөз тынымсыз (үзгүлтүксүз) эң маанилүү нерсе. Бул контекстте биз башынан аягына чейин үзгүлтүксүз же кол кийлигишүүсүз боло турган нерсени айтабыз. Бул контекстте CI & CD жана CDди карап көрөлү.
- Үзгүлтүксүз интеграция бул эволюциянын алгачкы кадамы. Серверге жаңы кодду тапшыргандан кийин, биз өзгөртүүлөрүбүз туура экени тууралуу тез пикир алабыз деп күтөбүз. Адатта, CI статикалык кодду талдоо куралдарын жана бирдик/ички API тесттерин камтыйт. Бул бизге кодубуз жөнүндө маалыматты бир нече секунд/мүнөт ичинде алууга мүмкүндүк берет.
- үзгүлтүксүз жеткирүү интеграция/UI тесттерин жүргүзө турган өнүккөн кадам. Бирок, бул этапта биз CI сыяктуу тез натыйжаларды ала албайбыз. Биринчиден, бул сыноолордун түрлөрүн аяктоо үчүн көбүрөөк убакыт талап кылынат. Экинчиден, ишке киргизүүдөн мурун, биз өзгөртүүлөрүбүздү сыноо/сценировка чөйрөсүнө киргизишибиз керек. Андан тышкары, эгерде биз мобилдик өнүктүрүү жөнүндө сөз кыла турган болсок, анда биздин тиркеменин түзүмүн түзүү үчүн кошумча кадам пайда болот.
- Үзгүлтүксүз жайгаштыруу бардык кабыл алуу сыноолору мурунку этаптарда өткөн болсо, биз өндүрүшкө өзгөртүүлөрүбүздү автоматтык түрдө коёбуз деп ойлойт. Мындан тышкары, чыгаруу баскычынан кийин, сиз өндүрүштө түтүн сыноолорун жүргүзүү жана кызыккан көрсөткүчтөрдү чогултуу сыяктуу ар кандай этаптарды конфигурациялай аласыз. Үзгүлтүксүз жайылтуу автоматташтырылган тесттер менен жакшы камтуу менен гана мүмкүн. Эгерде кандайдыр бир кол менен кийлигишүү, анын ичинде тестирлөө талап кылынса, анда бул мындан ары болбойт тынымсыз (үзгүлтүксүз). Ошондо биздин куур үзгүлтүксүз жеткирүү практикасына гана туура келет деп айта алабыз.
Автоматташтыруу инфраструктурасынын мааниси
Бул бөлүмдө мен UI тесттери жөнүндө сөз кылганда, бул биздин өзгөртүүлөрүбүздү жана ага байланыштуу кызматтарыбызды сыноо чөйрөсүнө колдонуу керек экенин түшүндүрүшүм керек. Үзгүлтүксүз интеграция - процесс бул тапшырма үчүн колдонулбайт жана биз жок дегенде үзгүлтүксүз жеткирүү практикасын ишке ашырууга кам көрүшүбүз керек. Үзгүлтүксүз жайылтуу, эгерде биз аларды өндүрүштө иштете турган болсок, UI тесттеринин контекстинде да мааниси бар.
Архитектуранын өзгөрүшүнүн иллюстрациясын кароодон мурун, мен GitLab CI жөнүндө бир нече сөз айткым келет. Башка CI/CD куралдарынан айырмаланып, GitLab алыскы репозиторийди жана башка көптөгөн кошумча мүмкүнчүлүктөрдү камсыз кылат. Ошентип, GitLab CIден көбүрөөк. Ал булак кодун башкарууну, Agile башкарууну, CI/CD түтүктөрүн, журналды жазуу куралдарын жана кутудан тышкары метрикаларды чогултууну камтыйт. GitLab архитектурасы Gitlab CI/CD жана GitLab Runnerден турат. Бул жерде расмий сайтынан кыскача сүрөттөлүшү болуп саналат:
Gitlab CI/CD – бул API менен веб-тиркеме, ал анын абалын маалымат базасында сактайт, долбоорлорду/курууларды башкарат жана колдонуучу интерфейсин камсыз кылат. GitLab Runner - бул курууларды иштеткен тиркеме. Аны өзүнчө жайгаштырса болот жана API аркылуу GitLab CI/CD менен иштейт. Иштеп жаткан тесттер үчүн сизге Gitlab инстанциясы жана Runner керек.
Инфраструктуранын учурдагы абалынын иллюстрациясы
Изилдөө үчүн шилтемелер
Окшош куралдар
- Жана башкалар
5. Булут платформалары
Технологиянын кыскача баяндамасы
Бул бөлүмдө биз "коомдук булуттар" деп аталган популярдуу тренд жөнүндө сүйлөшөбүз. Жогоруда сүрөттөлгөн виртуалдаштыруу жана контейнерлештирүү технологиялары берген эбегейсиз артыкчылыктарга карабастан, биз дагы эле эсептөө ресурстарына муктажбыз. Компаниялар кымбат серверлерди сатып алышат же дата борборлорун ижарага алышат, бирок бул учурда бизге канча ресурстар керек болорун, аларды 24/7 колдонобузбу жана кандай максаттарда колдонобуз деген эсептөөлөрдү (кээде реалдуу эмес) жүргүзүү керек. Мисалы, өндүрүш XNUMX/XNUMX иштеген серверди талап кылат, бирок бизге жумуш убактысынан тышкары тестирлөө үчүн ушундай ресурстар керекпи? Бул ошондой эле жүргүзүлүп жаткан сыноонун түрүнө жараша болот. Мисал катары биз кийинки күнү жыйынтыктарды алуу үчүн жумуш эмес сааттарда жүргүзүүнү пландаштырган жүктөө/стресс тесттери болот. Бирок, албетте, XNUMX/XNUMX сервердин болушу акырына чейин автоматташтырылган тесттер үчүн талап кылынбайт, айрыкча кол менен тестирлөө чөйрөлөрү үчүн эмес. Мындай жагдайлар үчүн талап боюнча канча керек болсо, ошончо ресурстарды алып, аларды колдонуп, керексиз болгондон кийин төлөөнү токтотсо жакшы болмок. Андан тышкары, чычканды бир нече чыкылдатуу же бир нече скрипттерди иштетүү менен аларды дароо кабыл алуу сонун болмок. Коомдук булуттар ушул үчүн колдонулат. Келгиле, аныктаманы карап көрөлү:
«Коомдук булут коомдук Интернет аркылуу үчүнчү тараптын провайдерлери тарабынан сунушталган, аларды колдонууну же сатып алууну каалагандардын баарына жеткиликтүү кылуучу эсептөө кызматтары катары аныкталат. Алар бекер же талап боюнча сатылышы мүмкүн, бул кардарларга CPU циклдери, сактагычы же керектөө жөндөмдүүлүгү үчүн гана колдонуу үчүн төлөөгө мүмкүндүк берет."
Коомдук булуттар кымбат деген пикир бар. Бирок алардын негизги идеясы компаниянын чыгымдарын азайтуу. Жогоруда айтылгандай, коомдук булуттар суроо-талап боюнча ресурстарды алууга жана аларды колдонгон убакыт үчүн гана төлөөгө мүмкүндүк берет. Ошондой эле, кээде кызматкерлердин айлыктарын, адистер да кымбат ресурс экенин унутуп калабыз. Коомдук булуттар инфраструктураны колдоону бир топ жеңилдете тургандыгын эске алуу керек, бул инженерлерге көбүрөөк маанилүү милдеттерге көңүл бурууга мүмкүндүк берет.
Автоматташтыруу инфраструктурасынын мааниси
UI сыноолору үчүн бизге кандай конкреттүү ресурстар керек? Негизинен булар браузерлерди жана эмуляторлорду иштетүү үчүн виртуалдык машиналар же кластерлер (кийинки бөлүмдө Kubernetes жөнүндө сүйлөшөбүз). Канчалык көп браузерлерди жана эмуляторлорду бир эле учурда иштетүүнү кааласак, ошончолук көп CPU жана эстутум талап кылынат жана ошончолук көп акча төлөшүбүз керек. Ошентип, тестти автоматташтыруу контекстиндеги коомдук булуттар бизге суроо-талап боюнча көп сандагы (100, 200, 1000...) браузерлерди/эмуляторлорду иштетүүгө, тесттин натыйжаларын мүмкүн болушунча тезирээк алууга жана мындай акылга сыйбас ресурсту талап кылуу үчүн төлөөнү токтотууга мүмкүндүк берет. күч.
Эң популярдуу булут провайдерлери Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP) болуп саналат. Колдонмо GCPди кантип колдонуунун мисалдарын берет, бирок жалпысынан автоматташтыруу тапшырмалары үчүн эмнени колдонгонуңуз маанилүү эмес. Алардын бардыгы болжол менен бирдей функцияны камсыз кылат. Адатта, провайдерди тандоо үчүн жетекчилик компаниянын бардык инфраструктурасына жана бизнес талаптарына көңүл бурат, бул макаланын алкагына кирбейт. Автоматташтыруу инженерлери үчүн булуттук провайдерлерди колдонуу менен булут платформаларын атайын тестирлөө максатында, мисалы, Sauce Labs, BrowserStack, BitBar ж. Андыктан, келгиле да жасайлы! Менин оюмча, Sauce Labs - бул эң белгилүү булут сыноо чарбасы, ошондуктан мен аны салыштыруу үчүн колдондум.
GCP vs Sauce Labs автоматташтыруу максатында:
Келгиле, бир эле учурда 8 веб тестти жана 8 Android тестин өткөрүшүбүз керек деп элестетип көрөлү. Бул үчүн биз GCP колдонобуз жана Selenoid менен 2 виртуалдык машинаны иштетебиз. Биринчисинде биз браузерлер менен 8 контейнерди көтөрөбүз. Экинчисинде эмулятору бар 8 контейнер бар. Келгиле, бааларды карап көрөлү:
Chrome менен бир контейнерди иштетүү үчүн, бизге керек n1-стандарт-1 машина. Android учурда бул болот n1-стандарт-4 бир эмулятор үчүн. Чынында, бир кыйла ийкемдүү жана арзан жол CPU / эс үчүн белгилүү бир колдонуучу баалуулуктарды коюу болуп саналат, бирок учурда бул Sauce Labs менен салыштыруу үчүн маанилүү эмес.
Жана бул жерде Sauce Labs колдонуу үчүн тарифтер:
Мен сиз буга чейин эле айырманы байкаган деп ойлойм, бирок мен дагы эле биздин милдет үчүн эсептөөлөр менен таблица берем:
Керектүү ресурстар
Ай сайын
иш убактысы(8:8 - XNUMX:XNUMX)
иш убактысы+ Артыкчылыктуу
Желе үчүн GCP
n1-стандарт-1 x 8 = n1-стандарт-8
$194.18
23 күн * 12 саат * 0.38 = $104.88
23 күн * 12 саат * 0.08 = $22.08
Желе үчүн соус лабораториялары
Virtual Cloud8 параллелдүү тесттер
$1.559
-
-
Android үчүн GCP
n1-стандарт-4 x 8: n1-стандарт-16
$776.72
23 күн * 12 саат * 1.52 = $419.52
23 күн * 12 саат * 0.32 = $88.32
Android үчүн Souce Labs
Real Device Cloud 8 параллелдүү тесттер
$1.999
-
-
Көрүнүп тургандай, наркынын айырмасы абдан чоң, өзгөчө, эгерде сиз он эки сааттык жумуш мезгилинде гана сыноолорду өткөрсөңүз. Бирок, сиз артыкчылыктуу машиналарды колдонсоңуз, чыгымдарды дагы кыскарта аласыз. Бул не?
Артыкчылыктуу VM - бул кадимки инстанцияларга караганда алда канча арзаныраак баада түзүп, иштете ала турган инстанция. Бирок, Compute Engine башка тапшырмалар үчүн ошол ресурстарга кирүү мүмкүнчүлүгүн талап кылса, бул инстанцияларды токтотушу (алдын ала) мүмкүн. Артыкчылыктуу инстанциялар Compute Engine'дин ашыкча сыйымдуулугу, андыктан алардын жеткиликтүүлүгү колдонууга жараша өзгөрөт.
Эгер колдонмолоруңуз каталарга чыдамдуу болсо жана мүмкүн болгон алдын ала эскертүүлөргө туруштук бере алса, анда артыкчылыктуу инстанциялар Compute Engine чыгымдарыңызды олуттуу түрдө азайтат. Мисалы, пакеттик иштетүү жумуштары артыкчылыктуу инстанцияларда иштей алат. Эгерде ошол учурлардын айрымдары кайра иштетүү учурунда токтоп калса, жумуш жайлайт, бирок толугу менен токтобойт. Артыкчылыктуу инстанциялар учурдагы инстанцияларыңызга кошумча жумуш жүгүн салбастан жана кошумча кадимки инстанциялар үчүн толук бааны төлөөнү талап кылбастан, пакеттик иштетүү тапшырмаларыңызды бүтүрөт.
Анан дагы эле бүтө элек! Чындыгында, мен эч ким 12 саат бою тыныгуусуз тест өткөрбөйт деп ишенем. Эгер ошондой болсо, анда сиз виртуалдык машиналарды керексиз болгондо автоматтык түрдө иштетип, токтото аласыз. Иш жүзүндө колдонуу убактысы күнүнө 6 саатка чейин кыскарышы мүмкүн. Ошондо биздин тапшырманын алкагында төлөм 11 браузер үчүн айына $8 чейин төмөндөйт. Бул сонун эмеспи? Бирок, артыкчылыктуу машиналар менен биз этият болушубуз керек жана үзгүлтүккө жана туруксуздукка даяр болушубуз керек, бирок бул жагдайлар программалык камсыздоодо каралып, чечилиши мүмкүн. Бул татыктуу!
Бирок мен эч качан "булуттук сыноо чарбаларын колдонбоңуз" деп айтпайм. Алардын бир катар артыкчылыктары бар. Биринчиден, бул жөн гана виртуалдык машина эмес, бирок кутудан тышкары функциялардын топтому менен толук кандуу тесттик автоматташтыруу чечими: алыстан кирүү, журналдар, скриншоттор, видео жазуу, ар кандай браузерлер жана физикалык мобилдик түзмөктөр. Көп учурларда, бул абдан маанилүү альтернатива болушу мүмкүн. Сыноо платформалары өзгөчө IOS автоматташтыруу үчүн пайдалуу, анткени коомдук булуттар Linux/Windows тутумдарын гана сунуштай алат. Бирок iOS жөнүндө кийинки макалаларда сүйлөшөбүз. Мен ар дайым кырдаалды карап чыгууну жана тапшырмалардан баштоону сунуштайм: кээ бир учурларда коомдук булуттарды колдонуу арзаныраак жана натыйжалуураак, ал эми башкаларында тесттик платформалар сарпталган акчага татыктуу.
Инфраструктуранын учурдагы абалынын иллюстрациясы
Изилдөө үчүн шилтемелер
Окшош куралдар:
6. Оркестр
Технологиянын кыскача баяндамасы
Менде жакшы жаңылык бар - биз макаланын аягындабыз! Учурда биздин автоматташтыруу инфраструктурабыз веб жана Android тесттеринен турат, аларды GitLab CI аркылуу параллелдүү түрдө Docker колдогон куралдарды колдонуу менен жүргүзөбүз: Selenium тор жана Selenoid. Мындан тышкары, биз GCP аркылуу түзүлгөн виртуалдык машиналарды браузерлер жана эмуляторлор менен контейнерлерди жайгаштыруу үчүн колдонобуз. Чыгымдарды азайтуу үчүн биз бул виртуалдык машиналарды суроо-талап боюнча гана ишке киргизебиз жана тестирлөө жүргүзүлбөй турганда аларды токтотобуз. Биздин инфраструктураны жакшырта турган башка нерсе барбы? Жооп ооба! Kubernetes (K8s) менен таанышыңыз!
Биринчиден, оркестр, кластер жана Кубернетес сөздөрүнүн бири-бири менен кандай байланышы бар экенин карап көрөлү. Жогорку деңгээлде, оркестрлөө - бул тиркемелерди жайгаштыруучу жана башкарган система. Сыноо автоматташтыруу үчүн, мындай контейнердик колдонмолор Selenium тор жана Selenoid болуп саналат. Docker жана K8 бири-бирин толуктап турат. Биринчиси тиркемени жайылтуу үчүн, экинчиси оркестрлөө үчүн колдонулат. Өз кезегинде, K8s кластер болуп саналат. Кластердин милдети – бир сервердин (кластердин) ичинде ар кандай функцияларды, программаларды жана кызматтарды орнотууга мүмкүндүк берүүчү түйүн катары VMлерди колдонуу. Түйүндөрдүн бири иштебей калса, башка түйүндөр ишке кирет, бул биздин тиркеменин үзгүлтүксүз иштешин камсыз кылат. Мындан тышкары, K8s масштабдоо менен байланышкан маанилүү функцияларга ээ, анын аркасында биз жүктөмдүн негизинде ресурстардын оптималдуу көлөмүн автоматтык түрдө алабыз жана чектерди белгилейбиз.
Чындыгында, Kubernetesти нөлдөн баштап кол менен жайылтуу анча деле маанилүү эмес. Мен атактуу "Кубернетес The Hard Way" гидинин шилтемесин калтырам жана эгер сизди кызыктырсаңыз, анда аны машыксаңыз болот. Бирок, бактыга жараша, альтернативалуу ыкмалар жана куралдар бар. Эң оңой жолу - GCPде Google Kubernetes Engine (GKE) колдонуу, ал сизге бир нече чыкылдатуу менен даяр кластерди алууга мүмкүндүк берет. Мен үйрөнүүнү баштоо үчүн ушул ыкманы колдонууну сунуштайм, анткени бул ички компоненттерди бири-бири менен кантип интеграциялоо керектигин үйрөнүүнүн ордуна, өз милдеттериңиз үчүн K8лерди кантип колдонууну үйрөнүүгө басым жасоого мүмкүндүк берет.
Автоматташтыруу инфраструктурасынын мааниси
Келгиле, K8s камсыз кылган бир нече маанилүү өзгөчөлүктөрүн карап көрөлү:
- тиркемени жайылтуу: VMлердин ордуна көп түйүндүү кластерди колдонуу;
- динамикалык масштабдоо: суроо-талап боюнча гана колдонулган ресурстардын баасын төмөндөтөт;
- өзүн-өзү айыктыруу: кабыктарды автоматтык түрдө калыбына келтирүү (анын натыйжасында контейнерлер да калыбына келтирилет);
- жаңыртууларды чыгаруу жана өзгөртүүлөр токтобой туруп кайра кайтаруу: куралдарды, браузерлерди жана эмуляторлорду жаңыртуу учурдагы колдонуучулардын ишин үзгүлтүккө учуратпайт
Бирок K8s дагы эле күмүш ок эмес. Биз карап жаткан куралдардын контекстинде бардык артыкчылыктарды жана чектөөлөрдү түшүнүү үчүн (Selenium тор, Selenoid), биз кыскача K8 түзүмүн талкуулайбыз. Кластер түйүндөрдүн эки түрүн камтыйт: Башкы түйүндөр жана Жумушчу түйүндөр. Мастер түйүндөр башкаруу, жайылтуу жана пландаштыруу чечимдери үчүн жооптуу. Жумушчу түйүндөр тиркемелерди ишке киргизет. Түйүндөр ошондой эле контейнердин иштөө чөйрөсүн камтыйт. Биздин учурда, бул контейнерге байланыштуу операциялар үчүн жооптуу болгон Докер. Бирок, мисалы, альтернативалуу чечимдер да бар. Бул масштабдуу же өзүн-өзү айыктыруу түздөн-түз контейнерлерге тиешелүү эмес экенин түшүнүү маанилүү. Бул өз кезегинде контейнерлерди камтыган (адатта, ар бир подъездге бир контейнер, бирок тапшырмага жараша дагы көп болушу мүмкүн) камырлардын санын кошуу/азайтуу жолу менен ишке ашырылат. Жогорку деңгээлдеги иерархия жумушчу түйүндөрдөн турат, алардын ичинде уячалар бар, алардын ичинде контейнерлер көтөрүлөт.
Масштабдоо өзгөчөлүгү негизги болуп саналат жана аны кластердик түйүн бассейниндеги эки түйүнгө да, түйүн ичиндеги поддондорго да колдонсо болот. Түйүндөргө да, кабыктарга да тиешелүү масштабдаштыруунун 2 түрү бар. Биринчи түрү горизонталдуу - масштабдоо түйүндөрдүн/подоктордун санын көбөйтүү менен ишке ашат. Бул түрү көбүрөөк артыкчылык болуп саналат. Экинчи түрү, тиешелүүлүгүнө жараша, вертикалдуу болуп саналат. Масштабдоо түйүндөрдүн/капчыктардын санын эмес, өлчөмүн көбөйтүү менен ишке ашырылат.
Эми жогорудагы терминдердин контекстинде куралдарыбызды карап көрөлү.
Селен тор
Жогоруда айтылгандай, Selenium тор абдан популярдуу куралы болуп саналат, жана ал контейнерде болгон эч кандай калыштуу эмес. Ошондуктан, Selenium торунун K8де жайгаштырылышы таң калыштуу эмес. Муну кантип жасоонун мисалын расмий K8s репозиторийинен тапса болот. Адаттагыдай эле, мен бөлүмдүн аягында шилтемелерди тиркейм. Кошумчалай кетсек, колдонмодо муну Terraformдо кантип жасоо керектиги көрсөтүлгөн. Браузердик контейнерлерди камтыган поддондордун санын кантип масштабдоо боюнча нускамалар да бар. Бирок K8s контекстинде автоматтык масштабдоо функциясы дагы эле толугу менен ачык-айкын иш эмес. Окуп баштаганда эч кандай практикалык көрсөтмөлөрдү же сунуштарды тапкан жокмун. DevOps командасынын колдоосу менен бир нече изилдөөлөр жана эксперименттерден кийин, биз бир жумушчу түйүн ичинде жайгашкан бир поддондун ичинде керектүү браузерлер менен контейнерлерди көтөрүү ыкмасын тандап алдык. Бул ыкма түйүндөрдүн санын көбөйтүү жолу менен горизонталдуу масштабдоо стратегиясын колдонууга мүмкүндүк берет. Бул келечекте өзгөрөт деп үмүттөнөм жана биз жакшыраак ыкмалардын жана даяр чечимдердин көбүрөөк сыпаттамаларын көрөбүз, айрыкча ички архитектурасы өзгөргөн Selenium тор 4 чыккандан кийин.
Селеноид:
K8sдеги селеноиддерди жайгаштыруу азыркы учурда эң чоң көңүл калуу. Алар туура келбейт. Теориялык жактан алганда, биз Selenoid контейнерди подъезддин ичинде көтөрө алабыз, бирок Selenoid контейнерлерди браузерлер менен ишке киргизе баштаганда, алар дагы эле ошол эле капчыктын ичинде болот. Бул масштабдоону мүмкүн эмес кылат жана натыйжада кластердин ичиндеги Селеноиддин иши виртуалдык машинанын ичиндеги иштен айырмаланбайт. Окуянын аягы.
ай:
Селеноид менен иштөөдө бул кыйынчылыкты билип, иштеп чыгуучулар Мун деген күчтүү куралды чыгарышты. Бул курал алгач Kubernetes менен иштөө үчүн иштелип чыккан жана натыйжада автомасштабдоо функциясын колдонсо болот жана колдонушу керек. Анын үстүнө, мен айтат элем, азыркы учурда гана Selenium дүйнөсүндөгү курал, ал кутудан чыккан жергиликтүү K8s кластердик колдоосуна ээ (мындан ары жеткиликтүү эмес, кийинки куралды караңыз ). Бул колдоону камсыз кылган Айдын негизги өзгөчөлүктөрү:
Толугу менен жарандыгы жок. Селеноид учурда иштеп жаткан браузер сеанстары жөнүндө маалыматты эс тутумунда сактайт. Эгерде кандайдыр бир себептерден улам анын процесси бузулуп калса, анда бардык иштеп жаткан сеанстар жоголот. Айдын, тескерисинче, ички абалы жок жана аны маалымат борборлору аркылуу кайталоого болот. Браузер сеанстары бир же бир нече репликалар иштебей калса да, тирүү бойдон кала берет.
Ошентип, Мун сонун чечим, бирок бир көйгөй бар: ал бекер эмес. Баасы сеанстардын санына жараша болот. Сиз 0-4 сессияны бекер иштете аласыз, бул өзгөчө пайдалуу эмес. Бирок, бешинчи сессиядан баштап, ар бири үчүн 5 доллардан төлөөгө туура келет. Кырдаал компаниядан компанияга ар кандай болушу мүмкүн, бирок биздин учурда Айды колдонуу маанисиз. Мен жогоруда сүрөттөгөнүмдөй, биз талап боюнча Selenium Grid менен VMлерди иштете алабыз же кластердеги түйүндөрдүн санын көбөйтө алабыз. Болжол менен бир түтүк үчүн биз 500 браузерди ишке киргизебиз жана сыноолор аяктагандан кийин бардык ресурстарды токтотобуз. Эгер биз Мун колдонсок, тесттерди канчалык көп өткөрбөйлү, айына кошумча 500 x 5 = 2500 доллар төлөшүбүз керек. Дагы айтам, мен Айды колдонбогула деп айтпайм. Сиздин милдеттериңиз үчүн, бул, мисалы, сиздин уюмуңузда көптөгөн долбоорлор/командаларыңыз болсо жана сизге бардыгы үчүн чоң жалпы кластер керек болсо, алмаштырылгыс чечим болушу мүмкүн. Адаттагыдай эле, мен аягында шилтемени калтырып, тапшырмаңыздын контекстинде бардык керектүү эсептөөлөрдү жасоону сунуштайм.
Джандар: (Көңүл бургула! Бул оригиналдуу макалада жок жана орусча котормосунда гана камтылган)
Мен айткандай, Selenium абдан популярдуу курал болуп саналат, жана IT тармагында абдан тез өнүгүп жатат. Мен котормо үстүндө иштеп жатканда интернетте Callisto аттуу жаңы келечектүү курал пайда болду (hello Cypress жана башка Selenium killers). Бул жергиликтүү K8s менен иштейт жана Селеноиддик контейнерлерди түйүндөр боюнча бөлүштүрүлгөн капчыктарда иштетүүгө мүмкүндүк берет. Баары кутудан чыгып иштейт, анын ичинде автоскалдаштыруу. Фантастикалык, бирок сыналышы керек. Мен буга чейин бул куралды жайгаштырууга жана бир нече эксперименттерди жүргүзүүгө жетиштим. Бирок жыйынтык чыгарууга али эрте, узак аралыкта жыйынтыктарды алгандан кийин, балким, мен келечектеги макалаларда карап чыгам. Азырынча мен көз карандысыз изилдөө үчүн шилтемелерди гана калтырып жатам.
Инфраструктуранын учурдагы абалынын иллюстрациясы
Изилдөө үчүн шилтемелер
Окшош куралдар
7. Инфраструктура кодекс катары (IaC)
Технологиянын кыскача баяндамасы
Эми биз акыркы бөлүмгө келдик. Адатта, бул технология жана ага байланыштуу милдеттер автоматташтыруу инженерлеринин жоопкерчилиги эмес. Ал эми мунун себептери бар. Биринчиден, көптөгөн уюмдарда инфраструктура маселелери DevOps бөлүмүнүн көзөмөлүндө жана иштеп чыгуу топтору түтүктүн иштешин жана аны менен байланышкан нерселердин бардыгын кантип колдоо керектиги жөнүндө чындап кам көрүшпөйт. Экинчиден, чынын айтсак, көптөгөн компанияларда Инфраструктураны Кодекс катары (IaC) практикасы дагы эле кабыл алынган эмес. Бирок бул, албетте, популярдуу тенденция болуп калды жана аны менен байланышкан процесстерге, ыкмаларга жана инструменттерге катышууга аракет кылуу маанилүү. Же, жок эле дегенде, акыркы кабардар болгула.
Бул ыкманы колдонуу мотивациясынан баштайлы. Биз GitlabCIде тесттерди өткөрүү үчүн Gitlab Runnerди иштетүү үчүн эң аз дегенде ресурстар керек болорун талкууладык. Жана браузерлер/эмуляторлор менен контейнерлерди иштетүү үчүн биз VM же кластерди резервге алышыбыз керек. Ресурстарды сынап көрүүдөн тышкары, биз иштеп чыгуу, стадиялоо, өндүрүш чөйрөсүн колдоо үчүн олуттуу көлөмдөгү кубаттуулукка муктажбыз, ал ошондой эле маалымат базаларын, автоматтык графиктерди, тармак конфигурацияларын, жүктөмдөрдүн тең салмактуулугун, колдонуучунун укуктарын жана башкаларды камтыйт. Негизги маселе - мунун бардыгын колдоо үчүн күч-аракет талап кылынат. Өзгөртүүлөрдү киргизүүнүн жана жаңыртууларды чыгаруунун бир нече жолу бар. Мисалы, GCP контекстинде биз браузерде UI консолун колдонуп, баскычтарды чыкылдатуу менен бардык аракеттерди аткара алабыз. Альтернатива булут объекттери менен өз ара аракеттенүү үчүн API чалууларын колдонуу же керектүү манипуляцияларды аткаруу үчүн gcloud буйрук сабынын утилитасын колдонуу болот. Бирок чындап эле көп сандагы ар кандай объекттер жана инфраструктура элементтери менен бардык операцияларды кол менен аткаруу кыйынга турат же мүмкүн эмес болуп калат. Анын үстүнө, бул кол менен жасалган иш-аракеттердин баары көзөмөлдөнбөйт. Биз аларды аткарууга чейин кароого тапшыра албайбыз, версияны башкаруу тутумун колдоно албайбыз жана окуяга алып келген өзгөртүүлөрдү тез эле артка кайтара албайбыз. Мындай көйгөйлөрдү чечүү үчүн инженерлер автоматтык bash/shell скрипттерин түзүштү жана түзүштү, алар мурунку ыкмалардан анча деле жакшы эмес, анткени аларды процедуралык стилде тез окуу, түшүнүү, колдоо жана өзгөртүү оңой эмес.
Бул макалада жана кантип көрсөтмө, мен IaC практикасына байланыштуу 2 куралды колдоном. Бул Terraform жана Ansible. Кээ бир адамдар аларды бир эле учурда колдонуунун мааниси жок деп эсептешет, анткени алардын функциялары окшош жана бири-бирин алмаштырса болот. Бирок, чынында, алгач аларга такыр башка тапшырмалар берилген. Жана бул инструменттер бири-бирин толуктап турушу керек экендиги HashiCorp жана RedHat компаниясын иштеп чыгуучулардын биргелешкен презентациясында тастыкталды. Концептуалдык айырма - бул Terraform серверлердин өзүн башкаруу үчүн камсыздоо куралы. Ansible бул конфигурацияны башкаруу куралы болуп саналат, анын милдети бул серверлерде программалык камсыздоону орнотуу, конфигурациялоо жана башкаруу.
Бул куралдардын дагы бир негизги айырмалоочу өзгөчөлүгү коддоо стили болуп саналат. bash жана Ansibleден айырмаланып, Terraform аткаруунун натыйжасында жетишилүүчү каалаган акыркы абалды сүрөттөөгө негизделген декларативдик стилди колдонот. Мисалы, биз 10 VM түзө турган болсок жана өзгөртүүлөрдү Terraform аркылуу колдонсок, анда биз 10 VM алабыз. Эгерде биз скриптти кайра иштетсек, эч нерсе болбойт, анткени бизде 10 VM бар жана Terraform бул тууралуу билет, анткени ал инфраструктуранын учурдагы абалын мамлекеттик файлда сактайт. Бирок Ansible процедуралык ыкманы колдонот жана эгер сиз андан 10 VM түзүүнү сурансаңыз, анда биринчи ишке киргизүүдө биз Terraform сыяктуу 10 VM алабыз. Бирок кайра күйгүзгөндөн кийин бизде 20 VM болот. Бул маанилүү айырма болуп саналат. Процедуралык стилде биз учурдагы абалды сактабайбыз жана жөн гана аткарылышы керек болгон кадамдардын ырааттуулугун сүрөттөп беребиз. Албетте, биз ар кандай кырдаалдарды чече алабыз, ресурстардын бар-жогуна жана учурдагы абалына бир нече текшерүүлөрдү кошо алабыз, бирок бул логиканы көзөмөлдөө үчүн убакытты текке кетирүүнүн жана күч-аракетибизди жумшоонун мааниси жок. Мындан тышкары, бул ката кетирүү коркунучун жогорулатат.
Жогоруда айтылгандардын бардыгын жыйынтыктап, биз Terraform жана декларативдик белгилер серверлерди камсыздоо үчүн ылайыктуу курал болуп саналат деген тыянак чыгарууга болот. Бирок конфигурацияны башкаруу ишин Ansibleге тапшырган жакшы. Мындан тышкары, келгиле, автоматташтыруу контекстинде колдонуу учурларын карап көрөлү.
Автоматташтыруу инфраструктурасынын мааниси
Бул жерде түшүнүү керек болгон бир гана маанилүү нерсе - тесттин автоматташтырылган инфраструктурасы компаниянын бардык инфраструктурасынын бир бөлүгү катары каралышы керек. Бул бардык IaC практикалары бүткүл уюмдун ресурстарына глобалдуу түрдө колдонулушу керек дегенди билдирет. Бул үчүн ким жооптуу, сиздин процесстериңизден көз каранды. DevOps командасы бул маселелерде тажрыйбалуу, алар эмне болуп жатканын толугу менен көрүшөт. Бирок, QA инженерлери курулушту автоматташтыруу процессине жана түтүктүн структурасына көбүрөөк тартылышат, бул аларга бардык керектүү өзгөрүүлөрдү жана жакшыртуу мүмкүнчүлүктөрүн жакшыраак көрүүгө мүмкүндүк берет. Эң жакшы вариант – күтүлгөн натыйжага жетүү үчүн биргелешип иштөө, билим жана идеяларды алмашуу.
Бул жерде Terraform жана Ansible тесттерин автоматташтыруу контекстинде колдонуунун бир нече мисалдары жана биз мурда талкууланган куралдар:
1. Терраформды колдонуу менен VM жана кластерлердин керектүү мүнөздөмөлөрүн жана параметрлерин сүрөттөп бергиле.
2. Ansible колдонуп, тестирлөө үчүн керектүү куралдарды орнотуңуз: докер, Selenoid, Selenium Grid жана браузерлердин/эмуляторлордун керектүү версияларын жүктөп алыңыз.
3. Terraform колдонуп, GitLab Runner ишке киргизиле турган VMнин мүнөздөмөлөрүн сүрөттөп бериңиз.
4. Ansible аркылуу GitLab Runner жана керектүү коштомо куралдарды орнотуп, орнотууларды жана конфигурацияларды орнотуңуз.
Инфраструктуранын учурдагы абалынын иллюстрациясы
Изилдөө үчүн шилтемелер:
Окшош куралдар
Жыйынтыктайлы!
кадам
технология
аспаптар
Автоматташтыруу инфраструктурасынын мааниси
1
Жергиликтүү чуркоо
Node.js, Selenium, Appium
- Веб жана мобилдик үчүн эң популярдуу куралдар
- Көптөгөн тилдерди жана платформаларды колдойт (анын ичинде Node.js)
2
Версияларды башкаруу системалары
барып,
- Өнүгүү коду менен окшош артыкчылыктар
3
Контейнерлештирүү
Docker, Selenium тор, Selenoid (Web, Android)
- Тесттерди параллелдүү жүргүзүү
- Изоляцияланган чөйрөлөр
- Жөнөкөй, ийкемдүү версия жогорулатуулар
- Пайдаланылбаган ресурстарды динамикалык түрдө токтотуу
- Орнотуу оңой
4
CI/CD
Gitlab CI
- Түтүктүн бир бөлүгүн сынайт
- Тез пикир
- Бүткүл компанияга/командага көрүнүү
5
Булут платформалары
Google Cloud Platform
- Талап боюнча ресурстар (керек болгондо гана төлөйбүз)
- Башкаруу жана жаңыртуу оңой
- Бардык ресурстарды көрүү жана көзөмөлдөө
6
айкалыштыруу
Kubernetes
Подоктордун ичиндеги браузерлер/эмуляторлор бар контейнерлердин контекстинде:
- Масштабдоо/автоматтык масштабдоо
- Өзүн-өзү айыктыруу
- Үзгүлтүксүз жаңыртуулар жана артка кайтаруулар
7
Инфраструктура код катары (IaC)
Terraform, Ansible
- Өнүктүрүү инфраструктурасы менен окшош артыкчылыктар
- Кодду версиялоонун бардык артыкчылыктары
- Өзгөртүүлөрдү киргизүү жана сактоо оңой
- Толугу менен автоматташтырылган
Акыл картасынын диаграммалары: инфраструктуранын эволюциясы
1-кадам: Жергиликтүү
2-кадам: VCS
3-кадам: Контейнерлештирүү
4-кадам: CI/CD
5-кадам: Булут платформалары
6-кадам: Оркестрация
7-кадам: IaC
Кийинкиси эмне?
Ошентип, бул макаланын аягы. Бирок акырында мен сиздер менен кээ бир келишимдерди түзгүм келет.
Сен тараптан
Мен башында айткандай, макала практикалык жактан пайдалуу болушун жана алган билимдериңизди чыныгы жумушта колдонууга жардам беришин каалайм. Мен дагы кошом.
Бирок андан кийин деле токтоп калбаңыз, машыгыңыз, тиешелүү шилтемелерди жана китептерди изилдеңиз, ал сиздин компанияңызда кандай иштээрин билип алыңыз, жакшырта турган жерлерди табыңыз жана ага катышыңыз. Жолуңуз ачык болсун!
Мен жактан
Аталышынан бул биринчи гана бөлүгү болгонун көрүүгө болот. Бул абдан чоң болуп чыкканына карабастан, бул жерде дагы эле маанилүү темалар камтылган эмес. Экинчи бөлүктө IOS контекстинде автоматташтыруу инфраструктурасын кароону пландап жатам. Apple'дин iOS симуляторлорун macOS тутумдарында гана иштетүү боюнча чектөөлөрүнөн улам, биздин чечимдердин диапазону кыскарган. Мисалы, биз симуляторду иштетүү үчүн Dockerди же виртуалдык машиналарды иштетүү үчүн коомдук булуттарды колдоно албайбыз. Бирок бул башка альтернатива жок дегенди билдирбейт. Мен сизди өнүккөн чечимдер жана заманбап куралдар менен жаңыртып турууга аракет кылам!
Ошондой эле, мен мониторингге байланыштуу өтө чоң темаларды айткан жокмун. 3-бөлүктө мен эң популярдуу инфраструктуралык мониторинг куралдарын жана кандай маалыматтар менен метрикаларды карап чыгам.
Анан акыры. Келечекте мен тесттик инфраструктураны жана популярдуу куралдарды куруу боюнча видеокурс чыгарууну пландап жатам. Учурда Интернетте DevOps боюнча бир нече курстар жана лекциялар бар, бирок бардык материалдар тесттик автоматташтыруу эмес, иштеп чыгуу контекстинде берилген. Бул маселе боюнча мага мындай курс тестирлөөчүлөр жана автоматика инженерлеринин коомчулугу үчүн кызыктуу жана баалуу болобу деген пикир керек. Алдын ала рахмат!
Source: www.habr.com