Статьи

Запуск модульных тестов при развертывании ASP.NET на веб-сайтах Windows Azure

Одной из самых популярных функций веб-сайтов Windows Azure является тот факт, что вы можете просто перенести исходный код нашего приложения ASP.NET на платформу с помощью Git (или TFS или DropBox), а источники скомпилированы и развернуты на вашем веб-сайте Windows Azure. Сайт. Если вы проверяли портал управления ранее, вы, возможно, заметили, что выполняется ряд шагов развертывания: процесс развертывания ищет файл проекта для компиляции, компилирует его, копирует артефакты сборки в корневой веб-каталог и запускает ли ваш веб-сайт. , Но знаете ли вы, что вы можете настроить этот процесс?

Настройка процесса сборки

Чтобы понять, как настроить процесс сборки, я хочу объяснить вам, как это работает. В корне вашего репозитория вы можете добавить файл .deployment , содержащий простую директиву: какую команду следует запускать при развертывании.

 [config] 
 command = build.bat

Эта команда может быть командным файлом, файлом PHP, файлом bash и так далее. Пока мы можем сообщать Windows Azure Web Sites, что выполнять. Пойдем с командным файлом.

 @echo off 
 echo This is a custom deployment script, yay!

Передав это на веб-сайты Windows Azure, вы увидите следующее:

Пользовательская сборка веб-сайтов Windows Azure

В этом пакетном файле мы можем использовать некоторые переменные среды для дальнейшей настройки скрипта:

  • DEPLOYMENT_SOURCE — начальный «рабочий каталог»
  • DEPLOYMENT_TARGET — путь wwwroot (место назначения развертывания)
  • DEPLOYMENT_TEMP — путь к временному каталогу (удаляется после развертывания)
  • MSBUILD_PATH — путь к msbuild

После компиляции вы можете просто скопировать наше приложение в переменную% DEPLOYMENT_TARGET% и запустить свой веб-сайт.

Генерация сценариев развертывания

Создание сценариев развертывания может быть утомительной работой, хорошо, что есть инструменты azure-cli ! После того, как они установлены, просто вызовите следующую команду и получите как файл .deployment, так и сгенерированный пакетный или bash-файл:

azure site deploymentscript --aspWAP "path\to\project.csproj"

Для справки вот что генерируется:

 @echo off 
 
 :: ---------------------- 
 :: KUDU Deployment Script 
 :: ---------------------- 
 
 :: Prerequisites 
 :: ------------- 
 :: Verify node.js installed 
 where node 2>nul >nul 
 IF %ERRORLEVEL% NEQ 0 ( 
 echo Missing node.js executable, please install node.js, if already installed make sure it can be reached from current environment. 
 goto error) 

 :: Setup 
 :: ----- 
 setlocal enabledelayedexpansion 
 SET ARTIFACTS=%~dp0%artifacts 

 IF NOT DEFINED DEPLOYMENT_SOURCE ( 
 SET DEPLOYMENT_SOURCE=%~dp0%.  
 )  
  
 IF NOT DEFINED DEPLOYMENT_TARGET ( 
 SET DEPLOYMENT_TARGET=%ARTIFACTS%\wwwroot 
 ) 

 IF NOT DEFINED NEXT_MANIFEST_PATH ( 
 SET NEXT_MANIFEST_PATH=%ARTIFACTS%\manifest 

 IF NOT DEFINED PREVIOUS_MANIFEST_PATH ( 
 SET PREVIOUS_MANIFEST_PATH=%ARTIFACTS%\manifest 
 ) 
 ) 

 IF NOT DEFINED KUDU_SYNC_COMMAND ( 
 :: Install kudu sync 
 echo Installing Kudu Sync 
 call npm install kudusync -g --silent 
 IF !ERRORLEVEL! NEQ 0 goto error 
 :: Locally just running "kuduSync" would also work 
 SET KUDU_SYNC_COMMAND=node "%appdata%\npm\node_modules\kuduSync\bin\kuduSync" 
 ) 
 IF NOT DEFINED DEPLOYMENT_TEMP ( 
 SET DEPLOYMENT_TEMP=%temp%\___deployTemp%random% 
 SET CLEAN_LOCAL_DEPLOYMENT_TEMP=true 52 ) 
 IF DEFINED CLEAN_LOCAL_DEPLOYMENT_TEMP ( 
 IF EXIST "%DEPLOYMENT_TEMP%" rd /s /q "%DEPLOYMENT_TEMP%" 
 mkdir "%DEPLOYMENT_TEMP%" 
 ) 

 IF NOT DEFINED MSBUILD_PATH ( 
 SET MSBUILD_PATH=%WINDIR%\Microsoft.NET\Framework\v4.0.30319\msbuild.exe 
 ) 
 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 

 :: Deployment 
 :: ---------- 

 echo Handling .NET Web Application deployment. 

 :: 1. Build to the temporary path 
 %MSBUILD_PATH% "%DEPLOYMENT_SOURCE%\path.csproj" /nologo /verbosity:m /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="%DEPLOYMENT_TEMP%";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release 
 IF !ERRORLEVEL! NEQ 0 goto error 

 :: 2. KuduSync 
 echo Kudu Sync from "%DEPLOYMENT_TEMP%" to "%DEPLOYMENT_TARGET%" 
 call %KUDU_SYNC_COMMAND% -q -f "%DEPLOYMENT_TEMP%" -t "%DEPLOYMENT_TARGET%" -n "%NEXT_MANIFEST_PATH%" -p "%PREVIOUS_MANIFEST_PATH%" -i ".git;.deployment;deploy.cmd" 2>nul 
 IF !ERRORLEVEL! NEQ 0 goto error 

 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 

 goto end 

 :error 
 echo An error has occured during web site deployment. 
 exit /b 1 

 :end 
 echo Finished successfully. 
 

Этот скрипт делает пару вещей:

  • Убедитесь, что node.js установлен на веб-сайтах Windows Azure (потребуется позже для синхронизации файлов)
  • Настройка набора переменных среды
  • Запустите msbuild для указанного нами файла проекта
  • Используйте kudusync (инструмент на основе node.js, следовательно, node.js) для синхронизации измененных файлов с wwwroot нашего сайта

Попробуйте: после отправки этого на веб-сайты Windows Azure вы увидите, что используется пользовательский сценарий. Пока не так много добавленной стоимости, но это то, что вы должны предоставить.

Модульное тестирование перед развертыванием

Модульные тесты были бы хороши! Все, что вам нужно, это пара юнит-тестов и тестовый бегун. Вы можете добавить его в свой репозиторий и сохранить его там или просто загрузить во время развертывания. В моем примере я использую тестер Gallio, потому что он запускает почти все тестовые фреймворки, но не стесняйтесь использовать тестер для NUnit или xUnit.

Где-то перед строкой, которая вызывает msbuild и в идеале в области «setup» сценария развертывания, добавьте следующее:

IF NOT DEFINED GALLIO_COMMAND ( 
IF NOT EXIST "%appdata%\Gallio\bin\Gallio.Echo.exe" ( 
:: Downloading unzip 
echo Downloading unzip 
curl -O http://stahlforce.com/dev/unzip.exe 
IF !ERRORLEVEL! NEQ 0 goto error 

:: Downloading Gallio 
echo Downloading Gallio 
curl -O http://mb-unit.googlecode.com/files/GallioBundle-3.4.14.0.zip 
IF !ERRORLEVEL! NEQ 0 goto error 

:: Extracting Gallio 
echo Extracting Gallio 
unzip -q -n GallioBundle-3.4.14.0.zip -d %appdata%\Gallio 
IF !ERRORLEVEL! NEQ 0 goto error 
) 

:: Set Gallio runner path 
SET GALLIO_COMMAND=%appdata%\Gallio\bin\Gallio.Echo.exe 
)

Видишь, что там происходит? Мы проверяем, есть ли в локальной системе, в которой ваши файлы хранятся на веб-сайтах WindowsAzure, копия программы запуска Gallio.Echo.exe . Если нет, давайте загрузим инструмент, который позволяет нам разархивировать. Затем, весь бегунок теста Gallio загружается и извлекается. В качестве последнего шага переменная% GALLIO_COMMAND% заполняется полным путем к исполняемому файлу тестера.

Прямо перед строкой, которая вызывает «kudusync», добавьте следующее:

echo Running unit tests
"%GALLIO_COMMAND%" "%DEPLOYMENT_SOURCE%\SampleApp.Tests\bin\Release\SampleApp.Tests.dll"
IF !ERRORLEVEL! NEQ 0 goto error

Да, название вашей тестовой сборки будет другим, очевидно, вы должны это изменить. Что здесь происходит? Ну, мы вызываем тестового бегуна на наших юнит-тестах. Если это не удается, мы прекращаем развертывание. Переместите его в Windows Azure и убедитесь сами. Вот что отображается в случае успеха:

Модульные тесты веб-сайта Windows Azure

Все зеленые! А при неудаче мы получаем:

Gallio тестовый бегун Windows Azure

На портале четко видно, что развертывание было прервано:

Сбой развертывания при сбое модульных тестов

Вот и все. Наслаждайтесь!