Спасибо, что поделились и подробно описали минусы. Некоторые из них мы попробовали решить так:
Для release notes у нас такая схема: 1 или 2 раза в месяц мы пишем подробный release notes. Для этого заранее собираем информацию по продуктовым изменениям и проверяем, чтобы не было такого, что это фича находилась на этапе раскатки. В остальные релизы используем стандартные тексты, их у нас несколько штук.
Чтобы следить за ростом бинарника мы настроили сбор метрики размера приложения. В случае сильного скачка размера это сразу отображается на графике, и потом берется на изучение причины.
Один из минусов — сильная нагрузка на тестирование, чтобы поддерживать такие темпы. Если проект достаточно большой, то тут без автоматизации будет сложно.
Есть еще проблема влияния внешних факторов, независящих от нас:
Долгое ревью в сторе. Недавно в Google Play наше приложение проходило проверку примерно в 1,5 недели.
Режекты при ревью.
Незапланированные изменения, которые надо обязательно отправить.
Такие случаи не так часто происходят, но иногда бывают. Это создает «пробку» в релизах: отодвигаются даты следующих релизов, некоторые даже могут схлопываться. В это время в проекте могут жить несколько релизных веток, и тут тоже могут возникнуть проблемы.
Спасибо за статью!
Для Appium:
Там есть готовая функция - https://appium.io/docs/en/commands/session/screenshot/
Можно еще запись экрана делать - https://appium.io/docs/en/commands/device/recording-screen/start-recording-screen/
Спасибо, что поделились и подробно описали минусы. Некоторые из них мы попробовали решить так:
Для release notes у нас такая схема: 1 или 2 раза в месяц мы пишем подробный release notes. Для этого заранее собираем информацию по продуктовым изменениям и проверяем, чтобы не было такого, что это фича находилась на этапе раскатки. В остальные релизы используем стандартные тексты, их у нас несколько штук.
Чтобы следить за ростом бинарника мы настроили сбор метрики размера приложения. В случае сильного скачка размера это сразу отображается на графике, и потом берется на изучение причины.
Один из минусов — сильная нагрузка на тестирование, чтобы поддерживать такие темпы. Если проект достаточно большой, то тут без автоматизации будет сложно.
Есть еще проблема влияния внешних факторов, независящих от нас:
Долгое ревью в сторе. Недавно в Google Play наше приложение проходило проверку примерно в 1,5 недели.
Режекты при ревью.
Незапланированные изменения, которые надо обязательно отправить.
Такие случаи не так часто происходят, но иногда бывают. Это создает «пробку» в релизах: отодвигаются даты следующих релизов, некоторые даже могут схлопываться. В это время в проекте могут жить несколько релизных веток, и тут тоже могут возникнуть проблемы.
Сейчас релизные задачи двигаем вручную. Автоматическое изменение статусов в планах.
Наша команда всецело занимается мобильными релизами и всем что с ним связано, в том числе улучшением и поддержкой CI/CD, UI-тестов.