Комментарии 4
Как вы двигаете задачку с релизом по статусам? Поллингом опрашиваете маркеты?
Ваша релизная команда всецело занимается только скриптами для деплоя или просто выделяется время у разработчиков фичей по необходимости?
Как вы двигаете задачку с релизом по статусам? Поллингом опрашиваете маркеты?
Сейчас релизные задачи двигаем вручную. Автоматическое изменение статусов в планах.
Ваша релизная команда всецело занимается только скриптами для деплоя или просто выделяется время у разработчиков фичей по необходимости?
Наша команда всецело занимается мобильными релизами и всем что с ним связано, в том числе улучшением и поддержкой CI/CD, UI-тестов.
Идеальных решений не бывает, и в статье хотелось бы услышать и про минусы частых релизов. Озвучу те, что вижу сам:
Release notes, как правило, не будут обновлять каждую неделю и переводить на десятки языков. Это требует усилий как редакторов/маркетологов, так и переводчиков. В итоге release notes превращаются во всеми ненавистные "bug fixes and performance improvements". Проверил - у inDriver в английском сторе примерно так и есть)
Частые релизы подталкивают разработчиков к атомарным мелким PRам и фича-флагам для включения фич. В итоге при ревью контекст кода всей задачи в голове имеет только тот, кто ее реализует, а полного ревью от начала до конца одними и теми же людьми не проводится (как минимум это не энфорсится). В результате в главную ветку может попасть что угодно, если разделить это на достаточно малые части). А обилие фича-флагов мешает пониманию, что в какой сборке приложения есть и в каком качестве - в итоге release notes даже если и будут, то будут бесполезны (фичи могут быть под a/b тестами, выключены/включены у части аудитории, перманентно выключены, но быть в коде и т.п.).
Следствие предыдущего - рост бинарника. Когда PR мелкие и ничего не меняют в боевом приложении (из-за фиче-флагов) их психологически легко принять, и код начинает резко расти. У Убера был кейс, когда приложение росло мегабайтами в неделю. Так же из-за этого сложно вычистить что-то из приложения - сложно понять, не используется ли это, не дописано ли ещё, или уже выпилено выключенным фиче-флагом.
Быстрые релизы не позволяют вносить фундаментальные ломающие изменения в процесс сборки без остановки релиз-поезда хотя бы на время. Когда до релиза три недели, можно сломать весь CI/CD и делать с ним что угодно пару недель. С еженедельными релизами сломать его так не получится. Далеко не всегда можно держать две системы параллельно, и недельные релизы проигрывают при важных изменениях (смена сервиса для переводов, смена провайдера удаленных машин, смена самой платформы, например, на self-hosted или обратно)
Спасибо, что поделились и подробно описали минусы. Некоторые из них мы попробовали решить так:
Для release notes у нас такая схема: 1 или 2 раза в месяц мы пишем подробный release notes. Для этого заранее собираем информацию по продуктовым изменениям и проверяем, чтобы не было такого, что это фича находилась на этапе раскатки. В остальные релизы используем стандартные тексты, их у нас несколько штук.
Чтобы следить за ростом бинарника мы настроили сбор метрики размера приложения. В случае сильного скачка размера это сразу отображается на графике, и потом берется на изучение причины.
Один из минусов — сильная нагрузка на тестирование, чтобы поддерживать такие темпы. Если проект достаточно большой, то тут без автоматизации будет сложно.
Есть еще проблема влияния внешних факторов, независящих от нас:
Долгое ревью в сторе. Недавно в Google Play наше приложение проходило проверку примерно в 1,5 недели.
Режекты при ревью.
Незапланированные изменения, которые надо обязательно отправить.
Такие случаи не так часто происходят, но иногда бывают. Это создает «пробку» в релизах: отодвигаются даты следующих релизов, некоторые даже могут схлопываться. В это время в проекте могут жить несколько релизных веток, и тут тоже могут возникнуть проблемы.
Как мы перешли на регулярные релизы мобильного приложения