Для чего использовал CI/CD?

Мой опыт использования CI/CD в разработке на Unity

Я использовал CI/CD (Continuous Integration / Continuous Delivery) как фундаментальную инфраструктуру для автоматизации всех этапов разработки — от слияния кода до выпуска билдов в прод. Основные цели: обеспечение стабильности, ускорение процессов и минимизация рутины.

Ключевые сценарии применения

1. Автоматическая сборка и тестирование:

• При каждом пуше в ветки develop/main запускался пайплайн, который:

    - Клонировал репозиторий.
    - Восстанавливал зависимости через UPM или Package Manager.
    - Собирал проект для целевых платформ (PC, Android, iOS, WebGL).
    - Запускал **юнит-тесты** (через NUnit) и **интеграционные тесты**.
    - Генерировал отчеты о покрытии кода (используя **Unity Test Framework** с `--testResults` и `--coverageResults`).

    Пример конфигурации для GitHub Actions:

```yaml
name: Unity CI
on: [push]
jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: game-ci/unity-builder@v2
        with:
          targetPlatform: Android
      - uses: game-ci/unity-test-runner@v2
```

2. Управление версиями и артефактами:

• CI/CD автоматически присваивал версию билдам по схеме major.minor.patch-buildNumber (например, 1.2.3-456). Для этого использовались тэги Git или переменные окружения пайплайна.
• Каждый успешный билд загружался в артефакты (например, на Google Drive, S3, или внутренний сервер) с метаданными: версия, хеш коммита, дата сборки.
• Для мобильных платформ (Android/iOS) настраивалась автоматическая подпись и, при необходимости, загрузка в TestFlight или Google Play Console (в закрытые тестовые треки).

3. Интеграция с код-ревью и контроль качества:

• В GitLab/GitHub CI запускались статические анализаторы кода (например, Roslyn Analyzers) и проверки форматирования (через dotnet format).
• После успешного прохождения тестов создавался артефакт — WebGL демо-сборка, которая деплоилась на хостинг (например, GitHub Pages) для быстрого доступа команды дизайнеров/менеджеров.

4. Деплой на тестовые стенды:

• Для мультиплеерных проектов автоматически разворачивались серверные билды на выделенных инстансах (AWS EC2, Kubernetes).
• Для проектов с Addressable Assets пайплайн управлял загрузкой свежих ассет-бандлов на CDN, что позволяло обновлять контент без выпуска новой версии приложения.

Решаемые проблемы и преимущества

Без CI/CD команда сталкивалась с рядом критических проблем:

• "У меня на машине работает!" — из-за различий в окружениях.
• Ручные ошибки — забытая подпись, некорректная версия.
• Долгий процесс выпуска — сборка, тестирование, деплой занимали часы.

Благодаря внедрению CI/CD мы достигли:

• Сокращение времени выпуска с нескольких часов до 15-30 минут.
• Раннее обнаружение багов — тесты запускались на каждом коммите.
• Воспроизводимость — каждый билд собирался в изолированном окружении.
• Освобождение разработчиков от рутины, что позволило сфокусироваться на фичах.

Инструменты и стек

В зависимости от проекта я работал с:

• Облачные CI/CD системы: GitHub Actions, GitLab CI, Jenkins.
• Специализированные решения для Unity: GameCI (unity-builder, unity-test-runner), Bitrise.
• Контейнеризация: Docker для создания унифицированных образов с Unity (на основе официальных образов Unity Hub).
• Мониторинг: интеграция с Sentry для автоматической загрузки символов отладочной информации (debug symbols) из каждого билда.

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