Привет, читатель!

Уже три года я работаю лидом на проекте, который стремительно развивается. Изначально у нас было всего две сборки — для Android и iOS. Однако со временем проект значительно вырос: на его основе были выпущены два приложения, доступные на Android, iOS и WebGL. В результате количество сборок увеличилось до шести!

На этом этапе стало очевидно: пора автоматизировать процессы!

В этой статье я расскажу:

• Что такое CI/CD и почему это важно

• Какие существуют CI/CD сервисы и чем они отличаются

• Как мы улучшили наш CI/CD, какой сервис выбрали и почему

Если вам интересно, как оптимизировать процессы сборки и доставки приложений, устраивайтесь поудобнее — будет полезно!

Об авторе

Меня зовут Борис, я Tech Lead в компании, занимающейся игровым аутсорсингом и аутстаффингом. За почти пять лет я участвовал в проектах как для небольших инди-студий, так и для топ-5 игровых компаний мира, а еще я последние три года руковожу разработкой онлайн-нард.

Также веду блог в Telegram, где делюсь полезными советами для Unity-разработчиков.

Автор этой статьи не является DevOps-специалистом и не претендует на идеальное или универсальное решение. Материал носит обучающий и информационный характер, чтобы помочь Unity-разработчикам ознакомиться с CI/CD и начать его внедрение.

Что такое CI/CD?

CI/CD (Continuous Integration / Continuous Deployment) — это методология автоматизации процессов сборки, тестирования и развертывания приложений. CI (Continuous Integration) позволяет разработчикам автоматически проверять и объединять изменения в коде, предотвращая ошибки на ранних этапах. CD (Continuous Deployment/Delivery) отвечает за автоматическую доставку готовых сборок на продакшен или тестовые среды. Благодаря CI/CD можно сократить время выпуска обновлений, минимизировать человеческий фактор и ускорить разработку

Подробное описание CI/CD — это тема для отдельной статьи, а может, и нескольких. Поэтому углубляться в детали мы не будем, но выделим три ключевых этапа автоматизации CI/CD:

1. Запуск автотестов – проверка кода на ошибки перед сборкой. Это включает юнит-тесты, интеграционные тесты и, при необходимости, UI-тестирование.

2. Билд приложения – автоматическая сборка проекта под нужные платформы (Android, iOS, WebGL и т. д.).

3. Деплой – развертывание готовой сборки в тестовую среду, стор или на продакшен.

Эти три шага позволяют ускорить разработку, минимизировать ошибки и упростить выпуск обновлений

CI/CD — это, в первую очередь, зона ответственности DevOps-специалиста, а не Unity-разработчика. Однако в реальности не каждая компания может позволить себе отдельного DevOps-инженера. В инди-студиях и небольших командах именно Unity-разработчик становится тем, кто может внедрить этот процесс или хотя бы предложить его внедрение с привлечением стороннего специалиста.

Какие системы для настройки CI/CD существуют?

1. Unity Cloud Build

Unity Cloud Build — это облачный сервис от Unity, который позволяет автоматизировать сборку проектов для Android, iOS, WebGL, Windows, macOS и других платформ. Он тесно интегрирован с Unity и избавляет разработчиков от необходимости вручную собирать билд на своём компьютере или сервере

Преимущества Unity Cloud Build

1. Удобный интерфейс - В отличии от всех остальных систем сборок у Unity есть отличный UI интерфейс в котором легко можно настроить любые параметры билда

2. Легкость в настройки пайплайнов - легко добавлять, изменять пайплайны

3. Автоматическая выгрузка – можно отправлять билды тестировщикам или загружать их в сторы или настроить оповещения в рабочий мессенджер

4. Интеграция с ситетами контроля версий - Поддерживает GitHub, GitLab, Bitbucket, Plastic SCM и другие.

Недостатки Unity Cloud Build

1. Нет полного контроля над процессом сборки

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

3. Ограниченный доступ к окружению, что затрудняет интеграцию с внешними сервисами

4. Часто есть проблемы с сервисом: иногда плохо работает web интерфейс, идут профилактические работы или иные технические проблемы

Когда использовать?

• Если вы собираете билды вручную и быстро хотите улучшить ваш пайплайн

• Если вы собираете немного сборок и вам не нужна сильная автоматизация CI/CD

• Если вы часто меняете конфигурацию сборок

• Если вы не хотите тратить время и деньги на изучение настройку более сложных систем

Изменение цен на Unity Cloud Build после перехода на DevOps

Я знаю, что после изменения политики цен на Unity Cloud Build многие разработчики решили сменить свой пайплайн на другой, так как цена казалась сильно завышенной.
Поэтому ниже я приведу стоимость Unity Cloud Build на момент написания данной статьи для наших сборок за янвярь 2025 года

2. Облачные CI/CD сервисы

В отличие от Unity Cloud Build, который предоставляет удобный интерфейс для настройки облачных сборок, эти решения требуют ручной настройки и написания конфигурационных файлов. Это даёт больше гибкости, позволяет покрыть разнообразные сценарии, но требует значительно больше времени на настройку.

Например:

• Настроить пайплайн в Unity Cloud Build можно за 15–30 минут.

• Настроить CI/CD в облачных сервисах займёт от 4 часов если у вас хороший опыт в DevOps.

Тем не менее, облачные CI/CD сервисы позволяют автоматизировать сборку, тестирование и деплой без необходимости настраивать собственные сервера. Они работают в облаке и легко интегрируются с GitHub, GitLab и другими системами контроля версий.

Все эти сервисы базируются на GameCI

GitHub Actions и GitLab CI/CD

Они очень похожи между собой, и стоит использовать тот сервис, на котором лежит ваш исходный код

Преимущества:

• Полностью интегрирован с GitHub и GitLab.

• Простая YAML-конфигурации для описания пайплайнов.

• Есть готовые экшены для работы с Unity (например, game-ci).

• Хорошее комьюнити, довольно популярные решение

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

Недостатки:

• Работает только с Github и Gitlab репозиториями соответственно

Когда использовать?

• Если ваш код уже хранится в GitHub или Gitlab.

• Если Unity cloud build не хватает для ваших задач

• Если ваши билды входят в квоту бесплатных минут, что дает Github actions или Gitlab CI/CD

CircleCI

На момент написания этой стать у Circle CI в связке с GameCI был критический баг, из-за которого нельзя делать сборки на последних версиях Unity. Учитывая, что комьюнити, которое пользует этим решением небольшое, то этот баг никто не фиксит, а значит рассматривать это решение не стоит

Team City

Team City чаще используют как самостоятельную CI/CD систему, которую можно развернуть на своих серверах, однако у Team city есть SaaS сервис, который, на самом деле, тоже попадает в этот раздел, так как является облачным. Подробнее про Team City я расскажу в следующем разделе

3. Самостоятельные CI/CD-системы

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

Jenkins

Открытый, бесплатный и гибкий CI/CD инструмент

Преимущества:

• Полностью бесплатный и с открытым исходным кодом.

• Огромное сообщество и большое количество плагинов (есть плагины для Unity).

• Поддерживает разные платформы и языки программирования.

• Работает на локальных серверах или в облаке.

Недостатки:

• Требует настройки и администрирования.

• UI устаревший и менее удобный

• Требуются мощные ресурсы сервера при больших нагрузках.

Когда использовать?

• Если есть свои локальные машины и на них можно развернуть бесплатно

• Если важно не зависеть от облачных сервисов.

• Если в команде есть DevOps-специалист, готовый поддерживать Jenkins.

TeamCity

Продвинутое CI/CD-решение от JetBrains.

Преимущества:

• Интуитивно понятный UI и гибкая настройка.

• Поддержка параллельных билдов и кэширования.

• Хорошо работает с Docker и Kubernetes. * Гибкая система триггеров для автоматического запуска билдов.

• Работает на локальных серверах или в облаке.

Недостатки:

• Платный для больших команд, но есть бесплатная версия (до 3 билд-агентов). Saas версия стоит 15$

• Меньше плагинов и комьюнити, чем у Jenkins.

Когда использовать?

• Если нужна гибкость и кастомизация, но при этом удобный UI.

• Если команда использует другие продукты JetBrains.

• Если важна простая настройка параллельных билдов

Наше решение

Давайте начнем с проблемы

Мы поддерживаем наш проект на платформах Android и iOS. Для автоматизации процессов используем Cloud Build, где выполняются автотесты и собираются сборки.

Процесс создания релизной версии выглядит так:

1. Разработчик обновляет версию и номер сборки, затем пушит финальную версию в мастер.

2. Разработчик вручную запускает сборку релизных билдов для Android и iOS.

3. Продакт-менеджер загружает билды и отправляет их в Google Play и TestFlight.

4. Продакт уведомляет QA о готовности сборок к тестированию.

5. QA проверяет билды и, если всё в порядке, дает разрешение на релиз.

6. Продакт выпускает приложения в релиз.

Когда у нас было всего два релиза в спринт (раз в две недели), этот процесс казался вполне приемлемым. Да, иногда разработчик забывал обновить версию, а продакт мог быть недоступен и загружал сборку с задержкой, но такие случаи были редкостью. Переход на TeamCity или другую CI/CD-систему с наймом DevOps-инженера казался избыточным и сложным, поэтому процесс оставался ручным — и всех это в целом устраивало.

Но всё изменилось с появлением рескина. Мы создали второе приложение на базе текущего проекта, сохранив общий код. Затем добавили поддержку WebGL, и всего за полгода количество сборок выросло до шести!

В этот момент стало очевидно: мы больше не справляемся. Ручной процесс превратился в узкое место — участились ошибки, возросли задержки. Нам срочно требовалась автоматизация, и я начал изучать различные CI/CD-системы. Результаты этого исследования легли в основу статьи, где мы рассмотрим возможные решения.

1. Переход на GitLab CI/CD

Наш проект хранится в GitLab, поэтому логично было рассмотреть его встроенную CI/CD-систему. Использование GitHub Actions сразу отпало, так как мы работаем с GitLab. А изучив CircleCI, мы обнаружили, что Game CI, который его использует, не поддерживает нашу версию Unity.

Кроме того, полноценный переход на GitLab CI/CD потребовал бы DevOps-инженера, а нанимать его мы не планировали. Несмотря на все плюсы GitLab CI/CD, мы не хотели отказываться от Unity Cloud Build, который оставался для нас удобным инструментом. В итоге этот вариант мы оставили как план B.

2. Переход на TeamCity

TeamCity сразу привлек наше внимание: удобный интерфейс, богатый функционал и мощные возможности настройки. После его изучения мы решили отказаться от GitLab CI/CD и сделать ставку на TeamCity в SaaS (облачной) версии.

Но оставалась серьезная проблема:

• Перенос пайплайна с Unity Cloud Build на TeamCity потребовал бы значительных временных затрат.

• Без DevOps-инженера процесс оказался бы слишком сложным.

3. Unity Cloud Build + TeamCity

TeamCity — отличное решение, но мы не хотели полностью переносить наш пайплайн из Unity Cloud Build. Тогда у нас появилась идея: а что, если оставить сборки в Unity Cloud Build, но автоматизировать деплой через TeamCity?

Я решил протестировать этот подход на WebGL-версии приложения. Потратив 10–20 часов, мне удалось реализовать автоматизированный деплой — и это сработало!

В итоге мы сохранили наш процесс сборки в Unity Cloud Build, а TeamCity настроили исключительно для автоматизации деплоя, с чем Unity Cloud Build не справлялся. Теперь у нас есть гибкая система, готовая к дальнейшим улучшениям и автоматизациям, например:

• Деплой новых версий без ручного вмешательства

• Автоматическое создание задач в таск-трекере

Этот подход позволил нам оптимизировать процесс без радикального изменения инфраструктуры

Давайте сравним 2 процесса. До внедрения Team City и после

До внедрения TeamCity

Деплой dev версии

1. Разработчик пушит изменения в репозиторий

2. Разработчик нажимает на кнопку создания билда и Unity Cloud Build создает билд

3. Разработчик скачивает билд

4. Разработчик разархивирует билд

5. Разработчик пушит в другой репозиторий, где хранится WebGL версия и WebGL версия деплоится на дев окружение

6. Разработчик пишет QA, что вышла новая версия

Релиз

1. Разработчик мерджит dev ветку в main и это запускает деплой на Prod

2. Разработчик пишет QA, что прошел релиз

Как видим разработчику нужно сделать 6 шагов вручную, которые еще размазаны во времени. Много мест, где можно совершить ошибку

Внимательный читатель мог заметить, что при пуше в репозиторий, в котором хранится WebGL версия автоматически триггерится деплой. Этот деплой сделан на Gitlab CI/CD и за него отвечает наш Backend девелопер, который его и настроил. Так что, справедливости ради связка Unity Cloud Build + Team City + Gitlab CI/CD. Но он был сделан еще до того, как мы начали решать проблему комплексно и при желание процес из Gitlab CI/CD можно будет легко перенести на Team City

После внедрения Team City

Деплой Dev версии

1. Разработчик пушит изменения в репозиторий

2. Разработчик нажимает на кнопку создания билда и Unity Cloud Build создает билд

   Разработчик скачивает билд

   Разработчик разархивирует билд

   Разработчик пушит в другой репозиторий, где хранится WebGL версия

3. Разработчик нажимает на кнопку в Team City

   1. Team City скачивает последний билд с нужным именем и делать все нужные шаги для пуша в дев окружение

   2. WebGL версия деплоится на дев окружение

   3. Team City отправляет оповещение в канал, о том, что загружена новая версия

Релиз

1. Разработчик нажимает на кнопку в Team City

   1. Team City делает мердж в main

   2. Team City отправляет оповещение в канал

Как видим, количество действий значительно сократилось. Дополнительно к этому теперь любой член команды, имеющий доступ к TeamCity, может запустить деплой, а не только разработчик. Для этого не требуются знания Git или другие технические навыки. Это особенно удобно, например, для QA-специалиста, который после успешного тестирования может самостоятельно выпустить релиз, не дожидаясь разработчика

Можно ли улучшить этот процесс?

Конечно можно. В идеале мы хотим, что бы процесс деплоя для WebGL выглядел следующим образом:

1. Разработчик пушит в репозиторий с тегом

   1. По тегу Team City запускает Unity Cloud Build сборку

   2. По завершению билда Team City запускает пайплайн деплоя

   3. Team City оповещает команду о том, что деплой завершен

Читатель, спасибо, что дочитал до конца первую часть статьи про CI/CD в Unity!

В следущей части я расскажу подробно в формате туториала, с примерами кода и подробным объяснением о том, как мы автоматизировали наш деплой WebGL версии
А если вам понравилась эта статья, то поддержите меня лайком! Это даст мотивации выпустить статью быстрее и буду рад, если подпишитесь на мой канал в Telegram