Недавно я столкнулся с не очень популярным зверем в мире DevOps — конвейерами Azure DevOps. Я сразу почувствовал отсутствие каких-либо четких инструкций или статей по теме, не знаю, с чем это связано, но Microsoft явно есть над чем работать в плане популяризации инструмента.
Сегодня мы построим конвейер автоматического тестирования внутри облака Azure. Итак, задача: Есть ПО, построенное с использованием того же Azure DevOps, собранное из проекта на WIX. Если будет интерес, напишу об этом инструменте.
Фактически, это более оптимизированный для автоматизации способ создания установщиков Windows, заменяющий стандартный InstallShield. Итак, наше программное обеспечение успешно собирается и генерирует артефакт, некий setup.exe, который устанавливает приложение в систему Windows. Вам необходимо поместить это приложение в виртуальную машину, аналогичную производственной, скопировать туда автоматические тесты, подготовленные командой тестирования, запустить их и взять результаты, чтобы перед слиянием считать ветку хорошей или плохой.
Все как в GitLab, только через.
В качестве среды виртуализации, где мы будем выполнять наши тесты, мы, очевидно, используем Azure DevTest Labs, некую сущность в подписках Azure, которая создана для этой цели, чтобы за разумные деньги запускать в ней всякую тестовую ерунду.
1. Интеграция на стороне облака Во-первых, нам нужно интегрировать наши DevTest Labs с Azure DevOps, для чего нам нужен определенный Service Principal, по сути, сервисная учетная запись, которая позволяет конвейерам отправляться в облако и создавать/удалять там ресурсы для себя.
Перейдите в подписку и найдите службу Azure Active Directory. 
Найдите «Регистрации приложений» и нажмите «Новая регистрация».
Это создаст наш субъект-службу.
Я не буду подробно останавливаться на том, какие настройки выбрать при его создании; это может отличаться для разных подписок.
Теперь нам нужно дать права нашему сервисному директору.
Для этого заходим в подписки, иконка с ключиком.
Выберите нашу подписку.
Затем в разделе «Контроль доступа» нажмите «Назначение роли» и найдите эту учетную запись, используя только что созданное имя.
Даём роль Contributor, этого достаточно.
Далее мы возвращаемся к нашему Service Principal в Azure AD и открываем его свойства.
Позже нам понадобятся все идентификаторы, которые там есть, мы их сохраним.
На этом настройка портала завершена, и мы переходим к Azure DevOps.
2. Интеграция на стороне Azure DevOps.
Прежде всего, мы зайдем в настройки проекта и выберем Service Connections. Создайте новый элемент типа Azure Resource Manager. 
Теперь нам понадобятся все идентификаторы, которые мы записали.
Нажмите «Использовать полную версию диалога подключения службы».
И вводим все данные, которые получили от Service Principal. Нажмите «Проверить» и, если все в порядке, сохраните соединение.
Теперь наши конвейеры могут использовать его для подключения к облаку.
3. Создание конвейера
Теперь перейдем к самому интересному — построению самого конвейера.
Откройте меню Pipelines-Builds. 
Нас встречает меню создания новой сборки, которое по умолчанию попытается создать для нас YAML-файл с подходящей конфигурацией.
Мы вежливо отказываемся от этого и выбираем классический вариант. Понятно, что Microsoft хочет сделать всё как люди и дать возможность максимально кастомизировать пайплайны через YAML, но скудная документация и просто практическая неработоспособность многих модулей говорят нам о том, что использовать этот функционал пока рано.
Из всего разнообразия шаблонов нам нужен простой Empty Pipeline. После его создания нас встречает пустое окно редактирования, в котором мы проведем довольно много времени.
Итак, нажимаем на + и оказываемся в определенном магазине модулей, откуда нам потребуются следующие компоненты из списка.
Прежде чем мы начнем настраивать задачи конвейера, нам необходимо сгенерировать и поместить в проект несколько файлов.
Это будет ARM-шаблон нашей виртуальной машины, который мы сгенерируем в Azure DevTest Labs, скрипт для получения IP-адреса машины после ее создания и, при желании, скрипты для наших тестов или того, на чем мы хотим запуститься.
гостья.
4. Генерация шаблона ARM. Чтобы создать виртуальную машину, нам сначала нужно будет сгенерировать для нее шаблон, json-файл, который мы поместим в код проекта, чтобы конвейер мог прочитать его оттуда.
Заходим в нашу лабораторию и находим меню Формулы (многоразовые базы), нажимаем создать новую.
Нас встретит длинный список образов в качестве основы, выбор размера машины, все так же, как и при создании виртуальной машины.
Мы не остановимся на этом этапе; сразу перейдем к последнему пункту свойств машины, а именно к артефактам.
Вы можете использовать любые конфигурации, необходимые для вашей среды.
Например, я добавляю машину в домен и добавляю к ней сервисную учетную запись в качестве администратора, чтобы конвейер мог затем зайти на эту машину под этой учетной записью.
Тут всё может быть по-разному, но для успешного тестирования кода нам нужен один артефакт, на котором мы остановимся подробнее.
Чтобы убедиться, что на нашем компьютере установлена последняя версия тестируемого программного обеспечения, мы будем использовать артефакт «Загрузить артефакт Azure Pipelines и запустить сценарий».
Помните вначале я говорил, что где-то есть сборка с установщиком приложений? Теперь нам нужно сказать виртуальной машине, а точнее шаблону, чтобы она пошла и забрала этот артефакт. И не просто взял, а еще и установил, для чего заполняем специальные поля с указанием проекта, названия сборки и секретного ключа.
Секретный ключ, как и во всех системах такого типа, генерируется в учетной записи, в данном случае в Azure DevOps, и хранится в секретах вашей лаборатории.
Здесь есть небольшой нюанс, мы сохраним его в Secrets, но шаблон не будет ни холодным, ни горячим, он будет запускаться от другого пользователя внутри конвейера, поэтому нам нужно будет снова вручную ввести секретный ключ в шаблон.
Еще один артефакт, который необходимо включить, — «Настроить WinRM»; он понадобится нам для последующего доступа к машине.
Есть только один параметр — имя хоста.
Поскольку мы не знаем этого заранее, мы будем использовать переменную %COMPUTERNAME%.
Итак, мы добавили все необходимые артефакты, давайте перейдем к тому, зачем мы вообще пришли сюда.
Сгенерированный ARM Template выносим во вкладку Advanced того же окна создания формулы.
Копируем содержимое страницы в файл VMtemplate.json и помещаем в корень проекта.
Облако нам больше не нужно, вернемся к конвейеру.
5. Конфигурация конвейера Начнем с самого важного и интересного, создания виртуальной машины, для этого мы делали все эти интеграции и шаблоны.
В пункте Azure RM Subscription выбираем наше подключение к Сервису, которое мы настроили на шаге 2. Далее должна появиться доступная нам лабораторная среда.
Затем мы выбираем сгенерированный нами json и определяем некоторые необходимые переменные.
Логин и пароль к машине можно задать как напрямую, так и с помощью переменных, но я совсем не уверен, что это работает, что бы я там не писал, я не смог зайти на машину по этим учетным данным, главное заключается в том, чтобы задать имя машины так, чтобы оно всегда было по возможности уникальным.
Для этого я использую переменную среды сборки.
Далее мы установили еще один важный момент. После того как машина взлетит, нам нужно как-то узнать ее параметры, а лучше не нам, а конвейеру.
Для этого делаем скрипт, например GetLabVMParams.ps1 и помещаем его туда, в проект. Текст скрипта я взял с сайта Microsoft, но немного подкорректировал под свою среду, потому что.
он брал машины PublicIP и FQDN. У меня нет ни того, ни другого, но есть PrivateIP, который не так-то просто получить, поэтому и добавил кусочек.
Из всего, что читает скрипт, нам нужна только переменная labVMIpAddress. Ну это для меня, может быть вам нужно что-то еще, поэтому я ничего не удалял, а просто закомментировал ненужное.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
Я также объясню последнюю строку сценария; это позволяет нашей сборочной машине получить доступ к любому хосту через WinRM. Следующий шаг — запуск нашего замечательного скрипта.
Ему понадобится то самое подключение к облаку, входная переменная с идентификатором машины, который к тому времени уже будет известен из предыдущего шага.
Как? Здесь нужно упомянуть такую замечательную вещь, как Выходные переменные.
Каждый шаг может иметь список переменных, которые передаются на следующие шаги конвейера.
Соответственно, для нашего суперскрипта этой переменной будет labVMIpAddress, не забудьте это указать.
Далее я делаю достаточно простые вещи, которые к тому же могут меняться от случая к случаю.
Я выполняю удаленный сценарий и создаю общий ресурс, в который затем загружаю свои сценарии.
New-Item “C:\test" –type directory
New-SMBShare –Name “test” –Path “C:\test” –FullAccess everyone
Из названия задач понятно, что далее мы копируем на машину какой-нибудь образец скрипта и выполняем его еще на один шаг.
Наша переменная $(labVMIpAddress) пригодится нам в качестве адреса удаленной машины.
Далее мы используем задачу «забрать артефакт из шаров» и копируем результаты выполнения скрипта в нашу среду сборки, затем той же стандартной задачей сохраняем эти файлы в артефакт сборки.
После того, как машина нам больше не нужна, последний шаг — убить ее.
Основная сложность, как видно из длины статьи, состоит в том, чтобы интегрироваться с облаком и установить контакт с созданной вами виртуальной машиной, тогда вы сможете развлекаться столько, сколько вам нужно.
Это моя первая статья, так что не судите строго, комментарии приветствуются.
Теги: #Microsoft Azure #DevOps #руководство #azure devops #автоматизация конвейера #автоматическое тестирование
-
Компьютерное Программирование
19 Oct, 24 -
Выбор Технологии Разработки Браузерных Игр
19 Oct, 24 -
Облачный Хостинг Pci Dss: Подробности Услуги
19 Oct, 24
