Для чего использовал Fastlane?

Применение Fastlane в разработке на Unity

Как Unity-разработчик с более чем 10 лет опыта, я использовал Fastlane в качестве центрального инструмента для автоматизации процессов сборки и публикации игр и приложений, созданных в Unity. Хотя Fastlane изначально создан для нативных мобильных проектов, его гибкость позволяет эффективно интегрировать его в Unity-пайплайны, особенно когда речь идёт о мобильных платформах (iOS и Android). Вот ключевые направления использования:

Основные сценарии использования Fastlane с Unity

• Автоматизация сборки Android (APK/AAB):

    Fastlane использовался для стандартизации процесса сборки. Вместо ручного выбора параметров в Unity Editor или написания длинных скриптов командной строки, я настраивал `Fastfile` для единой команды, которая:
    *   Запускает сборку Unity с нужными параметрами (`-executeMethod`, `-buildTarget`).
    *   Автоматически подписывает APK/AAB файл, извлекая подписи из защищённого хранилища (например, Jenkins Credentials или GitHub Secrets).
    *   Генерирует промо-скриншоты или иконки (с помощью плагинов).
    *   Загружает артефакт сборки на сервер для тестирования или в магазин.

```ruby
# Пример lane для сборки Android AAB из Unity
lane :build_android_release do
  # 1. Запуск сборки Unity
  sh("Unity -quit -batchmode -projectPath /path/to/project -executeMethod BuildScript.PerformAndroidBuild -logFile build.log")

  # 2. Путь к выходному файлу от Unity (условно)
  aab_path = "../Builds/android/release/myGame.aab"

  # 3. Подписание AAB с использованием хранимых ключей
  android_signing = get_android_signing()
  sign(
    aab_path: aab_path,
    signing_key_path: android_signing[:keystore_path],
    alias: android_signing[:alias],
    keypass: android_signing[:keypass],
    storepass: android_signing[:storepass]
  )

  # 4. Загрузка в Firebase App Distribution для тестовой группы
  firebase_app_distribution(
    app: "1:1234567890:android:abc123def456",
    service_credentials_file: "path/to/credentials.json",
    groups: "qa-team, internal"
  )
end
```

• Автоматизация публикации в Google Play Console:

    Это, пожалуй, самый мощный вариант использования. `supply` (действие для Android) позволял:
    *   Автоматически загружать новую сборку (AAB) в выбранный трек (`internal`, `alpha`, `beta`, `production`).
    *   Обновлять метаданные магазина (тексты описаний, скриншоты, иконки) из структурированных папок и файлов.
    *   Поэтапный релиз с управлением процентным распределением.
    *   Полностью автоматизировать процесс Continuous Deployment после успешного прохождения всех тестов.

• Автоматизация сборки и публикации для iOS:

    Для iOS пайплайн сложнее, и Fastlane был незаменим. Я использовал его для:
    *   **Управление профилями и сертификатами (`match`):** Автоматическое создание и синхронизация профилей Provisioning в команде через зашифрованный Git-репозиторий. Это решало проблему "у меня не собирается".
    *   **Сборка Xcode проекта (`gym`):** После экспорта проекта из Unity (вручную или через скрипт), Fastlane брал на себя компиляцию `.xcodeproj` в `.ipa`.
    *   **Публикация в TestFlight (`pilot`):** Автоматическая загрузка билда в TestFlight и управление группами тестировщиков.
    *   **Публикация в App Store (`deliver`):** Загрузка билда на ревью в App Store Connect и обновление метаданных, аналогично Google Play.

• Оркестрация кросс-платформенных сборок:

    Создавал единый `Fastfile` с лейнами, которые последовательно запускали сборку под Android, затем iOS, либо параллельно, если позволяла инфраструктура. Это было основой CI/CD-пайплайна на Jenkins или GitHub Actions.

```ruby
lane :deploy_all do
  # Параллельная сборка (если есть несколько агентов)
  # sh("fastlane android_deploy &")
  # sh("fastlane ios_deploy &")

  # Последовательная сборка
  build_android_release()
  # build_ios_release() # После экспорта проекта из Unity
end
```

• Управление окружением и версиями:

    Использовал действия вроде `increment_build_number` для автоматического увеличения `buildVersion` (для iOS) и `versionCode` (для Android) прямо из Fastlane. Это гарантировало уникальность и последовательность номеров сборок.

Преимущества для проекта на Unity

1. Согласованность: Каждая сборка создавалась идентично, независимо от того, кто её запускал — разработчик на локальной машине или CI-сервер.
2. Скорость и надёжность: Ручные, многошаговые процессы, занимавшие 10-15 минут и подверженные человеческим ошибкам (например, неправильное подписание), сокращались до одной команды fastlane deploy и выполнялись за 2-5 минут без вмешательства.
3. Интеграция с CI/CD: Fastlane идеально встраивался в Jenkins, GitLab CI, GitHub Actions, становясь "исполнительным" ядром пайплайна.
4. Документация процесса: Сам Fastfile служил живой и исполняемой документацией всех шагов по сборке и деплою проекта.

В итоге, Fastlane использовался не для написания игрового кода, а как мощный инфраструктурный инструмент, который переносил рутинные, сложные и критически важные операции сборки и публикации Unity-проектов в область предсказуемой, контролируемой и быстрой автоматизации. Это позволяло команде сосредоточиться на разработке, а не на DevOps-рутине.