Недавно сам наишао на не тако популарну звер у ДевОпс свету, Азуре ДевОпс цевоводе. Одмах сам осетио недостатак јасних упутстава или чланака на ту тему, не знам са чиме је то повезано, али Мицрософт очигледно има на чему да ради у смислу популаризације алата. Данас ћемо изградити цевовод за аутоматизовано тестирање унутар Азуре облака.

Дакле, задатак:
Постоји софтвер који је направљен коришћењем истог Azure DevOps-а, компајлиран из WIX пројекта. Ако буде интересовања, писаћу и о овом алату. У суштини, то је аутоматизованији начин за изградњу Windows инсталера, који замењује стандардни InstallShield. Дакле, наш софтвер се успешно изграђује и генерише артефакт, setup.exe, који инсталира апликацију у систем. WindowsПотребно је да инсталирате ову апликацију на виртуелну машину сличну продукцијској, копирате аутоматизоване тестове које је припремио тим за тестирање, покренете их и прикупите резултате како бисте утврдили да ли је грана добра или лоша пре спајања. То је баш као у ГитЛабу, само преко задњице.

Као окружење виртуелизације у којем ћемо извршавати наше тестове, очигледно користимо Азуре ДевТест Лабс, одређени ентитет у Азуре претплатама, који је креиран за ову сврху да би у њему за разумне паре покренули све врсте тестирања глупости.

1. Интеграција на страни облака

Прво, морамо да интегришемо наше ДевТест Лабс са Азуре ДевОпс-ом, за шта нам је потребан одређени Сервице Принципал, у суштини налог услуге који омогућава цевоводима да иду у облак и сами креирају/бришу ресурсе тамо.

Идите на претплату и пронађите услугу Азуре Ацтиве Дирецтори

Пронађите Регистрације апликације и кликните на Нова регистрација, ово ће креирати принципал наше услуге. Нећу улазити у детаље о томе која подешавања да одаберете када га креирате; ово се може разликовати за различите претплате.

Сада треба да дамо права нашем директору сервиса. Да бисте то урадили, идите на претплате, икону са кључем. Изаберите нашу претплату.

Затим, у Контроли приступа, кликните на Додељивање улоге и потражите овај налог користећи име које сте управо креирали. Дајемо Цонтрибутор улогу, то је довољно.

Затим се враћамо на наш Принципал услуге у Азуре АД и отварамо његова својства. Касније ће нам требати све личне карте које постоје, сачуваћемо их.

Овим завршавамо подешавања нашег портала и прелазимо на Азуре ДевОпс.

2. Интеграција на Азуре ДевОпс страни

Пре свега, идемо на подешавања пројекта и изаберите Сервице Цоннецтионс. Креирајте нови елемент типа Азуре Ресоурце Манагер.

Сада ће нам требати све личне карте које смо записали. Кликните на користи пуну верзију дијалога за повезивање услуге. И уносимо све податке које смо добили од директора сервиса. Кликните на потврди и ако је све у реду, сачувајте везу. Сада наши цевоводи могу да га користе за повезивање са облаком.

3. Креирање цевовода

Сада пређимо на забавни део, изградњу самог цевовода. Отворите мени Пипелинес-Буилдс

Дочекује нас мени за креирање нове верзије, која ће подразумевано покушати да креира ИАМЛ датотеку за нас са одговарајућом конфигурацијом. Ми то љубазно одбијамо и одлучујемо се за класичну опцију. Разумљиво је да Мицрософт жели да уради све као што раде људи и да пружи могућност да се цевоводи прилагођавају што је више могуће преко ИАМЛ-а, али оскудна документација и једноставно практична неоперабилност многих модула нам говоре да је прерано да користимо ову функционалност.

Од разних шаблона, потребан нам је једноставан Емпти Пипелине. Након креирања, дочека нас празан прозор за уређивање, у којем ћемо провести доста времена.

Дакле, кликните на + и нађите се у одређеној продавници модула, одакле ће нам требати следеће компоненте са листе.

Пре него што почнемо да конфигуришемо задатке цевовода, морамо да генеришемо и ставимо неколико датотека у пројекат. Ово ће бити АРМ шаблон наше виртуелне машине, који ћемо генерисати у Азуре ДевТест Лабс, скрипта за добијање ИП-а машине након што је креирана и, по жељи, скрипте за наше тестове или оно на чему желимо да покренемо домаћин.

4. Генерисање АРМ шаблона

Да бисмо направили виртуелну машину, прво ћемо морати да генеришемо шаблон за њу, јсон датотеку, коју ћемо ставити у код пројекта како би цевовод могао да је прочита одатле.

Идемо у нашу лабораторију и пронађемо мени Формуле (базе за вишекратну употребу), кликните на креирање новог.

Дочекаће нас дугачка листа слика као основа, избор величине машине и исти поступак као приликом креирања виртуелне машине. Нећемо се задржавати на овом кораку; прећи ћемо директно на последњу ставку у својствима машине, наиме, артефакте. Можете користити било које конфигурације потребне за ваше окружење. На пример, додајем машину у domena Додајем сервисни налог као администратор како би се цевовод затим могао пријавити на ову машину под овим налогом. Све ово може да варира, али да бисмо успешно тестирали код, потребан нам је један артефакт, о чему ћемо детаљније говорити. Да бисмо осигурали да је најновија верзија софтвера који тестирамо инсталирана на нашој машини, користићемо артефакт „Преузми Azure цевоводни артефакт и покрени скрипту“. Сећате се на почетку када сам поменуо да се негде компајлира верзија са инсталатером апликације? Сада треба да кажемо виртуелној машини, или прецизније, шаблону, да оде и преузме овај артефакт. И не само да га преузме, већ и да га инсталира, за шта попуњавамо посебна поља која наводе пројекат, име верзије и тајни кључ. Тајни кључ, као и у свим сличним системима, генерише се на налогу — у овом случају, у Azure DevOps — и чува се у Secrets у вашој лабораторији. Овде постоји мала напомена: сачуваћемо га у Secrets, али шаблону неће бити стало. Покренуће га други корисник унутар цевовода, тако да ћемо морати поново ручно да унесемо тајни кључ у шаблон.

Још један артефакт који мора бити укључен је „Конфигуришите ВинРМ“ биће нам потребан за накнадни приступ машини. Постоји само један параметар, име хоста. Пошто то не знамо унапред, користићемо променљиву %ЦОМПУТЕРНАМЕ%.

Дакле, додали смо све неопходне артефакте, пређимо на то зашто смо уопште дошли овде. Извлачимо генерисани АРМ шаблон на картици Напредно у истом прозору за креирање формуле.

Копирамо садржај странице у датотеку ВМтемплате.јсон и стављамо је у корен пројекта. Облак нам више није потребан, вратимо се на цевовод.

5. Конфигурација цевовода

Почнимо са најважнијом и најинтересантнијом ствари, стварањем виртуелне машине, за ово смо урадили све ове интеграције и шаблоне. У ставци Азуре РМ Претплата бирамо нашу Сервисну везу, коју смо конфигурисали у кораку 2. Затим би требало да се појави лабораторијско окружење које нам је доступно. Затим бирамо јсон који смо генерисали и дефинишемо неке потребне променљиве. Корисничко име и лозинка за машину могу да се подесе директно или помоћу променљивих, али уопште нисам сигуран да ради, без обзира шта сам тамо написао, нисам могао да се пријавим на машину користећи ове акредитиве, главна ствар је подесити име машине тако да увек буде тамо, ако је могуће јединствено. За ово користим променљиву окружења за изградњу.

Затим постављамо још једну важну тачку. Након што ауто полети, морамо некако да знамо његове параметре, или још боље, не за нас, већ за цевовод. Да бисмо то урадили, правимо скрипту, на пример ГетЛабВМПарамс.пс1 и стављамо је тамо, у пројекат. Узео сам текст скрипте са Мицрософт веб локације, али сам га мало прилагодио свом окружењу, јер... узео је ПублицИП и ФКДН машине. Немам ни једно ни друго, али имам ПриватеИП, који није тако лако добити, зато сам додао комад.

Param( [string] $labVmId)

$labVmComputeId = (Get-AzureRmResource -Id $labVmId).Properties.ComputeId

# Get lab VM resource group name
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Get the lab VM Name
$labVmName = (Get-AzureRmResource -Id $labVmId).Name

# Get lab VM public IP address
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

# Get lab VM FQDN
# $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn

# Get lab VM private IP address
$VmNetworkdetails= (((Get-AzureRmVM -ResourceGroupName $labVmRgName -Name $labVmName).NetworkProfile).NetworkInterfaces).Id
$nicname = $VmNetworkdetails.substring($VmNetworkdetails.LastIndexOf("/")+1)
$labVMnetwork = (Get-AzureRmNetworkInterface -Name $nicname -ResourceGroupName $labVmRgName)|Select-Object -ExpandProperty IPConfigurations 
$labVMIpAddress = $labVMnetwork.PrivateIpAddress

# Set a variable labVmRgName to store the lab VM resource group name
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Set a variable labVMIpAddress to store the lab VM Ip address
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Set a variable labVMFqdn to store the lab VM FQDN name
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

Од свега што скрипта чита, потребна нам је само променљива лабВМИпАддресс. Е, то је за мене, можда ти треба још нешто, зато нисам ништа обрисао и само сам коментарисао непотребне ствари.

Такође ћу објаснити последњу линију скрипте која омогућава нашој машини за прављење приступ било ком хосту преко ВинРМ-а.

Следећи корак је покретање нашег дивног сценарија. Биће му потребна иста веза са облаком, улазна варијабла са ИД-ом машине, која ће до тада већ бити позната из претходног корака. Како? Овде треба да поменемо тако дивну ствар као што су излазне варијабле. Сваки корак може имати листу променљивих које се прослеђују на следеће кораке цевовода. Сходно томе, за нашу супер скрипту ова променљива ће бити лабВМИпАддресс, не заборавите да то наведете.

Затим, радим прилично једноставне ствари, које се, штавише, могу разликовати од случаја до случаја. Извршавам удаљену скрипту и правим дељење, у које ћу затим отпремити своје скрипте.

New-Item “C:test" –type directory
New-SMBShare –Name “test” –Path “C:test”  –FullAccess everyone

Из назива задатака је јасно да следеће копирамо неки узорак скрипте на машину и извршимо га у још једном кораку. Наша променљива $(лабВМИпАддресс) биће нам корисна као адреса удаљене машине. Затим користимо задатак „покупи артефакт из муда“ и копирамо резултате извршавања скрипте у наше окружење за прављење, а затим користимо исти стандардни задатак да сачувамо ове датотеке у артефакт изградње. Након што нам ауто више не треба, последњи корак је да га убијемо. Главна потешкоћа, као што се може видети из дужине чланка, је да се интегришете са облаком и успоставите контакт са виртуелном машином коју сте креирали, а онда можете да се забавите колико вам је потребно.

Ово је мој први чланак, тако да не судите престрого, коментари су добродошли.

Извор: ввв.хабр.цом