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

Почему небольшой time-to-market – это конкурентное преимущество для компании, которая развивает собственные продукты? Тут все просто: чем быстрее вы поставляете обновления пользователям, тем быстрее вы получаете обратную связь, тем быстрее вы можете исправить ошибки, протестировать функции и доработать их. Заказчик со своей стороны лучше управляет продуктом, если быстро получает результаты от команды. Он так же может быстро вносить корректировки, гибко полностью управлять финальным продуктом.

В сложных процессах, которые объединяют аналитиков, дизайнеров, разработчиков, QA-инженеров, оптимизация каждого шага дает весомый вклад в финальный результат. Поэтому, когда мы стали развивать мобильное направление, мы стали искать возможности, чтобы максимально автоматизировать каждый шаг – избавить людей от ручной работы, застраховаться от ошибок.

О том, как выглядел этот путь, к какому результату мы пришли и каких преимуществ добились, рассказываем дальше.

Первый шаг – автоматизация

На старте больше 10 лет назад разработчики собирали версии вручную, тестировщики приходили к ним за сборками, подсоединяли смартфон к компьютеру, загружали себе сборку и так далее. Процесс шел не очень быстро и, главное, упирался в человеческий фактор – тестировщикам приходилось пинговать команду, разработчики отвлекались от задач, чтобы передать им продукт.

Мы начали с того, что внедрили автоматизацию через Jenkins. Команды получили наборы скриптов, чтобы готовить сборки и отправлять их в наш собственный App Store. На этой площадке у каждого проекта автоматически создавалась страница, где публиковалась последняя версия приложения. Отсюда тестировщики забирали себе релиз на проверку.

Это первый шаг, который разделил процессы разработки и тестирование – больше не приходилось физически включать телефон в компьютер. Мы даже сделали генерацию QR-кодов, чтобы не приходилось на экране смартфона вбивать адреса и тыкать пальцами в ссылки – наводишь камеру на экран компьютера, сканируешь код, получаешь себе приложение.

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

Второй шаг – управление версиями

В это время появилось несколько продуктов для управления версиями приложений. Мы изучили рынок и выбрали сервис Beta. Он позволял добавлять группы пользователей (разработчиков, тестировщиков), назначать им разные права, настраивать, кто какие уведомления будет получать. Самое главное – загружать цепочки версий и управлять ими.

Мы определили, какие нам нужны версии, как нужно работать с окружениями. Какие-то моменты выясняли методом проб и ошибок – например, сколько нужно дебаг-версий на каких окружениях, чтобы и не запутаться, и быстро определять источники проблем в приложениях. Начинали с собственных дебаг-версий для каждого окружения, в итоге пришли к одной версии, а между окружениями переключаемся через отдельный экран, если такая необходимость возникает.

Через несколько лет мы перешли на сервис App Distribution, который работает в платформе Firebase. Этим решением и пользуются сейчас наши мобильные команды. В Firebase у приложения, как правило, есть три версии: (1) dev – окружение развернуто у нас, (2) stage – здесь заказчик принимает работу, (3) релизная сборка, которая деплоится автоматически в версию опубликованных приложений.

App Distribution позволяет загрузить сборку, автоматически отправить нотификации ответственным сотрудникам. Ответственные лица – тестировщики, разработчики – могут сразу подключиться к работе, а если у них подключен к нашей инфраструктуре смартфон, то они сразу получат обновление на свое устройство.

Параллельно эволюционировал набор инструментов для автоматизации сборок и публикации. Следующая веха – переход с Jenkins. Какое-то время мы экспериментировали с Gitlab CI/CD, но в итоге на уровне компании приняли решение перейти на Azure DevOps (TFS).

Третий шаг – пайплайны TFS

Теперь у нас в процессах есть набор событий, которые автоматически запускают пайплайн в TFS для выполнения определенных действий. Например, после мерджа в девелоперскую ветку выкачивается исходник, происходит сборка, артефакты отправляются в Firebase, автоматически создается карточка версии.

TFS готовит автоматические сборки с описанием, что было сделано для каждой из них. Как мы уже рассказывали раньше, release notes подтягиваются автоматически из выполненных тасков. Тестировщик сразу видит, какая сборка актуальная, что в ней изменилось, может ее себе скачать и проверить.

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

Итог – быстрые и прозрачные процессы CI/CD

Экономится время тестировщика на получение сборки, он не дергает команду, чтобы ему поставили версию. Все участники процесса в каждый момент времени знают, что им нужно желать – теги TFS автоматически меняют статус сборки, все изменения можно удобно отслеживать. Фактически когда каждый участник закончил свой участок, он может про задачу забыть – автоматизация управляет процессом.

Сейчас у нас выработан подход к построению версий на все возможные окружения. Процессы отлажены и автоматизированы. Следующая большая цель – переход на TBD. Здесь нам еще предстоит разобраться. Например, возникают вопросы, как тестировать код, если он постоянно заливается в мастер, как работать с хотфиксами...

Сейчас мы отрабатываем эти подходы на одном из крупнейших проектов, где TBD строится с самого начала. Через несколько месяцев продукт отправится на прод, и к этому моменту у нас будет цельная картина процессов. Опытом поделимся.