С помощью VSTS можно автоматизировать развертывание и тестирование программного обеспечения в различных средах. Суть Continuous Integration заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В частности CI позволяет автоматизировать регрессионное тестирование приложений.

В качестве ознакомления с возможностями VSTS предлагаю опубликовать и настроить Continuous Integration c Unit тестами простого UWP приложения.

Создадим простой проект UWP приложения, в котором у нас будет один метод:

        public double CalcSquere(string t)
        {
            double res = Convert.ToDouble(t);
            res = res * res;
            return res;
        }

В решение добавим проект с unit тестами (Unit Test App). Рекомендуется именовать тестовый проект по конвенции, добавляя в конец Tests. Таким образом проще будет сконфигурировать запуск тестов в VSTS и TFS. Добавим ссылку на основной проект:



Переименуем UnitTest.cs в MainPageTests.cs. Если файл будет так назван, то станет проще понять, что именно тестирует этот класс.

Добавим метод:

  [TestMethod]
        public void CalcSquere_5_Result25()
        {
            Windows.ApplicationModel.Core.CoreApplication.MainView.CoreWindow.Dispatcher.RunAsync(CoreDispatcherPriority.Normal,
            () =>
         {
             SimpleApp.MainPage mp = new SimpleApp.MainPage();
             double expected = mp.CalcSquere("5");
             Assert.AreEqual(expected, 25, "Wrong");
         }).AsTask().Wait();

        }

Код метода запускается из UI потока. Не забываем добавить пространство имен

using Windows.UI.Core;

Если при создании проекта мы не добавляли систему контроля версий, то необходимо это сделать сейчас.



Необходимо удалить сертификаты обоих проектов из списка gitignore (иначе сборка VSTS будет неудачной).

Публикуем на VSTS. Переходим в окошко Team Explorer и нажимаем Sync

После публикации мы можем создать Build Definition. Но перед этим нам необходимо сконфигурировать build агента. Дело в том, что для того, чтобы запустить Unit тесты необходимо, чтобы был создан кастомный агент.

По умолчанию существует 3 пула агентов:
Default pool используется для агентов, которые установлены на удаленных серверах.
Hosted pool используется для агентов, которые по умолчанию установлены на серверах VSTS и TFS
Hosted Linux pool позволяет работать с Linux машинами без какой-либо настройки своего агента. Работает в Ubuntu Linux host внутри докер контейнера vsts-agent-docker.

Далее в таблице отображены возможные сценарии, которые указывают на то, что нам необходим кастомный агент:

Сценарий	Custom Agent	Hosted Build Agent
Основные возможности UWP сборок (включая .NET native)	X	X
Создание пакетов для Sideloading	X	X
Создание пакетов для Windows Store	X	X
Использование сторонних сертификатов	X
Построение для особой версии Windows SDK	X
Запуск unit тестов	X
Использование инкрементного построения	X

Для создания своего агента сборки необходимо создать персональный токен. Нажать на иконку профиля и зайти в Security.



Нажимаем Add. Выбираем только Agent pools (read, manage)



Нажимаем Create token (внизу) и копируем значение, сохраняя его на своем компьютере



Сообщение нас предупреждает, что если мы не сохраним значение токена сейчас, то потом мы его никак получить не сможем. Переходим к агентам



Именно в этом окне появится наш агент после того, как мы его создадим, но сейчас пока что в нем пусто.

Нажимаем Download agent.



Вы скачаете архив vsts-agent-win7-x64-2.110.0.zip. Распакуйте его в папку C:\agent (имя и расположение не обязательно должны быть именно такими)

Не обязательно устанавливать агента на ту же самую машину, на которой вы ведете разработку. Его можно установить на любую машину. Теоретически его можно установить и на виртуалку Azure. Обязательное условие — у вас должна быть установлена 64-ех разрядная версия Windows. Для большинства сценариев требуется чтобы на машине была установлена еще и Visual Studio вместе с NuGet.

Запускаем PowerShell и переходим в директорию C:\agent. Конфигурируем. Выполняем командный файл .\config.cmd и отвечаем на запросы. Вводим URL сервера и выбираем тип аутентификации. Для VSTS единственный доступный вариант это PAT (Personal Access Token). Это именно тот самый токен, который мы создали чуть ранее. Далее идет выбор пула и имени агента. Эти значения в моем случае были оставлены по умолчанию.



Последним шагом конфигурации является вопрос о том нужно ли запустить агента как сервис. В случае необходимости тестирования агент запускается вручную, т.е. в качестве сервиса него устанавливать не нужно.

Ремарка: Удалить агента можно с помощью .\config remove При этом необходимо будет ввести токен PAT.

Подробнее о конфигурировании здесь: Deploy an agent on Windows

Теперь давайте создадим Build



Выбираем шаблон именно для универсальной платформы



И настраиваем Continous integration (ставим галочку напротив). Пулом агента выбираем Default



В результате получим такое окно:



Шаг публикации артефактов (Publish Artifact: drop) можно пропустить или даже удалить для экономии времени если вы не собираетесь делать копию файлов, полученных в результате построения приложения (эту копию можно, например, передать клиенту, отправить в релиз или протестировать вручную).

Для ускорения билда (если необходимо только удостовериться в том, что тесты проходят) на шаге Build solution можно указать одну платформу – x64. Это рекомендуется делать для CI.
В таком случае меняем строку MSBuild Arguments в настройках билда. Значением AppxBundle устанавливаем Never:

/p:AppxBundlePlatforms="$(BuildPlatform)" /p:AppxPackageDir="$(Build.ArtifactStagingDirectory)\AppxPackages\\" /p:AppxBundle=Never /p:UapAppxPackageBuildMode=StoreUpload

В этой строке $(Build.ArtifactStagingDirectory) – это переменная, которая обозначает путь к папке с артефактами. Если на моей машине агент установлен на диске C в папке agent и если при его конфигурировании я выбрал рабочей папкой директорию с названием _work, то путь к этой папке такой:

C:\agent\_work\1\a
Здесь 1 – это порядковый номер проекта

Список всех переменных можно найти на следующей странице: Use build variables

Основные настройки:



Если же вы хотите сгенерировать bundle (файл, содержащий пакеты приложения для различных архитектур процессора), то необходимо совершить изменения в настройках проекта. А точнее открыть файлы проектов .csproj и совершить следующие изменения.
В файле проекта юнит теста в конец первого элемента

<PropertyGroup>

добавить:

<AppxBundle>Never</AppxBundle>

А в файл проекта приложения добавить:

<AppxBundle>Always</AppxBundle>

После этих изменений из строки MSBuild Arguments параметр AppxBundle можно смело удалить вместе с его значением (или поставить значением Auto — /p:AppxBundle=Auto)
Этот вариант подходит для CD.

Так как есть желание тестировать (а в нашем случае оно есть), то необходимо добавить шаг



В окне выбора задачи добавить Visual Studio Test. Указать путь к Test Assembly
В моем случае это:

$(Build.ArtifactStagingDirectory)\AppxPackages\SimpleAppTests_1.0.0.0_x64_Test\SimpleAppTests_1.0.0.0_x64.appx

Другие возможные настройки теста описаны по следующей ссылке: Visual Studio Test

Для unit тестов необходимо чтобы агент был запущен в интерактивном режиме (т.е. с помощью скрипта .\run.cmd).

Кроме того, необходимо чтобы сертификаты приложений (и основного приложения и приложения unit теста) были установлены в хранилище Local Machine — Trusted People (установка возможна простым двойным кликом на *.pfx файл). Устанавливать сертификаты необходимо на той же машине, на которой установлен агент.

Иной раз, при запуске тестов может возникнуть ошибка:

… (0x5B4) Operation timed out. Unable to install Windows app package in 30 sec..

В таком случае можно искусственно увеличить отведенной на запуск время. Делается это с помощью создания файла .runsettings. Минимальное содержимое файла в таком случае может быть таким:

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <!-- Configurations that affect the Test Framework -->
  <RunConfiguration>
    <!-- [x86] | x64  
      - You can also change it from menu Test, Test Settings, Default Processor Architecture -->
    <TargetPlatform>x64</TargetPlatform>
  </RunConfiguration>
  <!-- Adapter Specific sections -->
  <!-- MSTest adapter -->
  <MSStoreTest>
    <AppxInstallTimeout>240000</AppxInstallTimeout>
  </MSStoreTest> 
</RunSettings>

Здесь мы выбираем пакет для какой архитектуры мы будем тестировать и устанавливаем ограничение по времени на установку приложения равным 240 секундам.

Файл создается, как правило, в корневой директории приложения и указывается в настройках билда VSTS:



Результат успешного построения и выполнения теста отображен далее:



Окно подробной информации о тесте:



Из этого окна можно создать новый баг или ассоциацию теста с задачей разработки.

Цена вопроса: большинство функций для небольших команд разработчиков бесплатны (и даже нет необходимости привязывать кредитную карту к аккаунту). Безлимит на приватные репозитории, создание задач. Кроме того предоставляется частный конвейер (concurrent pipeline), который позволяет запускать одновременно один билд и один релиз. Запустить несколько билдов одновременно можно, но они будут выполнены последовательно один за другим. Кроме того вы можете использовать hosted agent в течении 240 минут в месяц бесплатно (каждый билд или релиз не должен продолжаться дольше чем 30 минут).
Цены для больших команд разработчиков смотрите здесь: Цены за использование Visual Studio Team Services.

Официальный мануал: Настройка автоматических сборок для приложения UWP