Comments 12
1) интересно сколько мобильных тестов вы гоняете регулярно в CI ?
2) сколько всего сейчас мобильных тестов всего (ios / android)?
У нас два приложения в активной стадии разработки. Одно для соискателей (с которым все знакомы) уже довольно давно живет. В нём картина такая:
390 iOS
452 Android
Второе приложение для работодателей мы с нуля переписали недавно (это совсем другая история), его только сейчас начали покрывать тестами
Гоняются и в ночных прогонах и на PR в develop абсолютно все тесты. Это стало возможным благодаря уходу от trunk-based — не нужно каждый чих проверять на стабильность
О как. Интересно. Т.е. если в день 20 коммитов (в каждый репозиторий) то успеваете за день 20 раз все 800 прогнать. Я правильно понимаю?
Если так - то мне нравится скорость ваших тестов!
Нет, не правильно поняли!
1) iOS и Android в разных репозиториях, поэтому тесты гоняются для каждой платформы отдельно
2) Ночные тесты гоняются на каждой фиче ветке и develop (на ветках разработческих не гоняем). Для ночного среза репозитория из примера(см картинку ниже) будет 3 прогона: 2 на больших фиче ветках и 1 на develop
3) Также гоняются тесты при PR в develop. Таких моментов на диаграмме изображено 3
Если просуммировать, то после 20 дневных коммитов может и не быть прогонов, если еще не настала ночь и мы не делали PR в develop. Так понятнее стало?
Ну погодите. Да фичи делают дольше. Но баг фиксы и не большие изменения выкатываются часто в течение дня. У нас например недавно до 40 в день выходило. Сейчас поменьше 10-15 для каждой платформы.
Мы делаем только ночные прогоны. Около 500 для каждой платформы. И только если надо в течение дня (девы и сами умеют запустить. Не все правда).
В релизах уже на полные 800 -) разгоняем.
Прогон 500 тестов занимает около 2 часов. Андроид чуть быстрее. Поэтому все все на каждый коммит в девелоп нам пока сложно по времени уложится.
У нас багфиксы умещаются внутри фичи. Дело в том, что тестирование фичей проходит в две стадии. Во время разработки QA обсуждает с разработчиком, что можно уже посмотреть, а куда лезть не стоит. Таким образом, когда фича начинает подходить к релизу QA начинает тестирование (пунктир на рисунке ниже). Перед тем, как влить фичу в develop, QA уже тестирует её и все, что можно задеть, капитально.
Таким образом мы получаем практически всегда стабильный develop. Да, конечно, туда может просочиться баг из-за мердж конфликтов или по невнимательности, но их уже фиксят обычно в релизной ветке. Исключения составляют, конечно же, те случаи, когда сломался develop.
Что касается времени прогона тестов и всех проверок — у нас есть вот такой вот дашборд:
Сейчас пришли к тому, что прогон выполняется около 40 минут на Android и около 50 минут на iOS
Чисто тесты проходят за минут 25 (взял рандомную ветку, поэтому число тестов отличается от того, что написал выше)
И да, кстати я вас обманул в первом сообщении, на самом деле распределение по числу тестов наоборот:
390 Android
452 iOS
Шикарная скорость! Нам чтобы ускорить надо до вас надо на 60 тредов перейти. У нас сейчас 25 реальных тел (12 iPhone, 13 Android).
PS и да. Андроид у вас тоже чуть быстрее. Все совпадает.
У нас на iOS симуляторы, а Android вообще в k8s запускаем!
Интересно послушать, как вы с реальным устройствами справляетесь!
Мы на заре нашего UI тестирования пробовали, но не смогли добиться стабильности
Ну с реальными все просто. Я ведь фанат Аппиума. Один проект. Один код под обе оси. Просто манагерить. Ну и все равно на чем бежать, просто реальные телефоны проще, плюс часть функционала пашет только на реальных тел. iPhone проще - они примерно все похожи. Android выбрал Nokia - голый Android, дешевые.
Может надо тоже этот Kubernetes попробовать. Но его ведь надо локально подымать или запускать тесты рядом. Иначе сетевые задержки все сожрут.
Прошу прощения, в сообщении выше перепутал платформы. На самом деле у нас так на текущий момент:
±390 Android
±452 iOS
#режим зануды включен
Сори но ваш процесс разработки в ветках это не Github-flow. Github-flow это хорошо описанный легковесный процесс для разработки. Процитирую автора:
Anything in the master branch is deployable
To work on something new, create a descriptively named branch off of
master(ie:new-oauth2-scopes)Commit to that branch locally and regularly push your work to the same named branch on the server
When you need feedback or help, or you think the branch is ready for merging, open a pull request
After someone else has reviewed and signed off on the feature, you can merge it into master
Once it is merged and pushed to 'master', you can and should deploy immediately
То есть как минимум в нем просто не может быть релиз бранчей - тк master по сути и есть релиз бранч.
#режим зануды выключен.
Как запилить джентльменский релиз