В тексте не называл Саутгейта не разу плохим менеджером, слово менеджер употреблено в значении не "футбольный менеджер", а "руководитель команды разработки"
Это же статья про то, на сколько компания известна именно как работодатель! Если так смотреть, то цифра, что 33% опрошенных знают, как работает условный Ozon внутри, вполне адекватна. Вот если бы было где-то 100%, то тогда бы надо было напрячься)
Очень частый вопрос: как вообще выделять правильно модули. Так и не смог для этого вынести какие-то формальные критерии. Получается что-то типа: отдельная фича — это кусок кода с изолированной логикой, не очень большой и не очень маленький >_<
Кризис в стране, батенька, ещё не понятно что с вашими сикуэлами будет, а вот в виду проблем с импортом качественной техники мастера-ремонтники могут озолотиться?
А почему так мало мобильных разработчиков? Если нужна помощь в проникновение в сообщество (тот же Android Dev Podcast или Android Broadcast), пишите в личку
У нас багфиксы умещаются внутри фичи. Дело в том, что тестирование фичей проходит в две стадии. Во время разработки QA обсуждает с разработчиком, что можно уже посмотреть, а куда лезть не стоит. Таким образом, когда фича начинает подходить к релизу QA начинает тестирование (пунктир на рисунке ниже). Перед тем, как влить фичу в develop, QA уже тестирует её и все, что можно задеть, капитально.
Таким образом мы получаем практически всегда стабильный develop. Да, конечно, туда может просочиться баг из-за мердж конфликтов или по невнимательности, но их уже фиксят обычно в релизной ветке. Исключения составляют, конечно же, те случаи, когда сломался develop.
Что касается времени прогона тестов и всех проверок — у нас есть вот такой вот дашборд:
Сейчас пришли к тому, что прогон выполняется около 40 минут на Android и около 50 минут на iOS
Чисто тесты проходят за минут 25 (взял рандомную ветку, поэтому число тестов отличается от того, что написал выше)
И да, кстати я вас обманул в первом сообщении, на самом деле распределение по числу тестов наоборот:
1) iOS и Android в разных репозиториях, поэтому тесты гоняются для каждой платформы отдельно
2) Ночные тесты гоняются на каждой фиче ветке и develop (на ветках разработческих не гоняем). Для ночного среза репозитория из примера(см картинку ниже) будет 3 прогона: 2 на больших фиче ветках и 1 на develop
3) Также гоняются тесты при PR в develop. Таких моментов на диаграмме изображено 3
Если просуммировать, то после 20 дневных коммитов может и не быть прогонов, если еще не настала ночь и мы не делали PR в develop. Так понятнее стало?
У нас два приложения в активной стадии разработки. Одно для соискателей (с которым все знакомы) уже довольно давно живет. В нём картина такая:
390 iOS
452 Android
Второе приложение для работодателей мы с нуля переписали недавно (это совсем другая история), его только сейчас начали покрывать тестами
Гоняются и в ночных прогонах и на PR в develop абсолютно все тесты. Это стало возможным благодаря уходу от trunk-based — не нужно каждый чих проверять на стабильность
@benavirот себя еще предложил бы вам хотя бы временно уменьшить нагрузку на тестировщика. Вообще 1 к 7 это еще хуже чем в известной картинке!
Как можно снять нагрузку? Можно найти много способов, например:
Отправить двоих разрабов разрабатывать фреймворк и инфру для автотестов (это убьет сразу же двух зайцев, кстати)
Взять на пару месяцев аутстаф тестировщика на мануальное тестирование, чтобы разгрузить Вас (мы, кстати, так сделали, когда запускали автотестирование на втором приложении)
Дождаться, когда команда уйдет в отпуск ( перед новогодними, например)
Удачи Вам, поговорите, со своим руководителям о балансе сил!
В тексте не называл Саутгейта не разу плохим менеджером, слово менеджер употреблено в значении не "футбольный менеджер", а "руководитель команды разработки"
Претензий к финалу особо нет — обычно это скучная игра. Большие вопросы к другим встречам, где команда проскочила чисто на мастерстве исполнителей
Помню когда начинал работать с тимлидом одной из команд, у них 1-1 проходил тимлид - проджект менеджер - член команды.
И главное, никого не смущал этот треугольник?
Можно еще посмотреть на зарплаты на том же career.ru, вот к примеру у джавистов https://career.ru/profession/38?grade=senior
Если у вас есть крутые идеи, можете написать в телеграмм чатик с нашими разработчиками и передать их в первые руки так сказать https://t.me/hh_tech ;)
В чате обсуждаем больше технологии, архитектуру и тд, но годные идеи тоже рады будем слышать
Это же статья про то, на сколько компания известна именно как работодатель! Если так смотреть, то цифра, что 33% опрошенных знают, как работает условный Ozon внутри, вполне адекватна. Вот если бы было где-то 100%, то тогда бы надо было напрячься)
Очень частый вопрос: как вообще выделять правильно модули. Так и не смог для этого вынести какие-то формальные критерии. Получается что-то типа: отдельная фича — это кусок кода с изолированной логикой, не очень большой и не очень маленький >_<
Кризис в стране, батенька, ещё не понятно что с вашими сикуэлами будет, а вот в виду проблем с импортом качественной техники мастера-ремонтники могут озолотиться?
Видимо поиск считает, что с Вашими набором навыков неплохо себя и в разработке попробовать?
Вот тут в охэхэнной истории про релиз Даня рассказал, почему мы переходили на GIthub Flow и почему нас не устроил подход trunk based.
Вкратце: хотели стабильный develop, при этом минимально вкладываться в инфраструктуру
А почему так мало мобильных разработчиков? Если нужна помощь в проникновение в сообщество (тот же Android Dev Podcast или Android Broadcast), пишите в личку
У нас на iOS симуляторы, а Android вообще в k8s запускаем!
Интересно послушать, как вы с реальным устройствами справляетесь!
Мы на заре нашего UI тестирования пробовали, но не смогли добиться стабильности
Прошу прощения, в сообщении выше перепутал платформы. На самом деле у нас так на текущий момент:
±390 Android
±452 iOS
У нас багфиксы умещаются внутри фичи. Дело в том, что тестирование фичей проходит в две стадии. Во время разработки QA обсуждает с разработчиком, что можно уже посмотреть, а куда лезть не стоит. Таким образом, когда фича начинает подходить к релизу QA начинает тестирование (пунктир на рисунке ниже). Перед тем, как влить фичу в develop, QA уже тестирует её и все, что можно задеть, капитально.
Таким образом мы получаем практически всегда стабильный develop. Да, конечно, туда может просочиться баг из-за мердж конфликтов или по невнимательности, но их уже фиксят обычно в релизной ветке. Исключения составляют, конечно же, те случаи, когда сломался develop.
Что касается времени прогона тестов и всех проверок — у нас есть вот такой вот дашборд:
Сейчас пришли к тому, что прогон выполняется около 40 минут на Android и около 50 минут на iOS
Чисто тесты проходят за минут 25 (взял рандомную ветку, поэтому число тестов отличается от того, что написал выше)
И да, кстати я вас обманул в первом сообщении, на самом деле распределение по числу тестов наоборот:
390 Android
452 iOS
Нет, не правильно поняли!
1) iOS и Android в разных репозиториях, поэтому тесты гоняются для каждой платформы отдельно
2) Ночные тесты гоняются на каждой фиче ветке и develop (на ветках разработческих не гоняем). Для ночного среза репозитория из примера(см картинку ниже) будет 3 прогона: 2 на больших фиче ветках и 1 на develop
3) Также гоняются тесты при PR в develop. Таких моментов на диаграмме изображено 3
Если просуммировать, то после 20 дневных коммитов может и не быть прогонов, если еще не настала ночь и мы не делали PR в develop. Так понятнее стало?
У нас два приложения в активной стадии разработки. Одно для соискателей (с которым все знакомы) уже довольно давно живет. В нём картина такая:
390 iOS
452 Android
Второе приложение для работодателей мы с нуля переписали недавно (это совсем другая история), его только сейчас начали покрывать тестами
Гоняются и в ночных прогонах и на PR в develop абсолютно все тесты. Это стало возможным благодаря уходу от trunk-based — не нужно каждый чих проверять на стабильность
Спасибо, мне постоянно казалось, что называем неправильно — похоже мы изобрели hh-flow. Погнали патентовать?
Не понял, а у вас кроссплатформенные тесты на java?
А какой стек целиком? На сколько флакуют?
@Calcв прошлом году было аналогичное исследование, вот тут можно посмотреть результат
@benavir от себя еще предложил бы вам хотя бы временно уменьшить нагрузку на тестировщика. Вообще 1 к 7 это еще хуже чем в известной картинке!
Как можно снять нагрузку? Можно найти много способов, например:
Отправить двоих разрабов разрабатывать фреймворк и инфру для автотестов (это убьет сразу же двух зайцев, кстати)
Взять на пару месяцев аутстаф тестировщика на мануальное тестирование, чтобы разгрузить Вас (мы, кстати, так сделали, когда запускали автотестирование на втором приложении)
Дождаться, когда команда уйдет в отпуск ( перед новогодними, например)
Удачи Вам, поговорите, со своим руководителям о балансе сил!