Део 1: Веб/Андроид
Приметити: овај чланак је превод оригиналног чланка на руски Међутим, све илустрације, везе, цитати и термини су сачувани на оригиналном језику како би се избегло изобличење значења када се преводе на руски. Желим вам срећно учење!
Тренутно је специјалност ДевОпс једна од најтраженијих у ИТ индустрији. Ако отворите популарне сајтове за тражење посла и филтрирате према плати, видећете да су послови везани за ДевОпс на врху листе. Међутим, важно је схватити да се то углавном односи на позицију 'Сениор', што подразумева да кандидат има висок ниво вештина, знања о технологији и алатима. Ово такође долази са високим степеном одговорности повезане са несметаним радом производње. Међутим, почели смо да заборављамо шта је ДевОпс. У почетку то није била нека конкретна особа или одељење. Ако потражимо дефиниције овог појма, наћи ћемо много лепих и исправних именица, као што су методологија, пракса, културна филозофија, група појмова и тако даље.
Моја специјализација је инжењер за аутоматизацију тестова (КА аутоматион енгинеер), али сматрам да то не треба повезивати само са писањем ауто-тестова или развојем архитектуре тестног оквира. У 2020. познавање инфраструктуре за аутоматизацију је такође неопходно. Ово вам омогућава да сами организујете процес аутоматизације, од покретања тестова до пружања резултата свим заинтересованим странама у складу са вашим циљевима. Као резултат тога, ДевОпс вештине су неопходне за обављање посла. И све је ово добро, али, нажалост, постоји проблем (спојлер: овај чланак покушава да поједностави овај проблем). Поента је да је ДевОпс тежак. И то је очигледно, јер компаније неће платити много за нешто што је лако урадити... У ДевОпс свету постоји велики број алата, термина и пракси које треба савладати. Ово је посебно тешко на почетку каријере и зависи од акумулираног техничког искуства.
Извор:
Овде ћемо вероватно завршити са уводним делом и фокусирати се на сврху овог чланка.
О чему је овај чланак?
У овом чланку ћу поделити своје искуство у изградњи инфраструктуре за аутоматизацију тестова. На Интернету постоји много извора информација о разним алатима и начину њиховог коришћења, али бих желео да их погледам искључиво у контексту аутоматизације. Верујем да су многи инжењери аутоматизације упознати са ситуацијом када нико осим вас не покреће развијене тестове нити брине о њиховом одржавању. Као резултат тога, тестови постају застарели и морате да трошите време на њихово ажурирање. Опет, на почетку каријере, ово може бити прилично тежак задатак: мудро одлучивање који алати треба да помогну у отклањању датог проблема, како да их изаберете, конфигуришете и одржавате. Неки тестери се обраћају ДевОпс-у (људи) за помоћ и, будимо искрени, овај приступ функционише. У многим случајевима ово може бити једина опција пошто немамо преглед свих зависности. Али као што знамо, ДевОпс су веома заузети момци, јер морају да размишљају о инфраструктури целокупне компаније, постављању, надгледању, микросервисима и другим сличним задацима у зависности од организације/тима. Као што обично бива, аутоматизација није приоритет. У таквом случају морамо покушати да учинимо све што је могуће од почетка до краја. Ово ће смањити зависности, убрзати ток посла, побољшати наше вештине и омогућити нам да видимо ширу слику онога што се дешава.
Чланак представља најпопуларније и најпопуларније алате и показује како их користити за изградњу инфраструктуре за аутоматизацију корак по корак. Сваку групу представљају алати који су тестирани личним искуством. Али то не значи да морате да користите исту ствар. Сами алати нису важни, појављују се и застаревају. Наш инжењерски задатак је да разумемо основне принципе: зашто нам је потребна ова група алата и које радне проблеме можемо да решимо уз њихову помоћ. Зато на крају сваког одељка остављам везе до сличних алата који се могу користити у вашој организацији.
Чега нема у овом чланку
Још једном понављам да чланак није о конкретним алатима, тако да неће бити уметања кода из документације и описа конкретних команди. Али на крају сваког одељка остављам везе за детаљно проучавање.
Ово се ради зато што:
- овај материјал је врло лако пронаћи у разним изворима (документација, књиге, видео курсеви);
- ако кренемо дубље, мораћемо да напишемо 10, 20, 30 делова овог чланка (док су планови 2-3);
- Само не желим да губим ваше време јер бисте можда желели да користите друге алате за постизање истих циљева.
Пракса
Заиста бих волео да овај материјал буде користан сваком читаоцу, а не само прочитан и заборављен. У свакој студији, пракса је веома важна компонента. За ово сам се припремио. Ту је и домаћи задатак који вас чека како бисте били сигурни да не копирате безумно редове команди које извршавате.
План
Корак
технологија
алат
1
Локално трчање (припремите веб/андроид демо тестове и покрените га локално)
Ноде.јс, Селен, Аппиум
2
Системи контроле верзија
гит
3
Контејнеризација
Доцкер, Селениум грид, Селеноид (Веб, Андроид)
4
ЦИ/ЦД
Гитлаб ЦИ
5
Цлоуд платформе
Гоогле Цлоуд Платформ
6
Оркестрација
Кубернетес
7
Инфраструктура као код (ИаЦ)
Терраформ, Ансибле
Структура сваке секције
Да би нарација била јасна, сваки одељак је описан према следећем прегледу:
- кратак опис технологије,
- вредност за инфраструктуру аутоматизације,
- илустрација тренутног стања инфраструктуре,
- везе до студија,
- слични алати.
1. Покрените тестове локално
Кратак опис технологије
Ово је само припремни корак за локално покретање демо тестова и проверу да ли су прошли. У практичном делу се користи Ноде.јс, али програмски језик и платформа такође нису битни и можете користити оне који се користе у вашој компанији.
Међутим, као алатке за аутоматизацију, препоручујем коришћење Селениум ВебДривер-а за веб платформе и Аппиум-а за Андроид платформу, пошто ћемо у наредним корацима користити Доцкер слике које су прилагођене за рад са овим алатима. Штавише, с обзиром на захтеве посла, ови алати су најтраженији на тржишту.
Као што сте можда приметили, разматрамо само веб и Андроид тестове. Нажалост, иОС је сасвим друга прича (хвала Аппле-у). Планирам да представим решења и праксе у вези са ИОС-ом у наредним деловима.
Вредност за инфраструктуру аутоматизације
Из перспективе инфраструктуре, локално трчање не пружа никакву вредност. Проверавате само да ли се тестови покрећу на локалној машини у локалним претраживачима и симулаторима. Али у сваком случају, ово је неопходна полазна тачка.
Илустрација тренутног стања инфраструктуре
Везе за истраживање
Слични алати
- било који програмски језик који вам се допада у комбинацији са тестовима Селениум/Аппиум;
- било каквих тестова;
- било који пробни тркач.
2. Системи контроле верзија (Гит)
Кратак опис технологије
Никоме неће бити велико откриће ако кажем да је контрола верзија изузетно важан део развоја, како у тиму, тако и појединачно. На основу различитих извора, са сигурношћу се може рећи да је Гит најпопуларнији представник. Систем контроле верзија пружа многе предности, као што су дељење кода, чување верзија, враћање на претходне гране, праћење историје пројекта и прављење резервних копија. Нећемо детаљно расправљати о свакој тачки, јер сам сигуран да сте је добро упознати и да је користите у свом свакодневном раду. Али ако изненада не, онда препоручујем да паузирате читање овог чланка и попуните ову празнину што је пре могуће.
Вредност за инфраструктуру аутоматизације
И овде можете поставити разумно питање: „Зашто нам говори о Гиту? Сви то знају и користе га и за развојни код и за код за аутоматско тестирање.” Бићете потпуно у праву, али у овом чланку говоримо о инфраструктури и овај одељак служи као преглед за одељак 7: „Инфраструктура као код (ИаЦ)“. За нас то значи да је целокупна инфраструктура, укључујући и тестирање, описана у облику кода, тако да на њу можемо применити и системе за верзионисање и добити сличне погодности као код развоја и аутоматизације.
ИаЦ ћемо детаљније погледати у кораку 7, али чак и сада можете почети да користите Гит локално креирањем локалног спремишта. Велика слика ће се проширити када инфраструктури додамо удаљено спремиште.
Илустрација тренутног стања инфраструктуре
Везе за истраживање
Слични алати
3. Контејнеризација (Доцкер)
Кратак опис технологије
Да бисмо показали како је контејнеризација променила правила игре, вратимо се неколико деценија уназад. Тада су људи куповали и користили серверске машине за покретање апликација. Али у већини случајева, потребни ресурси за покретање нису били унапред познати. Као резултат тога, компаније су трошиле новац на куповину скупих, моћних сервера, али део ових капацитета није у потпуности искоришћен.
Следећа фаза еволуције биле су виртуелне машине (ВМ), које су решиле проблем расипања новца на неискоришћене ресурсе. Ова технологија је омогућила покретање апликација независно једна од друге унутар истог сервера, додељујући потпуно изолован простор. Али, нажалост, свака технологија има своје недостатке. Покретање ВМ захтева комплетан оперативни систем, који троши ЦПУ, РАМ, складиште и, у зависности од оперативног система, треба узети у обзир трошкове лиценце. Ови фактори утичу на брзину учитавања и отежавају преносивост.
И сада долазимо до контејнеризације. Још једном, ова технологија решава претходни проблем, јер контејнери не користе пун ОС, што ослобађа велику количину ресурса и пружа брзо и флексибилно решење за преносивост.
Наравно, технологија контејнеризације није ништа ново и први пут је уведена касних 70-их. У то време спроведено је много истраживања, развоја и покушаја. Али Доцкер је прилагодио ову технологију и учинио је лако доступном масама. Данас, када говоримо о контејнерима, у већини случајева мислимо на Доцкер. Када говоримо о Доцкер контејнерима, мислимо на Линук контејнере. Можемо користити Виндовс и мацОС системе за покретање контејнера, али је важно разумети да се у овом случају појављује додатни слој. На пример, Доцкер на Мац-у тихо покреће контејнере унутар лаганог Линук ВМ-а. Вратићемо се на ову тему када будемо разговарали о покретању Андроид емулатора унутар контејнера, тако да овде постоји веома важна нијанса о којој треба детаљније разговарати.
Вредност за инфраструктуру аутоматизације
Сазнали смо да су контејнеризација и Доцкер цоол. Погледајмо ово у контексту аутоматизације, јер сваки алат или технологија треба да реши проблем. Хајде да наведемо очигледне проблеме аутоматизације тестова у контексту УИ тестова:
- огроман број зависности приликом инсталирања Селена и посебно Аппиума;
- проблеми са компатибилношћу између верзија претраживача, симулатора и драјвера;
- недостатак изолованог простора за претраживаче/симулаторе, што је посебно критично за паралелно трчање;
- тешко управљати и одржавати ако треба да покренете 10, 50, 100 или чак 1000 претраживача истовремено.
Али пошто је Селен најпопуларнија алатка за аутоматизацију, а Доцкер најпопуларнија алатка за контејнеризацију, не би требало да буде изненађење што је неко покушао да их комбинује како би направио моћан алат за решавање горе наведених проблема. Размотримо таква решења детаљније.
Селенска мрежа у доцкер-у
Овај алат је најпопуларнији у свету Селена за покретање више прегледача на више машина и управљање њима из централног чворишта. За почетак, потребно је да региструјете најмање 2 дела: чвориште и чвор(е). Чвориште је централни чвор који прима све захтеве из тестова и дистрибуира их одговарајућим чворовима. За сваки чвор можемо да конфигуришемо одређену конфигурацију, на пример, навођењем жељеног претраживача и његове верзије. Међутим, и даље морамо сами да се побринемо за компатибилне драјвере претраживача и да их инсталирамо на жељене чворове. Из тог разлога, Селениум грид се не користи у свом чистом облику, осим када треба да радимо са претраживачима који се не могу инсталирати на Линук ОС. За све остале случајеве, значајно флексибилно и исправно решење би било коришћење Доцкер слика за покретање Селениум грид Хуб-а и чворова. Овај приступ у великој мери поједностављује управљање чворовима, пошто можемо да изаберемо слику која нам је потребна са компатибилним верзијама претраживача и управљачких програма који су већ инсталирани.
Упркос негативним критикама о стабилности, посебно када се покреће велики број чворова паралелно, Селениум грид је и даље најпопуларнији алат за паралелно покретање Селенијум тестова. Важно је напоменути да се у отвореном коду стално појављују разна побољшања и модификације овог алата, који се боре против разних уских грла.
Селеноид за веб
Овај алат је пробој у свету Селена јер ради одмах из кутије и много је олакшао живот многим инжењерима аутоматизације. Пре свега, ово није још једна модификација Селенове мреже. Уместо тога, програмери су креирали потпуно нову верзију Селениум Хуб-а у Голангу, која је у комбинацији са лаким Доцкер сликама за различите претраживаче дала подстицај развоју аутоматизације тестирања. Штавише, у случају Селениум Грид-а, морамо унапред одредити све потребне претраживаче и њихове верзије, што није проблем када се ради само са једним претраживачем. Али када је у питању више подржаних претраживача, Селеноид је решење број један захваљујући својој функцији „прегледач на захтев“. Све што се од нас тражи је да унапред преузмемо потребне слике са претраживача и ажурирамо конфигурациони фајл са којим Селеноид комуницира. Након што Селеноид прими захтев од тестова, аутоматски ће покренути жељени контејнер са жељеним претраживачем. Када се тест заврши, Селеноид ће повући контејнер из употребе, чиме ће ослободити ресурсе за будуће захтеве. Овај приступ у потпуности елиминише добро познати проблем 'деградације чворова' са којим се често сусрећемо у Селениум мрежи.
Али, авај, Селеноид још увек није сребрни метак. Добили смо функцију „прегледач на захтев“, али функција „ресурси на захтев“ још увек није доступна. Да бисмо користили Селеноид, морамо га поставити на физички хардвер или на ВМ, што значи да морамо унапред знати колико ресурса треба да се додели. Претпостављам да то није проблем за мале пројекте који покрећу 10, 20 или чак 30 претраживача паралелно. Али шта ако нам треба 100, 500, 1000 или више? Нема смисла стално одржавати и плаћати толико ресурса. У одељцима 5 и 6 овог чланка ћемо разговарати о решењима која вам омогућавају скалирање, чиме се значајно смањују трошкови компаније.
Селеноид за Андроид
Након успеха Селеноида као алата за веб аутоматизацију, људи су желели нешто слично за Андроид. И десило се - Селеноид је пуштен са подршком за Андроид. Са становишта корисника високог нивоа, принцип рада је сличан веб аутоматизацији. Једина разлика је у томе што уместо контејнера претраживача, Селеноид покреће контејнере Андроид емулатора. По мом мишљењу, ово је тренутно најмоћнији бесплатни алат за паралелно покретање Андроид тестова.
Заиста не бих желео да говорим о негативним аспектима овог алата, јер ми се заиста свиђа. Али ипак, постоје исти недостаци који се односе на веб аутоматизацију и повезани су са скалирањем. Поред овога, морамо да разговарамо о још једном ограничењу које може бити изненађење ако постављамо алат по први пут. Да бисмо покренули Андроид слике, потребна нам је физичка машина или ВМ са подршком за угнежђену виртуелизацију. У водичу са упутствима демонстрирам како то омогућити на Линук ВМ-у. Међутим, ако сте корисник мацОС-а и желите да примените Селеноид локално, тада неће бити могуће покренути Андроид тестове. Али увек можете локално покренути Линук ВМ са конфигурисаном „угнежђеном виртуелизацијом“ и применити Селеноид унутра.
Илустрација тренутног стања инфраструктуре
У контексту овог чланка, додаћемо 2 алата за илустрацију инфраструктуре. Ово су Селениум грид за веб тестове и Селеноид за Андроид тестове. У ГитХуб водичу, такође ћу вам показати како да користите Селеноид за покретање веб тестова.
Везе за истраживање
Слични алати
- Постоје и други алати за контејнеризацију, али Доцкер је најпопуларнији. Ако желите да испробате нешто друго, имајте на уму да алати које смо покрили за паралелно покретање Селенијум тестова неће радити без употребе.
- Као што је већ речено, постоји много модификација селенске мреже, на пример,.
4.ЦИ/ЦД
Кратак опис технологије
Пракса континуиране интеграције је прилично популарна у развоју и једнака је системима контроле верзија. Упркос томе, осећам да постоји збрка у терминологији. У овом параграфу бих желео да опишем 3 модификације ове технологије са моје тачке гледишта. На интернету ћете наћи много чланака са различитим тумачењима и сасвим је нормално ако се ваше мишљење разликује. Најважније је да сте на истој страни са својим колегама.
Дакле, постоје 3 термина: ЦИ - Континуирана интеграција, ЦД - Континуирана испорука и опет ЦД - Континуирана имплементација. (У наставку ћу користити ове термине на енглеском). Свака модификација додаје неколико додатних корака вашем развојном цевоводу. Али реч непрекидан (континуирано) је најважнија ствар. У овом контексту мислимо на нешто што се дешава од почетка до краја, без прекида или ручне интервенције. Погледајмо ЦИ & ЦД и ЦД у овом контексту.
- Континуирано интеграција ово је почетни корак еволуције. Након слања новог кода на сервер, очекујемо да добијемо брзе повратне информације да су наше промене у реду. Типично, ЦИ укључује покретање алата за статичку анализу кода и јединичне/интерне АПИ тестове.Ово нам омогућава да добијемо информације о нашем коду у року од неколико секунди/минута.
- Континуирана достава је напреднији корак где покрећемо интеграцијске/УИ тестове. Међутим, у овој фази не добијамо резултате тако брзо као код ЦИ. Прво, за ове врсте тестова је потребно више времена. Друго, пре покретања, морамо да применимо наше промене у окружењу за тестирање/сцену. Штавише, ако говоримо о мобилном развоју, онда се појављује додатни корак за креирање верзије наше апликације.
- Континуирано постављање претпоставља да аутоматски пуштамо наше измене у производњу ако су сви тестови прихватања прошли у претходним фазама. Поред тога, након фазе издавања, можете конфигурисати различите фазе, као што је покретање тестова дима у производњи и прикупљање метрике од интереса. Континуирана примена је могућа само уз добру покривеност аутоматизованим тестовима. Ако су потребне било какве ручне интервенције, укључујући тестирање, онда то више није Непрекидан (континуирано). Тада можемо рећи да је наш цевовод у складу само са праксом континуиране испоруке.
Вредност за инфраструктуру аутоматизације
У овом одељку, требало би да појасним да када говоримо о енд-то-енд УИ тестовима, то значи да треба да применимо наше промене и повезане услуге у окружењима за тестирање. Континуирана интеграција – процес није применљив за овај задатак и морамо се побринути за имплементацију барем пракси континуиране испоруке. Континуирана примена такође има смисла у контексту УИ тестова ако ћемо их покренути у производњи.
И пре него што погледамо илустрацију промене архитектуре, желим да кажем неколико речи о ГитЛаб ЦИ. За разлику од других ЦИ/ЦД алата, ГитЛаб пружа удаљено спремиште и многе друге додатне функције. Дакле, ГитЛаб је више од ЦИ. Укључује управљање изворним кодом, Агиле управљање, ЦИ/ЦД цевоводе, алате за евидентирање и прикупљање метрика из кутије. ГитЛаб архитектура се састоји од Гитлаб ЦИ/ЦД и ГитЛаб Руннер-а. Ево кратког описа са званичног сајта:
Гитлаб ЦИ/ЦД је веб апликација са АПИ-јем који чува своје стање у бази података, управља пројектима/изградњом и обезбеђује кориснички интерфејс. ГитЛаб Руннер је апликација која обрађује градње. Може се применити одвојено и ради са ГитЛаб ЦИ/ЦД преко АПИ-ја. За покретање тестова потребни су вам и Гитлаб инстанца и Руннер.
Илустрација тренутног стања инфраструктуре
Везе за истраживање
Слични алати
- И многи други
5. Цлоуд платформе
Кратак опис технологије
У овом одељку ћемо говорити о популарном тренду који се зове 'јавни облаци'. Упркос огромним предностима које горе описане технологије виртуелизације и контејнеризације пружају, и даље су нам потребни рачунарски ресурси. Компаније купују скупе сервере или изнајмљују дата центре, али је у овом случају потребно направити калкулације (понекад нереалне) колико ће нам ресурса бити потребно, да ли ћемо их користити 24/7 и у које сврхе. На пример, производња захтева сервер који ради XNUMX/XNUMX, али да ли су нам потребни слични ресурси за тестирање ван радног времена? Такође зависи од врсте тестирања која се обавља. Пример би били тестови оптерећења/стрес које планирамо да радимо током нерадног времена како бисмо следећег дана добили резултате. Али дефинитивно доступност сервера XNUMX/XNUMX није потребна за аутоматизоване тестове од краја до краја, а посебно не за окружења за ручно тестирање. За такве ситуације било би добро набавити онолико ресурса колико је потребно на захтев, искористити их и престати да плаћате када више нису потребни. Штавише, било би сјајно да их примите одмах тако што ћете направити неколико кликова мишем или покренути неколико скрипти. За то се користе јавни облаци. Погледајмо дефиницију:
„Јавни облак се дефинише као рачунарске услуге које нуде провајдери трећих страна преко јавног Интернета, чинећи их доступним свима који желе да их користе или купе. Могу бити бесплатни или се продају на захтев, омогућавајући купцима да плате само по употреби за ЦПУ циклусе, складиште или пропусни опсег који троше."
Постоји мишљење да су јавни облаци скупи. Али њихова кључна идеја је смањење трошкова компаније. Као што је раније поменуто, јавни облаци вам омогућавају да добијете ресурсе на захтев и платите само за време које користите. Такође, понекад заборављамо да запослени примају плате, а специјалисти су такође скуп ресурс. Мора се узети у обзир да јавни облаци знатно олакшавају подршку инфраструктуре, што омогућава инжењерима да се фокусирају на важније задатке.
Вредност за инфраструктуру аутоматизације
Који специфични ресурси су нам потребни за енд-то-енд УИ тестове? У основи, ово су виртуелне машине или кластери (о Кубернетес-у ћемо говорити у следећем одељку) за покретање претраживача и емулатора. Што више претраживача и емулатора желимо да покрећемо истовремено, потребно је више ЦПУ-а и меморије и више новца морамо да платимо за то. Дакле, јавни облаци у контексту аутоматизације тестирања омогућавају нам да покренемо велики број (100, 200, 1000...) претраживача/емулатора на захтев, добијемо резултате тестирања што је пре могуће и престанемо да плаћамо за тако сулудо интензивне ресурсе снага.
Најпопуларнији добављачи облака су Амазон Веб Сервицес (АВС), Мицрософт Азуре, Гоогле Цлоуд Платформ (ГЦП). Водич са упутствима пружа примере како да користите ГЦП, али генерално није важно шта користите за задатке аутоматизације. Сви они пружају приближно исту функционалност. Обично, да би изабрао провајдера, менаџмент се фокусира на целокупну инфраструктуру и пословне захтеве компаније, што је ван оквира овог чланка. За инжењере аутоматизације биће интересантније да упореде коришћење клауд провајдера са коришћењем клауд платформи посебно у сврхе тестирања, као што су Сауце Лабс, БровсерСтацк, БитБар и тако даље. Па хајде да урадимо и то! По мом мишљењу, Сауце Лабс је најпознатија фарма за тестирање облака, због чега сам је користио за поређење.
ГЦП наспрам Сауце Лабс за потребе аутоматизације:
Замислимо да треба да покренемо 8 веб тестова и 8 Андроид тестова истовремено. За ово ћемо користити ГЦП и покренути 2 виртуелне машине са Селеноид-ом. На првом ћемо подићи 8 контејнера са претраживачима. На другом се налази 8 контејнера са емулаторима. Хајде да погледамо цене:
Да бисмо покренули један контејнер са Цхроме-ом, треба нам н1-стандард-1 ауто. У случају Андроида биће н1-стандард-4 за један емулатор. У ствари, флексибилнији и јефтинији начин је постављање специфичних корисничких вредности за ЦПУ/Меморију, али то тренутно није важно за поређење са Сауце Лабс.
А ево и тарифа за коришћење Сауце Лабс:
Верујем да сте већ приметили разлику, али ја ћу ипак дати табелу са прорачунима за наш задатак:
Потребни ресурси
Месечно
Радно време(8:8 - XNUMX:XNUMX)
Радно време+ Преемптибле
ГЦП за веб
н1-стандард-1 к 8 = н1-стандард-8
$194.18
23 дана * 12 сати * 0.38 = 104.88 УСД
23 дана * 12 сати * 0.08 = 22.08 УСД
Сауце Лабс за веб
Виртуелни Цлоуд8 паралелни тестови
$1.559
-
-
ГЦП за Андроид
н1-стандард-4 к 8: н1-стандард-16
$776.72
23 дана * 12 сати * 1.52 = 419.52 УСД
23 дана * 12 сати * 0.32 = 88.32 УСД
Сауце Лабс за Андроид
Реал Девице Цлоуд 8 паралелни тестови
$1.999
-
-
Као што видите, разлика у цени је огромна, посебно ако тестирате само током дванаесточасовног радног периода. Али можете још више смањити трошкове ако користите машине које се могу искључити. Шта је то?
Преемптибилни ВМ је инстанца коју можете креирати и покренути по много већој цени од нормалних инстанци. Међутим, Цомпуте Енгине може да прекине (предузме) ове инстанце ако захтева приступ тим ресурсима за друге задатке. Преемптибилне инстанце су вишак капацитета Цомпуте Енгине-а, тако да њихова доступност варира у зависности од употребе.
Ако су ваше апликације толерантне на грешке и могу да издрже могуће преузеће инстанце, онда инстанце које се могу преокупити могу значајно да смање трошкове Цомпуте Енгине-а. На пример, послови групне обраде могу да се покрећу на инстанцама које се могу преузети. Ако се неке од тих инстанци прекину током обраде, посао се успорава, али се не зауставља у потпуности. Преемптибилне инстанце довршавају ваше задатке групне обраде без постављања додатног оптерећења на ваше постојеће инстанце и без потребе да плаћате пуну цену за додатне нормалне инстанце.
И још увек није готово! У стварности, сигуран сам да нико не ради тестове 12 сати без паузе. А ако јесте, онда можете аутоматски покренути и зауставити виртуелне машине када нису потребне. Стварно време употребе може се смањити на 6 сати дневно. Тада ће се плаћање у контексту нашег задатка смањити на 11 УСД месечно за 8 претраживача. Зар ово није дивно? Али са машинама које се могу искључити морамо бити пажљиви и спремни за прекиде и нестабилност, иако се ове ситуације могу предвидети и решити у софтверу. Вреди!
Али нипошто не кажем „никада не користите фарме за тестирање у облаку“. Имају низ предности. Пре свега, ово није само виртуелна машина, већ потпуно решење за аутоматизацију тестирања са скупом функционалности из кутије: даљински приступ, евиденције, снимке екрана, видео снимање, разни претраживачи и физички мобилни уређаји. У многим ситуацијама, ово може бити суштинска шик алтернатива. Платформе за тестирање су посебно корисне за аутоматизацију иОС-а, када јавни облаци могу да понуде само Линук/Виндовс системе. Али о иОС-у ћемо говорити у следећим чланцима. Препоручујем да увек сагледате ситуацију и пођете од задатака: у неким случајевима је јефтиније и ефикасније користити јавне облаке, ау другима тест платформе дефинитивно вреде потрошеног новца.
Илустрација тренутног стања инфраструктуре
Везе за истраживање
Слични алати:
6. Оркестрација
Кратак опис технологије
Имам добре вести – скоро смо на крају чланка! У овом тренутку, наша инфраструктура за аутоматизацију се састоји од веб и Андроид тестова, које паралелно изводимо кроз ГитЛаб ЦИ, користећи алате омогућене за Доцкер: Селениум грид и Селеноид. Штавише, користимо виртуелне машине креиране преко ГЦП-а за хостовање контејнера са претраживачима и емулаторима. Да бисмо смањили трошкове, покрећемо ове виртуелне машине само на захтев и заустављамо их када се тестирање не спроводи. Постоји ли још нешто што може побољшати нашу инфраструктуру? Одговор је да! Упознајте Кубернетес (К8с)!
Прво, погледајмо како су речи оркестрација, кластер и Кубернетес међусобно повезане. На високом нивоу, оркестрација је систем који примењује и управља апликацијама. За аутоматизацију тестирања, такве контејнерске апликације су Селениум грид и Селеноид. Доцкер и К8 се допуњују. Први се користи за примену апликације, други за оркестрацију. Заузврат, К8с је кластер. Задатак кластера је да користи ВМ као чворове, што вам омогућава да инсталирате различите функционалности, програме и услуге унутар једног сервера (кластера). Ако неки од чворова поквари, други чворови ће се покупити, што обезбеђује непрекидан рад наше апликације. Поред тога, К8с има важну функционалност која се односи на скалирање, захваљујући којој аутоматски добијамо оптималну количину ресурса на основу оптерећења и постављених ограничења.
Истина, ручно постављање Кубернетеса од нуле уопште није тривијалан задатак. Оставићу везу до познатог водича „Кубернетес Тхе Хард Ваи“ и ако сте заинтересовани, можете га вежбати. Али, на срећу, постоје алтернативне методе и алати. Најлакши начин је да користите Гоогле Кубернетес Енгине (ГКЕ) у ГЦП-у, који ће вам омогућити да добијете готов кластер у неколико кликова. Препоручујем да користите овај приступ да бисте започели учење, јер ће вам омогућити да се фокусирате на учење како да користите К8с за своје задатке уместо да научите како унутрашње компоненте треба да буду интегрисане једна са другом.
Вредност за инфраструктуру аутоматизације
Хајде да погледамо неколико значајних карактеристика које К8с пружа:
- примена апликације: коришћење кластера са више чворова уместо ВМ-а;
- динамичко скалирање: смањује трошкове ресурса који се користе само на захтев;
- самоизлечење: аутоматски опоравак махуна (као резултат тога се обнављају и контејнери);
- увођење ажурирања и враћање измена без прекида: ажурирање алата, претраживача и емулатора не прекида рад тренутних корисника
Али К8с још увек није сребрни метак. Да бисмо разумели све предности и ограничења у контексту алата које разматрамо (Селениум грид, Селеноид), укратко ћемо размотрити структуру К8с. Кластер садржи две врсте чворова: главне чворове и радничке чворове. Главни чворови су одговорни за управљање, распоређивање и одлуке о распореду. Раднички чворови су места на којима се покрећу апликације. Чворови такође садрже окружење за извршавање контејнера. У нашем случају, ово је Доцкер, који је одговоран за операције везане за контејнере. Али постоје и алтернативна решења, нпр. Важно је разумети да се скалирање или самозалечење не примењују директно на контејнере. Ово се имплементира додавањем/смањивањем броја подова, који заузврат садрже контејнере (обично један контејнер по махуни, али у зависности од задатка може их бити и више). Хијерархију високог нивоа чине чворови радника, унутар којих се налазе махуне, унутар којих су подигнути контејнери.
Функција скалирања је кључна и може се применити на оба чвора унутар скупа чворова кластера и на подове унутар чвора. Постоје 2 врсте скалирања које се примењују и на чворове и на махуне. Први тип је хоризонтални – скалирање се дешава повећањем броја чворова/подова. Овај тип је пожељнији. Други тип је, сходно томе, вертикални. Скалирање се врши повећањем величине чворова/подова, а не њиховог броја.
Погледајмо сада наше алате у контексту горњих појмова.
Селенска мрежа
Као што је раније поменуто, Селениум грид је веома популаран алат и није изненађење што је у контејнерима. Стога не чуди што се Селенијум мрежа може применити у К8с. Пример како се то ради може се наћи у званичном К8с спремишту. Као и обично, прилажем линкове на крају одељка. Поред тога, водич са упутствима показује како се то ради у Терраформу. Такође постоје упутства о томе како да скалирате број подова који садрже контејнере претраживача. Али функција аутоматског скалирања у контексту К8с још увек није сасвим очигледан задатак. Када сам почео да учим, нисам нашао никакве практичне смернице или препоруке. Након неколико студија и експеримената уз подршку ДевОпс тима, изабрали смо приступ подизања контејнера са потребним претраживачима унутар једног пода, који се налази унутар једног радног чвора. Овај метод нам омогућава да применимо стратегију хоризонталног скалирања чворова повећањем њиховог броја. Надам се да ће се то променити у будућности и да ћемо видети све више описа бољих приступа и готових решења, посебно након изласка Селениум грид 4 са измењеном интерном архитектуром.
Селеноид:
Примена селеноида у К8с је тренутно највеће разочарење. Нису компатибилни. У теорији, можемо да подигнемо Селеноид контејнер унутар модула, али када Селеноид почне да покреће контејнере са претраживачима, они ће и даље бити унутар истог модула. Ово онемогућава скалирање и, као резултат, рад Селеноида унутар кластера неће се разликовати од рада унутар виртуелне машине. Крај приче.
Месец:
Знајући ово уско грло у раду са Селеноидом, програмери су објавили моћнији алат под називом Моон. Овај алат је првобитно дизајниран да ради са Кубернетес-ом и, као резултат, функција аутоматског скалирања може и треба да се користи. Штавише, рекао бих да у овом тренутку јесте сингл алат у свету Селенијума, који има изворну подршку за К8с кластер из кутије (више није доступно, погледајте следећи алат ). Кључне карактеристике Моон-а које пружају ову подршку су:
Потпуно без држављанства. Селеноид складишти у меморији информације о тренутно покренутим сесијама претраживача. Ако се из неког разлога његов процес сруши — онда су све активне сесије изгубљене. Месец напротив нема унутрашње стање и може се реплицирати у центрима података. Сесије претраживача остају активне чак и ако се једна или више реплика поквари.
Дакле, Месец је одлично решење, али постоји један проблем: није бесплатан. Цена зависи од броја сесија. Можете покренути само 0-4 сесије бесплатно, што није посебно корисно. Али, почевши од пете сесије, мораћете да платите 5 долара за сваку. Ситуација се може разликовати од компаније до компаније, али у нашем случају коришћење Месеца је бесмислено. Као што сам горе описао, можемо покренути ВМ са Селениум Грид-ом на захтев или повећати број чворова у кластеру. За отприлике један цевовод покрећемо 500 претраживача и заустављамо све ресурсе након што се тестови заврше. Ако бисмо користили Месец, морали бисмо да платимо додатних 500 к 5 = 2500 долара месечно, без обзира колико често радимо тестове. Опет, не кажем да не користите Месец. За ваше задатке, ово може бити незаменљиво решење, на пример, ако имате много пројеката/тимова у вашој организацији и потребан вам је огроман заједнички кластер за све. Као и увек, остављам везу на крају и препоручујем да извршите све потребне прорачуне у контексту вашег задатка.
Калисто: (Пажња! Ово није у оригиналном чланку и налази се само у преводу на руски)
Као што сам рекао, Селен је веома популаран алат, а ИТ област се веома брзо развија. Док сам радио на преводу, на вебу се појавио нови обећавајући алат под називом Цаллисто (здраво Ципресс и друге убице селена). Нативно ради са К8с и омогућава вам да покренете Селеноид контејнере у подовима, распоређеним по чворовима. Све ради одмах из кутије, укључујући аутоматско скалирање. Фантастично, али треба тестирати. Већ сам успео да применим овај алат и извршим неколико експеримената. Али прерано је доносити закључке, након што добијем резултате на великој удаљености, можда ћу направити преглед у будућим чланцима. За сада остављам само везе за независно истраживање.
Илустрација тренутног стања инфраструктуре
Везе за истраживање
Слични алати
7. Инфраструктура као код (ИаЦ)
Кратак опис технологије
И сада долазимо до последњег одељка. Обично ова технологија и повезани задаци нису одговорност инжењера аутоматизације. И за то постоје разлози. Прво, у многим организацијама, инфраструктурна питања су под контролом ДевОпс одељења и развојним тимовима није баш стало до тога шта чини да цевовод функционише и како све што је повезано са њим треба да буде подржано. Друго, будимо искрени, пракса Инфраструктура као кодекс (ИаЦ) још увек није усвојена у многим компанијама. Али то је дефинитивно постао популаран тренд и важно је покушати да будете укључени у процесе, приступе и алате који су са њим повезани. Или барем останите у току.
Почнимо са мотивацијом за коришћење овог приступа. Већ смо разговарали о томе да ће нам за покретање тестова у ГитлабЦИ-у бити потребни барем ресурси за покретање Гитлаб Руннер-а. А да бисмо покренули контејнере са претраживачима/емулаторима, морамо да резервишемо ВМ или кластер. Поред ресурса за тестирање, потребна нам је значајна количина капацитета за подршку развојним, сценским, производним окружењима, што такође укључује базе података, аутоматске распореде, мрежне конфигурације, балансере оптерећења, корисничка права и тако даље. Кључно питање је напор који је потребан да се све то подржи. Постоји неколико начина на које можемо да унесемо промене и уведемо ажурирања. На пример, у контексту ГЦП-а, можемо да користимо УИ конзолу у прегледачу и да извршимо све радње кликом на дугмад. Алтернатива би била употреба АПИ позива за интеракцију са ентитетима у облаку или употреба услужног програма командне линије гцлоуд да извршите жељене манипулације. Али са заиста великим бројем различитих ентитета и инфраструктурних елемената, постаје тешко или чак немогуће извршити све операције ручно. Штавише, све ове ручне радње су неконтролисане. Не можемо их послати на преглед пре извршења, користити систем контроле верзија и брзо вратити промене које су довеле до инцидента. Да би решили такве проблеме, инжењери су креирали и креирали аутоматске басх/схелл скрипте, које нису много боље од претходних метода, пошто их није тако лако брзо прочитати, разумети, одржавати и модификовати у процедуралном стилу.
У овом чланку и водичу са упутствима користим 2 алата везана за праксу ИаЦ-а. То су Терраформ и Ансибле. Неки људи сматрају да их нема смисла користити истовремено, јер су им функционалност слична и заменљиви су. Али чињеница је да им се у почетку дају потпуно другачији задаци. А да би ови алати требало да се допуњују, потврдили су на заједничкој презентацији програмери који представљају ХасхиЦорп и РедХат. Концептуална разлика је у томе што је Терраформ алат за обезбеђивање за управљање самим серверима. Док је Ансибле алат за управљање конфигурацијом чији је задатак да инсталира, конфигурише и управља софтвером на овим серверима.
Још једна кључна карактеристика ових алата је стил кодирања. За разлику од басх-а и Ансибле-а, Терраформ користи декларативни стил заснован на опису жељеног крајњег стања које треба постићи као резултат извршења. На пример, ако ћемо креирати 10 ВМ-а и применити промене преко Терраформ-а, онда ћемо добити 10 ВМ-а. Ако поново покренемо скрипту, ништа се неће догодити пошто већ имамо 10 ВМ-ова, а Терраформ зна за ово јер чува тренутно стање инфраструктуре у датотеци стања. Али Ансибле користи процедурални приступ и, ако од њега затражите да креира 10 ВМ, онда ћемо при првом покретању добити 10 ВМ, сличних Терраформу. Али након поновног покретања већ ћемо имати 20 ВМ-ова. Ово је битна разлика. У процедуралном стилу, ми не чувамо тренутно стање и једноставно описујемо низ корака који се морају извршити. Наравно, можемо да се носимо са разним ситуацијама, додамо неколико провера постојања ресурса и тренутног стања, али нема смисла губити време и улагати се у контролу ове логике. Поред тога, ово повећава ризик од грешака.
Сумирајући све горе наведено, можемо закључити да су Терраформ и декларативне нотације погоднији алат за обезбеђивање сервера. Али боље је делегирати посао управљања конфигурацијом на Ансибле. Уз то, хајде да погледамо случајеве употребе у контексту аутоматизације.
Вредност за инфраструктуру аутоматизације
Једина важна ствар коју треба разумети је да инфраструктуру за аутоматизацију тестирања треба посматрати као део целокупне инфраструктуре компаније. То значи да се све праксе ИаЦ-а морају применити глобално на ресурсе целе организације. Ко је одговоран за ово зависи од ваших процеса. ДевОпс тим је искуснији у овим питањима, они виде целу слику онога што се дешава. Међутим, КА инжењери су више укључени у процес аутоматизације зграда и структуре цевовода, што им омогућава да боље сагледају све потребне промене и могућности за побољшање. Најбоља опција је заједнички рад, размена знања и идеја за постизање очекиваног резултата.
Ево неколико примера коришћења Терраформ и Ансибле у контексту аутоматизације тестирања и алата о којима смо раније разговарали:
1. Опишите потребне карактеристике и параметре ВМ-а и кластера користећи Терраформ.
2. Користећи Ансибле, инсталирајте алате неопходне за тестирање: доцкер, Селеноид, Селениум Грид и преузмите потребне верзије претраживача/емулатора.
3. Користећи Терраформ, опишите карактеристике ВМ-а у којем ће ГитЛаб Руннер бити покренут.
4. Инсталирајте ГитЛаб Руннер и потребне пратеће алате користећи Ансибле, подесите подешавања и конфигурације.
Илустрација тренутног стања инфраструктуре
Линкови за истраживање:
Слични алати
Хајде да сумирамо!
Корак
технологија
алат
Вредност за инфраструктуру аутоматизације
1
Локално трчање
Ноде.јс, Селен, Аппиум
- Најпопуларнији алати за веб и мобилне уређаје
- Подржава многе језике и платформе (укључујући Ноде.јс)
2
Системи контроле верзија
гит
- Сличне предности са развојним кодом
3
Контејнеризација
Доцкер, Селениум грид, Селеноид (Веб, Андроид)
- Паралелно извођење тестова
- Изолована окружења
- Једноставне, флексибилне надоградње верзије
- Динамичко заустављање неискоришћених ресурса
- Једноставно постављање
4
ЦИ/ЦД
Гитлаб ЦИ
- Тестира део цевовода
- Брза повратна информација
- Видљивост за целу компанију/тим
5
Цлоуд платформе
Гоогле Цлоуд Платформ
- Ресурси на захтев (плаћамо само када је потребно)
- Једноставан за управљање и ажурирање
- Видљивост и контрола свих ресурса
6
Оркестрација
Кубернетес
У контексту контејнера са прегледачима/емулаторима унутар подова:
- Скалирање/аутоматско скалирање
- Самоизлечење
- Ажурирања и враћања без прекида
7
Инфраструктура као код (ИаЦ)
Терраформ, Ансибле
- Сличне погодности са развојном инфраструктуром
- Све предности верзионисања кода
- Лако се мења и одржава
- Потпуно аутоматизован
Дијаграми мапе ума: еволуција инфраструктуре
корак 1: Локално
корак 2: ВЦС
корак 3: Контејнеризација
корак 4: ЦИ/ЦД
корак 5: Цлоуд платформе
корак 6: Оркестрација
корак 7: ИаЦ
Шта је следеће?
Дакле, ово је крај чланка. Али у закључку, желео бих да успоставим неке договоре са вама.
Са ваше стране
Као што је речено на почетку, волео бих да чланак буде од практичне користи и да вам помогне да стечено знање примените у стварном раду. Опет додајем.
Али чак и након тога, немојте стати, вежбајте, проучавајте релевантне линкове и књиге, сазнајте како то функционише у вашој компанији, пронађите места која се могу побољшати и укључите у то. Срећно!
Из мог угла
Из наслова се види да је ово био само први део. Упркос чињеници да се испоставило да је прилично обимна, важне теме овде још увек нису обрађене. У другом делу планирам да погледам инфраструктуру аутоматизације у контексту ИОС-а. Због Аппле-ових ограничења за покретање иОС симулатора само на мацОС системима, наш опсег решења је сужен. На пример, не можемо да користимо Доцкер за покретање симулатора или јавне облаке за покретање виртуелних машина. Али то не значи да нема других алтернатива. Покушаћу да вас држим у току са напредним решењима и савременим алатима!
Такође, нисам поменуо прилично велике теме везане за мониторинг. У трећем делу, погледаћу најпопуларније алате за праћење инфраструктуре и које податке и метрике треба узети у обзир.
И коначно. У будућности планирам да објавим видео курс о изградњи тестне инфраструктуре и популарних алата. Тренутно постоји доста курсева и предавања о ДевОпс-у на Интернету, али сви материјали су представљени у контексту развоја, а не аутоматизације тестирања. По овом питању, заиста ми је потребна повратна информација о томе да ли ће такав курс бити занимљив и вредан за заједницу тестера и инжењера аутоматизације. Хвала унапред!
Извор: ввв.хабр.цом