Настройка TeamCity и получение готовых билдов из Unity проекта.

Настройка TeamCity и получение готовых билдов из Unity проекта.

Задачка дня : имеем более чем 2-3 разработчика, проект игры на Unity и необходимость получать автоматически "установочные файлы" приложения под разные платформы. "Можно подключить к компьютеру устройство запустить эмулятор и не нужен мне ваш TeamCity" - но так же в команде есть тестировщик, который не должен запариваться со всеми IDE и прочими вещами,а лишь получать и проверять, проверять, проверять, и именно поэтому необходимо настроить процесс получения готовых билдов под разные платформы автоматически. Итоговая формула входных данных : Unity игра + VCS(gitmercurial) + 2 + разработчика + 1 + тестировщик + дополнительные менеджеры заказчик. Решения данной задачи берет на себя такой подход как CI (Continuous Integration - ннепрерывная интеграция) - подход позволяет обеспечить автоматическое выполнение задач проекта(тестирование, получение сборки, отправка уведомлений, отправка готового файла сборки в хранилище и тд.), а инструмент для выполнения - TeamCity (TC далее). Причины выбора и анализ аналогов не привожу, так как это тема отдельной статьи. На официальном сайте создателей инструмента  JetBrains можно увидеть достаточно много обширной информации по TC, а так же получить пробник на 60 дней. Описание установки и настройки TC так же не привожу, потому, как пути решения вопросов и проблем возникающих при установке уже лежат там где и должны.

Общая схема иерархии и взаимодействия компонентов в системе такова:

Схема взаимодействия компонентов системы TeamCity

Project - проект который и является базой. Build configuration - логическая единица настроекшагов, которые обеспечивают группировку по критериям (платформаразные источники исходного кода). Build step - шаг автоматического исполнения, в котором указываются инструкции для выполнения. Build trigger - триггер, который будет срабатывать при заданных условиях.

Исходя из данной схемы, для начала необходимо создать проект, настроить build configuration,  подключить VCS (Version Control System - система управления версиями) и составить  build steps. Проект создали, указали все нужные поля, создание конфигурации не содержит никаких сложностей, так как это чисто логическая единица:

Создание новой конфигурации для проекта

К конфигурации необходимо подключить источник VCS, где все исходники проекта содержатся:

Подключение VCS источника к конфигурации

Type of VCS - в нашем примере Mercurial. VCS root name, VCS root ID - уникальное имя для идентификации VCS источника. Pull changes from - источник исходного кода. Default branch - какую ветку в системе контроля версий использовать. Имя пользователя и пароль - те, что используете в системе VCS. После создания конфигурации и подключения источника VCS необходимо создать build steps, которые будут выполнять всю рутину автоматических задач:

Создание нового build step’а

Runner type  - список плагинов, которые доступны в TC и которые можно использовать. Предоставлено очень много вариаций под самые разные задачи, если ваша задача не решается, то можно написать собственный плагин, используя Java платформу. Таким образом, на высоком уровне проявляется новая схема взаимодействия компонентов в TC - все задачи выполняют плагины(runners), остается только написать скрипт, который и будет выполнятся. Для различных runner'ов разные настройки, к примеру для MSBuild следующие:

MSBuild runner

Build step'ов мы можем добавлять сколько нам необходимо в рамках нашей задачи, так же можем ограничивать выполнение - если предыдущий step не выполнен, то данный тоже не запускать. Для получения билдов из Unity проекта необходимы следующие setep'ы : построение проекта специфической платформы (для примера Windows Phone 8), получение исполняемого файла, перемещение файла в необходимый каталог сервер. Построение проекта под необходимую платформу из Unity источника:

#if UNITY_EDITOR
using UnityEditor;
using UnityEngine;
using System;
using System.IO;

public static class BuildScript
{
	static void BuildWindowsPhone8()
	{
		var folderName = "Build-WindowsPhone8";
		DeleteFolder (folderName);
		CreateFolder (folderName);
		string error = BuildPipeline.BuildPlayer(GetScenes(), folderName, BuildTarget.WP8Player, BuildOptions.None);
		if (error != null && error.Length > 0)
		{
			throw new Exception("Build failed: " + error);
		}
	}

	static void CreateFolder(string name)
	{
		if (!Directory.Exists(name))
		{
			Directory.CreateDirectory(name);
		}
	}

	static void DeleteFolder(string name)
	{
		if (Directory.Exists(name))
		{
			Directory.Delete(name, true);
		}
	}

	static string[] GetScenes()
	{
		string[] scenes = new string[EditorBuildSettings.scenes.Length];
		for(int i = 0; i < scenes.Length; i++)
		{
			scenes[i] = EditorBuildSettings.scenes[i].path;
		}
		return scenes;
	}
}
#endif

Но данный скрипт необходимо запустить на выполнение, для этого воспользуемся runner'ом MSBuild и создадим для него скрипт, который и будет использовать Unity IDE в консольном режиме и запустит на выполнение msbuild скрипт:

<?xml version="1.0" encoding="utf-8"?>
<Project  xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
  <Target Name="UnityToWindowsPhone8">
    <Message Text="$(MSBuildProjectDirectory)"/>
    <Exec Command='"$(UnityPath)" -batchmode -executeMethod BuildScript.BuildWindowsPhone8 -projectPath "$(MSBuildProjectDirectory)" -quit' IgnoreExitCode="false"/>
  </Target>
  <Target Name="BuildWindowsPhone8">
    <MSBuild Projects="$(MSBuildProjectDirectory)Путь к *.csproj файлу проекта" Targets="ReBuild" Properties="Configuration=Release" />
  </Target>
</Project>

Отмечу, что в данном скрипте используются параметры : $(MSBuildProjectDirectory) - указывает каталог проекта (рабочая папка),  и $(UnityPath) - указывает путь к Unity.exe. -batchmode -executeMethod BuildScript.BuildWindowsPhone8 данные параметры указывают что Unity мы запускаем в "консольном" режиме и выполняем указанный метод в указанном скрипте.

На данном этапе необходимо дополнительно разъяснить архитектурную особенность TC. На высоком уровне сервер(сайтхост) TC хранит все настройки автоматизации по различным проектам, выполнятся все эти настройки и скрипты будут на агентах - локальных машинах. Агент - любой компьютер, который подключается к системе TC и если удовлетворяет критериям (список доступных средств IDE утилит и инструментов), то выполняет всю автоматизацию. Каждый агент имеет свою рабочую папку для проекта, место в которое агент выкачивает обновления исходных кодов из VCS и после уже использует для работы. Таким образом, если агент имеет копию проекта в которой и будут все изменения от TC. К одному проекту можно подключить множество агентов, и если какой-либо будет отключен, то будет использован автоматически следующий по списку. Так же агент может иметь локальные параметры, которые будут доступны в TC, остается в настройках build step использовать только переменную. Так же таким образом можно указать отличительные особенности вашего агента (установлена специальная утилита доступны особенные инструменты). Для изменения параметров агентов необходимо отредактировать файл  *Директория билд агента*confbuildAgent.properties где можно указать, к примеру путь к Unity.exe  env.Unity4=E:\Program\Unity4\Editor\Unity.exe. Использование данной переменной и остальные настройки MSBuild указаны ниже:

Полный пример MSBuild step’а

После настройки всех шагов так же можно добавить триггер, который будет запускать процесс автоматизации или иные действия выполнять в зависимости от необходимых условий:

Добавление нового триггера

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

d2funlife | Даниил Павлов 2015-2020
Powered by ASP.NET Core 2.2, Entity Framework Core 2.2. Web + UI