Закулисный взгляд на то, как Spotify выпускает приложения: часть 1

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

В Spotify у нашей Release команды двойная задача: (1) следить за выпуском основного приложения Spotify и (2) создавать необходимые инструменты для поддержки этого процесса. Повседневной координацией занимается штатный менеджер по выпуску при поддержке остальных членов команды.

У нас есть логотип, а это значит, что мы занимаемся серьезным делом

Когда дело доходит до выпуска приложения, основные обязанности команды Release сводятся к двум пунктам:

1. Убедиться, что время от момента слияния разработчиком своего кода с основной веткой до момента, когда он станет доступен пользователям, максимально сокращено.
2. Обеспечение соответствия качества нашим стандартам.

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

• Соответствующая расстановка приоритетов — не все ошибки одинаковы. Сбой во время регистрации или воспроизведения требует немедленного внимания, в то время как сбой после выхода из системы может быть менее срочным.
• Определение запасного варианта — если ошибка затрагивает определенную группу A/B-тестов, мы можем временно перевести всех пользователей в рабочий режим с помощью корректировок на бэкенде, а исправление ошибки на стороне клиента будет реализовано в следующем релизе. Таким образом, релиз будет выпущен в срок без ущерба для пользовательского опыта.
• Быстрое реагирование в случае необходимости — даже незначительная ошибка, затрагивающая небольшую, но значительную группу пользователей (например, сбои в определенном регионе), может потребовать оперативного решения.

Релизный цикл

Чтобы проиллюстрировать наш релизный цикл, давайте проследим путь версии 8.9.2 от зарождения до внедрения.

Пятница, 20 сентября: рождение новой версии

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

В Spotify мы практикуем магистральную (trunk-based) разработку, то есть разработчики сливают свой код в основную ветку, как только он будет протестирован и отрецензирован.

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

В Spotify 8.9.2 мы планировали развернуть функцию «Аудиокниги» на некоторых рынках — она была доступна за фиче-флагом в бэкенде в течение нескольких релизов, для внутреннего тестирования с целью выявления ошибок, которые могли бы помешать запланированному развертыванию. Это была важная новая функция для компании, и мы хотели убедиться, что все сделано правильно, тем более что маркетинговые мероприятия и события уже были запланированы.

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

Другие команды могли мерджить код в любой момент, но мы настоятельно рекомендовали им использовать фиче-флаги. Если это было невозможно, мы просили их избегать слияния любых изменений с высоким риском на этой неделе.

Пятница, 20 сентября — четверг, 26 сентября

За исключением дополнительных действий в первый день, каждый день первой недели цикла выпуска в основном выглядит одинаково.

• Рано утром ночные сборки основной ветки рассылаются внутри компании и альфа-пользователям.
• Команды разрабатывают и мерджат новый код. Разработчики и их команды следят за тем, чтобы код был протестирован и проверен заранее.
• Внутренние и внешние альфа-пользователи отправляют сообщения об ошибках. Если владелец затронутой функции неизвестен автору сообщения, менеджер по выпуску следит за тем, чтобы сообщение об ошибке было направлено в нужную команду.
• Количество сбоев и другие показатели отслеживаются для каждой сборки как автоматически, так и вручную. Автоматические баг-тесты создаются, когда сбой или другая проблема превышает заданный порог серьезности; ручные баг-тесты создаются, когда менеджер по выпуску или любой другой сотрудник считает, что что-то заслуживает расследования.

Для отслеживания статуса предстоящего релиза мы используем Release Manager Dashboard, которая собирает всю необходимую информацию о релизе в одном месте:

Ниже приведены примеры данных, содержащихся на дашборде:

• Блокирующие ошибки
• Последняя доступная сборка, прошедшая тесты и распространяемая через альфа-программу в магазине приложений
• Аварии и ANR (App Not Responding) на единицу потребления
• Ежедневное использование
• Статус заданий по распространению, которые распространяют приложение внутри и вне магазина

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

Пятница, 27 сентября: пятница — день ветвления!

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

После создания ветки менеджер по выпуску координирует работу по скорейшему выпуску версии со всеми заинтересованными сторонами.

Чтобы помочь нам собрать дополнительные данные о качестве релизной ветки, у нас есть программа публичных бета-версий, которые берутся из релизной ветки — ожидается, что эти сборки будут более стабильными, чем наши альфа-сборки.

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

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

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

Пятница, 27 сентября — понедельник, 30 сентября: подготовка к отправке

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

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

Менеджер релиза следит за тем, чтобы ошибки были назначены правильной команде и правильно расставлены приоритеты, чтобы ручное тестирование было выполнено и о нем было сообщено, а все ошибки, блокирующие релиз (их обычно бывает от трех до пяти в каждом релизе), были исправлены в ветке релиза.

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

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

Панель Release Manager Dashboard дает четкое представление об этих критериях, используя цветовое кодирование (красный/желтый/зеленый) для быстрой оценки.

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

Вторник, 1 октября — среда, 2 октября: развертывание

После того как приложение одобрено для платформы, мы выводим его на рынок в два этапа: сначала на небольшой процент пользователей, а на следующий день — на 100% пользователей.

Когда релиз будет распространен на 1%, мы ожидаем, что дашборд будет выглядеть следующим образом:

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

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

Если мы обнаруживаем серьезную проблему во время первого этапа развертывания, мы немедленно приостанавливаем развертывание, и ответственная команда приступает к созданию исправления. В идеале исправление будет готово до появления следующих версионных веток, что позволит нам представить обновленную сборку. Однако если исправление не будет готово вовремя, мы можем столкнуться с трудным решением отменить либо текущий, либо предстоящий релиз, чтобы избежать сложностей, связанных с управлением двумя активными ветками одновременно. Как только мы достигаем 100%, мы продолжаем следить за состоянием релиза в течение следующей недели.

Для версии 8.9.2, как только достаточное количество пользователей стали использовать новую версию, команда аудиокниг начала поэтапное развертывание. Это включало в себя постепенное включение функции «Аудиокниги» для небольшого процента пользователей на определенных рынках с помощью флага функции на бэкенде.

К счастью, в версии 8.9.2 функция «Аудиокниги» соответствовала нашим стандартам качества, и в течение последующих дней развертывание было успешно доведено до 100%.

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

Резюме

Еженедельный процесс выпуска мобильного приложения Spotify старается найти баланс между скоростью и качеством. Руководителем процесса является менеджер релизов, который с помощью команды релизов обеспечивает связь и координацию с командами разработчиков и другими заинтересованными сторонами на протяжении всего цикла выпуска. Такие инструменты, как Release Manager Dashboard, играют важную роль, позволяя менеджеру по релизам принимать быстрые и точные решения.

Подробная документация по инструментам и процессам помогает ориентироваться всем участвующим командам.

Такая надежная система позволяет Spotify постоянно обновлять свое приложение, быстро решать проблемы и внедрять новые функции, такие как аудиокниги, при минимальных нарушениях в работе пользователей.

Во второй части, где мы заглянем под капот и посмотрим, как работают системы (и роботы!), обеспечивающие работу панели Release Manager Dashboard.

Источник