Как выгружался проект в AppStore на прошлом месте работы?

Процесс выгрузки проекта в AppStore

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

Основные этапы процесса

1. Подготовка и сборка
2. Настройка в App Store Connect
3. Верификация и тестирование
4. Самостоятельная публикация

1. Подготовка и сборка

Сборка для публикации всегда выполнялась из чистой среды. Мы использовали Xcode Cloud для CI/CD и, для критичных релизов, дополнительную локальную сборку.

• Версионирование: Номер сборки (CFBundleVersion) увеличивался автоматически через скрипт в Fastlane. Мажорная версия (CFBundleShortVersionString) изменялась вручную по решению тимлида.
• Конфигурация: Для сборки использовалась конфигурация Release с соответствующим provisioning profile и сертификатом дистрибьюшена, которые управлялись через Fastlane Match. Это гарантировало, что у всей команды используются идентичные и актуальные сертификаты.

Пример одного из наших lane в Fastfile для сборки и загрузки в TestFlight:

lane :release_to_testflight do
  increment_build_number # Автоинкремент номера сборки
  build_app(
    scheme: "OurApp",
    export_method: "app-store",
    clean: true
  )
  upload_to_testflight(
    skip_waiting_for_build_processing: false,
    groups: ["qa-team", "beta-testers"]
  )
  slack(message: "✅ Сборка #{lane_context[SharedValues::BUILD_NUMBER]} успешно загружена в TestFlight")
end

2. Настройка в App Store Connect

После загрузки билда в App Store Connect (часто через ту же upload_to_testflight) ответственный разработчик (обычно тимлид или я) заходил в панель и выполнял ручные настройки:

• Создание новой версии: Указывалась маркетинговая версия, подготавливались тексты описания, ключевые слова, скриншоты для всех поддерживаемых размеров устройств (частично генерировались автоматически через frameit).
• Заполнение метаданных: Проверялись ссылки на политику конфиденциальности, контактные данные поддержки, категория приложения.
• Ответы на вопросы регулирования: Обновлялась информация о шифровании (если были изменения), экспортное соответствие.

3. Верификация и тестирование

Перед отправкой на ревью билд обязательно проходил внутреннее тестирование.

• TestFlight: Сборка автоматически распределялась по заранее созданным группам (QA, internal, beta-testers). Мы собирали фидбэк через встроенные заметки TestFlight и внутренний Slack-канал.
• Валидация билда: После обработки билда Apple мы вручную проверяли, не возникло ли предупреждений о несовместимости, не устарела ли битность. Также проверялись логи от App Store Connect API на предмет возможных ошибок на этапе обработки.
• Smoke-тесты: QA-команда проводила быстрые smoke-тесты именно на той сборке, которая была загружена в Connect, чтобы убедиться в отсутствии критичных регрессий.

4. Самостоятельная публикация

После успешного внутреннего тестирования и получения "зелёного света" от продукт-менеджера, ответственный разработчик отправлял приложение на ревью.

• Контрольный список (checklist): Мы использовали общий чек-лист в Confluence, который включал пункты: "Все тексты проверены на орфографию", "Ссылки на политику конфиденциальности рабочие", "Нет заблокированных функций для текущей локали", "Тестовый аккаунт для ревью приложен и актуален".
• Отправка на ревью: Нажималась кнопка "Submit for Review". Мы почти всегда выбирали ручной запуск публикации после одобрения, чтобы контролировать точный тайминг выхода обновления.
• Мониторинг статуса: Статус ревью отслеживался через email-уведомления и в Slack (с помощью интеграции). В случае rejection — логи ревьюера анализировались, проблема оперативно исправлялась, и новая сборка отправлялась с комментарием.
• Релиз: После одобрения Apple в назначенное время (или сразу по команде) приложение публиковалось в магазине. Мы мониторили первые отзывы и метрики крашей (через Xcode Organizer и Firebase Crashlytics) в первые часы после релиза.

Ключевые инструменты и практики, которые делали этот процесс эффективным: Fastlane для автоматизации, Xcode Cloud для стабильных сборок, Match для управления сертификатами, TestFlight для дистрибуции, и строгий код-ревью + мерж-реквесты в основную ветку как триггер для начала подготовки релиза. Это позволяло минимизировать человеческий фактор и выпускать обновления еженедельно или раз в две недели.