Хабрахабр

Строим пайплайн автоматизированного тестирования на Azure DevOps

Недавно я столкнулся с не очень популярным пока зверем в мире DevOps, пайплайнами Azure DevOps. Сразу же ощутил отсутствие каких то внятных инструкций или статей на тему, не знаю с чем это связанно, но Microsoft явно есть над чем поработать в плане популяризации инструмента. Сегодня мы построим пайплайн для автоматизированного тестирования внутри облака Azure.

Если будет интерес, напишу и об этом инструменте. Итак, задача:
Имеется софт, который билдят при помощи того же Azure DevOps, собирают из проекта на WIX. Итак, наш софт успешно собирается и генерирует артефакт, некий setup.exe, который ставит приложение в систему Windows. По факту это более оптимизированный под автоматизацию способ сборки виндовых установщиков, заменяющий собой стандартный InstallShield. Все как в GitLab, только через ж.... Необходимо это приложение поставить в похожую на прод виртуалку, скопировать туда автоматизированные тесты, подготовленные командой тестирования, запустить их и забрать результаты, чтобы считать ветку хорошей или плохой, прежде чем мерджить.

В качестве среды виртуализации, где мы будем исполнять наши тесты, используем, очевидно, Azure DevTest Labs, некую сущность в подписках Azure, которая для того и создана, чтобы крутить в ней всякую тестовую ерунду за приемлимые деньги.

Для начала нам потребуется интегрировать наш DevTest Labs с Azure DevOps, для чего нам необходим некий Service Principal, по сути сервисная учетная запись, которая позволяет ходить пайплайнам в облако и создавать/удалять там ресурсы для себя.

Идем в подписку и находим сервис Azure Active Directory

Подробно разбирать какие настройки выбрать при создании не буду, это может отличаться у разных подписок. Находим App Registrations и кликаем на New Registration, это нам создаст нашего service principal.

Для этого идем в подписки, значок с ключиком. Теперь нам нужно дать права нашему сервисному директору. Выбираем нашу подписку.

Даем роль Contributor, этого достаточно. Далее в Access Control жмем Role Assignment и ищем в поиске по созданному только что имени эту учетку.

Позже, нам будут нужны будут все ID которые там есть, сохраняем их. Далее возвращаемся к нашему Service Principal в Azure AD и открываем его свойства.

На этом наши настройки портала заканчиваются и мы переходим в Azure DevOps.

Первым делом мы зайдем в настройки проекта и выбираем Service Connections. Создаем новый элемент типа Azure Resource Manager.

Кликаем на use the full version of the service connection dialog. Сейчас нам понадобятся все ID что мы записали. Жмем verify и если все отлично сохраняем соединение. И вводим все данные что мы получили от Service Principal. Теперь наши пайплайны могут его использовать для подключения к облаку.

Теперь приступаем к самому интересному, построению непосредственно пайплайна. Открываем меню Pipelines-Builds

Мы вежливо отказываемся от этого и выбираем классический вариант. Нас встречает меню создания нового билда, которое по умолчанию попытается создать нам YAML файл подходящей конфигурации. Понятно желание Microsoft сделать все как у людей и дать возможность максимально кастомизировать пайплайны через YAML, но скупая документация и просто практическая неработоспособность многих модулей говорит нам, что пока рано пользоваться этой функциональностью.

После его создания нас встречает пустое окошко редактирования, в нем мы дальше проведем довольно много времени. Из многообразия шаблонов нам потребуется простой Empty Pipeline.

Итак, нажимаем на + и попадаем в некий магазин модулей, откуда нам потребуются по списку следующие компоненты.

Это будут ARM Template нашей виртуальной машины, который мы сгенерируем в Azure DevTest Labs, скрипт доставания IP машины после того как она создана ну и, по желанию, скрипты наших тестов или того, что мы хотим на хосте запускать. Прежде чем мы приступим к конфигурации тасков пайплайна, нам нужно сформировать и положить в проект несколько файлов.

Чтобы создать виртуалку, нам необходимо будет для начала сгенерировать для нее темплейт, json файл, который мы положим в код проекта, чтобы его оттуда смог прочитать пайплайн.

Идем в нашу лабу и находим меню Formulas (reusable bases), жмем создать новую.

На этом этапе мы останавливаться не будем, сразу перейдем к последнему пункту свойств машины, а именно артефактам. Нас встретит длинный список имаджей в качестве базы, выбор размера машины, все то же самое как и при создании виртуалки. Например, я добавляю машину в домен и добавляю на нее сервисный аккаунт в качестве админа, чтобы пайплайн потом мог на эту машину заходить под этой учетной записью. Вы можете использовать любые конфигурации, которые необходимы для вашей среды. Чтобы на нашу машину поставилась последняя версия тестируемого нами софта, мы будем использовать артефакт «Download Azure Pipelines Artifact and Run Script». Это все может варьироваться, но для успешного тестирования кода нам необходим один артефакт, на котором остановимся подробнее. Вот сейчас нам необходимо сказать виртуалке, а точнее темплейту, чтобы он пошел и забрал этот артефакт. Помните в начале я говорил что где-то собирается билд с установщиком приложения? Секретный ключ, как и во всех системах подобного рода, генерируется в учетной записи, в данном случае в Azure DevOps и сохраняется в Secrets в вашей лабе. И не просто забрал, а еще установил, для чего заполняем специальные поля с указанием проекта, названия билда и секретного ключа. Тут есть маленькая оговорка, в Secrets то мы его сохраним, но темплейту от этого ни холодно ни жарко, он будет запускаться уже от другого пользователя в рамках пайплайна, по этому секретный ключ нам надо будет еще раз вручную внести в темплейт.

Там всего один параметр, hostname. Еще один артефакт, который нужно обязательно включить, это «Configure WinRM», нам он понадобится для последующего доступа на машину. Так как мы его заранее не знаем, воспользуемся переменной %COMPUTERNAME%.

Достаем сгенерированный ARM Template во вкладке Advanced того же окна создания формулы. Итак мы добавили все нужные артефакты, переходим к тому зачем мы сюда вообще пришли.

Больше нам облако не нужно, возвращаемся в пайплайн. Копируем содержимое страницы в файл VMtemplate.json и кладем его в корень проекта.

Начнем с самого важного и инетерсного, создания виртуалки, ради этого мы и делали все эти интеграции и темплейты. В пункте Azure RM Subscription мы выбираем наш Service connection, который мы сконфигурировали в пункте 2. Далее должна будет выскочить доступная нам лабороторная среда. Потом выбираем json который мы сгенерировали и определяем некоторые обязательные переменные. Логин и пароль от машины можно задать или на прямую или переменными, но я вообще не уверен что он работает, что бы я туда не писал, зайти на машину потом под этими кредами не получалось, главное задать имя машины, чтобы оно по возможности было всегда уникальным. Для этого я использую переменную среды билда.

После того как машина взлетит, нам же нужно как то знать ее параметры, а лучше не нам а пайплайну. Далее мы настраиваем еще один немаловажный момент. Текст скрипта я взял на сайте Microsoft, но немного подправил его для своей среды, т.к. Для этого мы делаем скрипт, к примеру GetLabVMParams.ps1 и кладем его туда же, в проект. Ни того ни другого у меня нет, но есть PrivateIP который не так то просто достать, по этому я дописал кусок. он брал PublicIP и FQDN машины.

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:\localhost\client\trustedhosts * -Force

Из всего, что считывает скрипт, нам нужна только переменная labVMIpAddress. Ну это мне, может вам еще что-то понадобится, по этому я ничего не удалял и просто закоментировал лишнее.

Так же объясню последнюю строчку скрипта, она разрешает нашей билд машине доступ до любого хоста по WinRM.

Ему потребуется то же самое соединение с облаком, входная переменная с ID машины, которое будет к тому моменту уже известно из предыдущего шага. Следующим этапом мы запускаем наш замечательный скрипт. Тут нужно упомянуть о такой замечательной вещи, как Output Variables. Как? Соответственно для нашего супер скрипта такой переменной будет labVMIpAddress, не забудьте это указать. У каждого шага может быть список переменных которые передаются дальше, следующим шагам пайплайна.

Исполняю удаленный скрипт с созданием шары, в которую потом буду загружать свои скрипты. Далее я делаю довольно простые вещи, которые, к тому же, могут варьироваться от кейса к кейсу.

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

Из названия тасок понятно, что дальше мы копируем некоторый sample script на машину и еще одним этапом его исполняем. В качестве адреса удаленной машины нам пригодится наша переменная $(labVMIpAddress). Далее мы используем таску «забрать артефакт с шары» и копируем результаты исполнения скрипта себе в билд среду, потом такой же стандартной таской сохраняем эти файлы в артефакт билда. После того как машина нам больше не нужна, последним этапом её убиваем. Главная сложность, как видно по объему статьи, это интегрироваться с облаком и наладить контакт с виртуалкой, которую вы создали, дальше уже можно развлекаться сколько нужно.

Это моя первая статья, так что не судите строго, замечания приветствуются.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть