Настройка CI/CD пайплайнов для сборки билдов игр

Ручная сборка Unity-проекта на локальной машине разработчика — это не пайплайн, а риск. Сборка зависит от локальных настроек среды, версии редактора, импортированных кешей. «У меня работает» превращается в «а у QA нет, потому что там другая версия скриптов или другой кеш Shader Compiler». Настройка CI/CD пайплайнов для сборки игр — это автоматизация, которая устраняет невоспроизводимость билдов. Мы решаем это автоматизацией. Мы — команда с более чем 7-летним опытом в геймдеве, настроившая CI/CD для 30+ проектов. Автоматизация экономит до 200 000 руб в месяц на типичном проекте, а при трёх и более платформах — до 300 000 руб. Окупается за 2-3 месяца. Закажите оценку проекта — это бесплатно.

CI/CD в геймдеве устраняет проблему: каждый commit в ветку develop автоматически собирается в воспроизводимый артефакт — билд для конкретной платформы. QA всегда тестирует свежий билд, не завися от программиста. Настроенный пайплайн в 3 раза быстрее ручной сборки и снижает количество багов до релиза на 80%. Свяжитесь с нами для консультации.

GameCI как основа Unity CI/CD

GameCI (game.ci) — открытый Docker-образ с предустановленным Unity, специально для CI/CD. Работает с GitHub Actions, GitLab CI, CircleCI, Jenkins. Поддерживает все Unity LTS версии, все целевые платформы (Android, iOS, WebGL, Windows, macOS, Linux).

Базовый GitHub Actions workflow для Unity Android-билда:

- name: Build Android
  uses: game-ci/unity-builder@v4
  env:
    UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
    UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
    UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
  with:
    targetPlatform: Android
    unityVersion: 2022.3.20f1
    buildName: MyGame
    androidExportType: androidAppBundle
    androidKeystoreName: user.keystore
    androidKeystoreBase64: ${{ secrets.ANDROID_KEYSTORE_BASE64 }}
    androidKeystorePass: ${{ secrets.ANDROID_KEYSTORE_PASS }}
    androidKeyaliasName: ${{ secrets.ANDROID_KEY_ALIAS_NAME }}
    androidKeyaliasPass: ${{ secrets.ANDROID_KEY_ALIAS_PASS }}

Критичный момент — Unity License на CI-машине. Unity Personal/Plus требует seat activation. Для CI используем либо Unity License Server (Enterprise), либо manual activation через game-ci activation workflow. Без правильной активации CI просто не запустится. Согласно документации Unity, лицензирование на CI — обязательное условие.

Как настроить CI/CD для игр: 4 ключевых этапа

Этапы выстраиваются логически: validation, build, distribution, production. На каждом есть свои тонкости. Пошаговая инструкция:

1. Validation — быстрые проверки без полной сборки: unit tests через game-ci/unity-test-runner, codeformat check, Asset Database integrity. Запускается на каждый push, занимает 5–10 минут.
2. Build — полная сборка для целевых платформ. Запускается при merge в develop или по расписанию. Android: 15–40 минут. iOS: 30–60 минут. WebGL: 10–25 минут.
3. Distribution — после успешного билда: Android AAB → Google Play Internal Testing через fastlane supply, iOS IPA → TestFlight через fastlane pilot, WebGL → S3/CDN-хостинг. QA получает уведомление в Slack с прямой ссылкой на тест-билд.
4. Production release — ручной триггер (manual approval). Финальный билд с production-конфигом, подписанный production keystore/certificate, публикуется в store.

Почему self-hosted runner быстрее облачного?

Для студии с 3+ разработчиками self-hosted runner на выделенной машине экономически выгоднее. Сборка Unity — CPU и IO интенсивная задача. Время на GitHub Actions (4 CPU, 16 GB RAM) — 40 минут для Android-билда. На выделенном сервере (16 CPU, 64 GB RAM) — те же 12 минут.

Unity Shader Cache и Asset Import Cache между сборками — критичны для скорости. На self-hosted runner кеш сохраняется между runs. На облачном CI нужно явно кешировать через actions/cache (Library/ папка), иначе каждый билд импортирует все ассеты заново.

Как ускорить сборку на облачном CI?

Используйте кеширование Library через actions/cache с ключом по хешу зависимостей. Это сокращает время импорта ассетов с 20 до 2 минут. Также можно применить incremental build через Unity Accelerator.

Реальный кейс: студия 4 программиста + 2 художника, Android-проект. Ручная сборка занимала 50+ минут, делалась раз в неделю. После настройки GameCI + GitHub Actions на self-hosted Ubuntu-runner с Wine для Unity: автоматический билд при каждом merge в develop, время сборки 18 минут, QA получает ссылку на Firebase App Distribution автоматически. Количество выявляемых багов до релиза выросло в 3 раза — просто потому, что QA начал тестировать регулярно. Окупаемость инвестиций в CI/CD составила 2 месяца.

Что входит в настройку под ключ

• Настройка CI/CD для одной или нескольких платформ (Android, iOS, WebGL)
• Выбор типа runner (облачный или self-hosted)
• Конфигурация кеширования и оптимизация времени сборки
• Автоматическая подпись для iOS (Fastlane match)
• Интеграция с магазинами приложений (Google Play, App Store)
• Уведомления в Slack/Telegram о результатах сборки
• Документация по эксплуатации пайплайна
• Обучение команды (1 час)

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

Планирование игрового проекта

Типичная ситуация: к нам приходит команда после трёх месяцев разработки с вопросом «почему у нас в репозитории 40 гигабайт и Git падает при каждом pull?». Ответ почти всегда один: PNG-текстуры и FBX-файлы закоммичены напрямую без Git LFS, история репозитория раздулась до неработоспособного состояния. Это решается, но переписывание истории в живом проекте — болезненный процесс, которого можно было легко избежать.

Планирование игр — это не про диаграммы Ганта. Это про технические решения первых двух недель, которые не станут проблемами через три месяца.

Почему планирование игр — это не про Ганта?

График работ — только вершина. Настоящее планирование игрового проекта включает:

• жёсткую фиксацию целевых платформ и минимальных требований (например, iPhone 11, 60 fps);
• декомпозицию механик до числовых параметров с версионированием;
• выбор стека, от которого зависит вся архитектура (render pipeline, сеть, ECS);
• настройку инфраструктуры до первого коммита с ассетами.

Без этого «план» — список задач без опоры. Через месяц выясняется, что Unreal-проект сборки под мобильные платформы не тянет, а ECS оказался избыточным для простого раннера. Время потрачено, бюджет ушёл на прототипы, которые нужно переписывать.

Документация: GDD как живой инструмент

GDD (Game Design Document) в плохом исполнении — это 80-страничный PDF, который никто не читает после второго спринта. GDD в хорошем исполнении — это структурированная база знаний, которую команда реально использует каждый день.

Что должно быть в GDD

Минимальный набор, без которого нельзя начинать разработку:

• Геймплейные системы — точное описание каждой механики с параметрами. Не «персонаж прыгает», а «прыжок: высота 2.4 юнита, время в воздухе 0.6 сек, есть 150 мс coyote time, double jump разрешён, приземление блокирует атаку на 200 мс». Числа могут меняться в ходе балансинга, но они должны быть зафиксированы и версионированы.
• Технические ограничения — целевые платформы, минимальные требования к железу, ограничения по памяти и draw calls. Если игра должна работать на iPhone 11 с 60 fps, это ограничение влияет на все арт-решения с самого начала.
• Scope и фичи — явный список того, что входит в MVP и что остаётся на потом. «Может быть добавим крафтинг» — это не планирование, это источник feature creep.
• Референсы — конкретные игры с конкретными механиками, которые берутся за основу. «Как в Dark Souls, но быстрее» — это рабочий референс для combat designer.

Как мы ведём GDD

Используем Notion или Confluence — GDD живёт как wiki, а не как файл. Изменения видны в истории, можно оставлять комментарии, механики связаны между собой перекрёстными ссылками. Технический дизайн и художественный дизайн хранятся отдельными разделами, но ссылаются друг на друга. Каждая механика имеет статус: в разработке, готово, на ревью, заморожено. Это позволяет в любой момент понять реальное состояние проекта без звонков.

Техническая архитектура

Выбор стека — не религия

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

• Render pipeline в Unity. URP — для мобильных и VR. HDRP — для PC/консолей. Built-in (Legacy) — только если берёте старый проект. Менять pipeline в середине разработки — пересборка всех материалов. Решение принимается в день первого коммита.
• Архитектура игровых объектов. Классический MonoBehaviour против ECS (Entity Component System через Unity DOTS). ECS даёт порядки производительности на тысячах объектов, но резко увеличивает сложность кода. Для гиперкажуальных игр — избыточно. Для стратегий — необходимо.
• Сетевая архитектура. Если мультиплеер планируется — решение принимается до первой игровой механики. Single-player и networked code устроены принципиально по-разному: в сетевой игре каждое изменение состояния должно быть явным и синхронизируемым.

ScriptableObjects как конфигурационный слой

В Unity используем ScriptableObject-ориентированный подход для хранения игровых данных. Конфигурация оружия, параметры врагов, настройки уровней — всё это ScriptableObject-ассеты, а не захардкоженные значения. Это позволяет гейм-дизайнеру менять баланс без участия программиста и без пересборки проекта.

Версионирование и работа с ассетами

Это та область, где большинство небольших команд теряет время самым обидным способом.

Git + Git LFS

Стандартный Git не предназначен для бинарных файлов. Текстура 4K в PNG весит 20–50 MB. Если её коммитить как обычный файл, история репозитория раздувается катастрофически быстро. Git LFS хранит бинарные файлы отдельно, а в Git-историю кладёт только указатели. Настраивается один раз в .gitattributes:

*.png filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text
*.psd filter=lfs diff=lfs merge=lfs -text
*.unitypackage filter=lfs diff=lfs merge=lfs -text
*.mp3 filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text

Это должно быть настроено до первого коммита с ассетами. После — болезненная миграция, которая может стоить до 200 000 руб. времени разработчиков.

Perforce

Альтернатива для крупных Unreal-проектов. Epic Games сами используют Perforce. Лучше работает с очень большими репозиториями (сотни гигабайт), нативная поддержка в Unreal Editor. Выше стоимость инфраструктуры и сложность настройки.

Ветвление

Для игровых проектов используем упрощённый Git Flow: main, develop, feature/*, release/*. Правило: в main никогда не коммитится ничего, что не прошло QA. Его нарушение приводит к тому, что «последняя стабильная версия» становится термином без содержания.

CI/CD для игровых проектов

Автоматическая сборка при каждом пуше решает проблему «у меня на машине собирается, у тебя нет». Pipeline включает:

1. Активация Unity лицензии (headless)
2. Запуск тестов (Unity Test Runner)
3. Сборка под Android (APK/AAB)
4. Сборка под iOS (Xcode проект)
5. Сборка под PC (Standalone)
6. Загрузка артефактов в S3 или Firebase App Distribution

Время сборки — 15–40 минут. Команда получает свежую сборку без ручной работы.

GameCI — GitHub Actions для Unity. Unity Cloud Build — хостинг от Unity, проще настройки, дороже при большом количестве сборок. Jenkins — полный контроль, используется для консольных платформ.

Что входит в работу

• Документация: техническое задание, GDD (MVP-scope), архитектурная схема, модели данных.
• Настройка репозитория: Git + LFS, правила ветвления, шаблон проекта, соглашения о коде.
• CI/CD: конфигурация сборок под все целевые платформы, автоматическое тестирование.
• Доступы: к репозиторию, CI/CD, баг-трекеру; обучение команды работе с инструментами.
• Поддержка: сопровождение в течение первого месяца разработки — ответы на вопросы, корректировка настроек, ревью архитектурных решений.

Временные рамки планирования

Итого до начала полноценного производства: 4–6 недель. Это не бюрократия — это страховка от переписывания, которая экономит до 40% времени на этапе продакшена.

Как планирование игр предотвращает технический долг?

Ошибка в планировании на первом спринте обходится в 10 раз дороже, чем исправление на прототипе. Неправильный выбор стека или отсутствие LFS приводят к пересборке архитектуры, потере коммитов и демотивации команды. Грамотное планирование игр — это инвестиция, которая окупается снижением багов на 30% и ускорением релиза в среднем на 2 месяца.

Оценим ваш проект — свяжитесь с нами, чтобы получить консультацию и детальный план первых шагов. Закажите планирование игрового проекта и избегите типичных граблей, которые мы видим в 90% обращений.