Pull to refresh
14
Karma
0
Rating
Антон Нечеухин @Antnch

QA

  • Followers 11
  • Following

Как эффективно релизить монолит, в который коммитят 150+ разработчиков из разных офисов

-> Как часто вы делаете релизы?
Каждый день выходит новая версия клиента и новая версия сервера. Стараемся не чаще чем раз в день, бывает чаще
-> Как часто у вас обнаруживаются проблемы в канареечных релизах?
К сожалению, часто. На вскидку до 20% релизов находят баги на проде или на бете. Мы постоянно работаем надо улучшением наших процессов обеспечения качества, и это приносит плоды
-> Упомянуто что вы используете е2е тесты — те это что-то типа selenium? используете ли вы модульные тесты (unit)?
Мы стараемся не использовать е2е тесты, то есть страраемся больше покрывать на юнит уровне и интеграционном чаще всего. Компонентых тестов практически нет. Есть API тесты. Почти нет контрактных тестов, и мы будем серьзно решать эту проблему при распилке монолите. Но так или иначе е2е тестов достаточно много, сейчас около 2000. Причем они тяжелые, так как мы используем canvas, это дает некоторую сложность в e2e тестировании, много скриншотных тестов. Мы много думаем над оптимизацией тестов, сейчас полный набор е2е тестов гоняется порядрка 17 мин.
-> какой у вас ттм? и что вы под ттм понимаете?
ттм это t2m? Я думаю это классический термин. Не смогу сказать какой у нас t2m, потому что сильно зависит от команды

Как эффективно релизить монолит, в который коммитят 150+ разработчиков из разных офисов

1. Изменения в БД проиходят посредством миграций. Мы имеем большое количество шардов, которые логически объединены в одну единую базу. Миграции накатываются автоматически при старте первого сервера приложения на новой версии. Тут надо добавить, что у нас нет бизнес логики на стороне базы (процедур, тригеров и т.д), только структура таблиц с индексами, ключами и констрейнтами
2. Мы можем релизиться дальше, потихоньку догоняя последний мастер. К счастью. не бывает большого количества блокирующих проблем, и мы даже в такой схеме с таким большим количеством разработчиков еще не лочим наши релизы напрочь
3. Чаще всего у нас разные версии сервера и клиента совместимы, мы специально стараемся так делать. Когда мы понимаем, что с новым сервером не будут работать старые клиенты, у нас есть механизм, который задает минимальную поддерживаемую версию клиента на сервере. Команды мониторят версию сервера на проде, и релизять свою фронтовую часть только когда серверная стабильна на проде
4. Главным образом, мы стараемся разделять предметные области команд. Это монолит, но команды стараются не перескаться в коде в один момент времени. Это позволяет нам не иметь больших проблем с конфликтами (что обычно часто бывает), и помогает нам реже ломать функционал друг друга. Хотя эта проблема есть, и мы прямо сейчас работаем над ней. Одна из идей, шарить технический дизайн документ, результат экзампл маппинга и другие артефакты до разработки. На ревью проблемы бывает найти сложнее, чем при ревью логики работы (с бизнесовой и технической стороны)
5. Я думаю частично ответ на вопрос здесь. У нас нет ручного регресса, он полностью автоматизирован, там есть и API тестирование. И нет ручного тестирования выделенным QA инженером, реализованных задач. Разработчик сам проверяет за собой по заранее продуманным тест-кейсам (созданным QA инженером чаще всего), и в процессе разработки пишутся тесты, мы стараемся тесты смещать на более низкие уровни на сколько получается (покрывать логику работы юнит тестами, взаимодействия между сервисами и частями сервисов интеграционными тестами и т.д.)
6. Хороший вопрос. Аналогично крупному рефакторингу. Всегда (я думаю всегда), такой рефакторинг делает одна команда, остальные учавствуют в тестировании и ревью
7. Еще один хороший вопрос). Пока нам удается разделять команды по реализуемой логике, даже в рамках одного направления. Мы пока не используем фреймворки вида Less и т.п. Наибольшее общение по планируемым изменениям сейчас происходит на уровне QA разных команд и направлений, и на продуктовом уровне. Также за взаимодействия с другими командами отвечает тим лид команды, если он видит пересечения, он договаривается как будут производиться изменения. Разработчики проактивно также могут общаться между собой, но это не процесс, скорее от случая к случаю
8. А там нет большого количества. Это единичные случаи. Сентри показывает только новые, и даже грязная консоль не проблема для такого анализа
9. Support команда создает тикеты на продуктовые команды. Команды исследуют эти тикеты, и либо отвечают на вопрос, либо создают фиче-реквест, либо создают багу с привязкой к обращению пользователя
10. Все крупные изменения сначала описываются в документе и получают апрувы у релевантных команд. Нет выделенных архитекторов, в каждом направлении есть несколько архитекторов работающих в командах
11. Огромный вопрос. Немного об этом здесь и здесь. Сейчас немного поменялся инструментарий, мы выкинули Jmeter, но идиалогия осталась
12. Это сильно зависит от команды. Даже не получится дать какой то усредненной картины. Есть команды, где баг фиксинг — доли процентов, есть команды где может уходить 50% времени спринтов на баги
13. Мы сильно заморачиваемся на этот счет. Есть дизайн система
14. Я бы сказал нет единого формата и договоренности, что не есть хорошо. Нам придется прийти к этому при распилке монолита
15. Конечно. Техподдержка состоит из 2 линий. Первая отвечает на все обращения, вторая иссследует сложные технические случаи. Там много разных процессов, в том числе, есть процесс по фиксации фиче реквестов. Думаю это тема для целой статьи, и кого из саппорта. Кстати возможно она даже есть, можно поискать…
16. Тут тоже тема очень большая, как бы на нее ответить комментом… наверное требуется уточнение вопроса, чтобы на него ответить. Может быть интересует что то конкретное?
17. Почти 10 лет
18. Шардирование в первую очередь помогает нам распределять нагрузку на разные инстансы. Есть и другие варианты, например вынос чтения на слейв
19. Конечно, ежегодно, SOC2
20. Не понял вопрос. Какой имеется ввиде порог вхождения?
21. Своя реализация. Для бекенд части, канарейка, это новые сервера на новой версии, мы их просто останавливаем. И новые и старые версии всегда совместимы, это правило, по другому у нас нельзя. Для клиенсткой сейчас нет канарейки, только бета

QA-процесс в Miro: отказ от водопада и ручного тестирования, передача ответственности за качество всей команде

1. В разных командах по разному, 1 или 2 недели
2. Все верно, не в конце каждого спринта
3. Да, хорошее замечание, но у нас вовлеченность PO хорошая, и таких проблем сейчас обычно не возникает
4. Фиксим сразу, и может сформироваться еще один спринт на доработки
5. Гарантия — это тесты. Бывают баги с таким подходом, и даже критичные для функционала, но что это влияет на всю систему так она рухнет, это невозможно, потому что каждый мастер перед релизом проходит большие автоматизированные регрессионные проверки, где покрыт базовый функционал. Ну и до этого, при сборке, другие тесты это также контролируют
6. А что вы имеете ввиду?

QA-процесс в Miro: отказ от водопада и ручного тестирования, передача ответственности за качество всей команде

Крутой вопрос, и я соглашусь, что это упущение этой статьи.
Этот процесс внедрялся в нескольких командах последовательно, мы пробовали, измеряли, и выводы учитывали в следующей команде. Было минимум 4 крупных эксперимента — 4 крупных функционала, где мы мерили: lead time, количество багов найденных в процессе разработки, количество багов найденных в фиче на проде, количество итераций разработки, NPS новой фичи. Был пример, когда одна и та же команда разрабатывала очень схожий функционал, при это не реиспользовала код предыдущей фичи, такое хорошее сравнение при прочих равных. И получилось так:
Разработка по старому процессу:
130 багов в общем
13 — выпускалось с таким количеством багов
После релиза заведено 15 багов
Lead time ~ 6 month
По новому процессу:
26 багов в общем
8 — выпускалось с таким количеством багов
После релиза за 3 месяца заведено 7 багов:
Lead time ~ 3 month
->Да, выглядит как некоторые дистиллированные результаты, но не на одном примере они были такими

QA-процесс в Miro: отказ от водопада и ручного тестирования, передача ответственности за качество всей команде

Отвечает, значит каждый знает об этом, и знает что за них это никто не сделает. Каким образом знает? Это вопрос сложнее, и тут надо сказать, что наши инструкции и формальности зачастую опаздывают, потому что мы изменения производим через эксперименты, и что-то начинает работать раньше, чем это «утверждается». Тут нам во многом помогает культура компании
В случае с продактом этот глагол отсутствует, потому что у нас достаточно высока «власть» продакта и уровень его отвественности. Продакт в целом отвечает, за то, ЧТО делает команда, и с него спрос за это с разных сторон. Без описанной части связанной с качеством, продакт не может закрыть более глобальные вещи в нашей продуктовой компании. Это в какой то степени — само собой разумеющееся, в нашем случае

Достоверный нагрузочный тест с учётом непредвиденных нюансов

Спасибо за коммент! Мы вообще не сильно привязаны к инструменту в данный момент и планируем в ближайшее время сделать research, может быть выберем другой инструмент. Может быть gatling для более удобной работы с ws, а может быть и траффик генератор, рассмотрим IXIA и Spirent

Information

Rating
Does not participate
Works in
Date of birth
Registered
Activity