Code review осуществляем в bitbucket, в соответствии с successfull git branching model.
Изменения должны быть оформлены в соответствии с нашим Coding Convention. Для merge обязателен аппрув от члена команды интеграционного тестирования.
У нас автоматизирована логика назначения ревьюеров на созданный PR, а также автоматическая проверка бранча на предмет соответствия минимальным требованиям — но это, возможно, тема для отдельной статьи.
Приемочных тестов на данный момент около 1500, они покрывают end-2-end сценарии разной степени сложности: иногда в сценарии участвуют 2 компонента, иногда 22. Компонентные тесты на сервисы, unit тесты — запускаются отдельно. Стабильность зависит от множества факторов, например, от того, задействован ли web-браузер в тесте, сколько компонентов затрагивает сценарий, как нагружены тестовая среда и CI-инструментарий. Перепрогоны в jenkins pipeline позволили снизить частоту откровенно случайных падений почти до 0.
Проверка сценариев отката, как и совместимость существующих данных с новой версией компонента, находится в зоне ответственности команд. Наша задача — провести интеграционное тестирование работоспособности бизнес-сценариев на окружении, приближенном к боевому максимально возможно.
Команды часто гоняют тесты на фичесборках, но это на сегодняшний день опция. Причина — в тонкостях организации тестовой среды. Интеграционные тестовые стенды более прокачаны, чем тестовые стенды команд, как с точки зрения ресурсов, так и с точки зрения числа сервисов: на тестовых стендах команд могут отсутствовать компоненты, которые данной командой не используются при разработке новых фичей, а следовательно, полный набор приемочных тестов на такой схеме проходить не обязан.
Каждую ночь версии всех компонент на тестовых средах синхронизируются с продакшен-средой. В течение дня релизы тестируются на свободных схемах, выбранных рандомно. Таким образом, к концу дня имеем разной степени обновленности схемы. Ночью — снова синк. Как показала практика, жить так можно. При тестировании зависимых сервисов приходится вручную накатывать их на все стенды.
Здесь без вмешательства человека не обходится. О таких коллизиях нас предупреждают команды, и мы уже самостоятельно разрешаем все зависимости.
Обычно сценарии поломанных тестов проверяют вручную, непротестированные фичи ни в коем случае не деплоятся в продакшен.
Важная функция блокировки — дать возможность отложить запуск новых тестов, написанных на фичу, до ее релиза. Блокировка старых тестов бывает не так часто, и, как правило, команды актуализируют код тестов параллельно изменениям в сервисе. Отключаются только тесты на минорную функциональность, и под ответственность команды, которая релизит компонент.
При перезапуске параметризованных тестов «из коробки» заново прогоняются все комбинации. У нас немного параметризованных сценариев в приемке, они чаще используются в других типах автотестов.
1. Исключаем с помощью сервиса quick-block. После решения задачи тест автоматом начнет запускаться, так как проверяем актуальность задачи в jira перед каждым запуском приёмки.
2. На практике, часто падающие тесты анализируются после сбора статистики, и в причинах их падения мы разбираемся. Исключить пропуск плавающих багов нельзя, но при нашем числе релизов лучше принимать такой риск, чем тормозить релизный цикл за счет ручного разбора упавших flaky-тестов.
megamozg.ru/post/22646 Здесь не о том, как делать надо, а о том, как не надо. С другой стороны — специфика вашего бизнеса направлена на компании, которым новые парадигмы мягко говоря не близки…
Code review осуществляем в bitbucket, в соответствии с successfull git branching model.
Изменения должны быть оформлены в соответствии с нашим Coding Convention. Для merge обязателен аппрув от члена команды интеграционного тестирования.
У нас автоматизирована логика назначения ревьюеров на созданный PR, а также автоматическая проверка бранча на предмет соответствия минимальным требованиям — но это, возможно, тема для отдельной статьи.
Приемочных тестов на данный момент около 1500, они покрывают end-2-end сценарии разной степени сложности: иногда в сценарии участвуют 2 компонента, иногда 22. Компонентные тесты на сервисы, unit тесты — запускаются отдельно. Стабильность зависит от множества факторов, например, от того, задействован ли web-браузер в тесте, сколько компонентов затрагивает сценарий, как нагружены тестовая среда и CI-инструментарий. Перепрогоны в jenkins pipeline позволили снизить частоту откровенно случайных падений почти до 0.
Проверка сценариев отката, как и совместимость существующих данных с новой версией компонента, находится в зоне ответственности команд. Наша задача — провести интеграционное тестирование работоспособности бизнес-сценариев на окружении, приближенном к боевому максимально возможно.
Команды часто гоняют тесты на фичесборках, но это на сегодняшний день опция. Причина — в тонкостях организации тестовой среды. Интеграционные тестовые стенды более прокачаны, чем тестовые стенды команд, как с точки зрения ресурсов, так и с точки зрения числа сервисов: на тестовых стендах команд могут отсутствовать компоненты, которые данной командой не используются при разработке новых фичей, а следовательно, полный набор приемочных тестов на такой схеме проходить не обязан.
Каждую ночь версии всех компонент на тестовых средах синхронизируются с продакшен-средой. В течение дня релизы тестируются на свободных схемах, выбранных рандомно. Таким образом, к концу дня имеем разной степени обновленности схемы. Ночью — снова синк. Как показала практика, жить так можно. При тестировании зависимых сервисов приходится вручную накатывать их на все стенды.
Здесь без вмешательства человека не обходится. О таких коллизиях нас предупреждают команды, и мы уже самостоятельно разрешаем все зависимости.
Обычно сценарии поломанных тестов проверяют вручную, непротестированные фичи ни в коем случае не деплоятся в продакшен.
Важная функция блокировки — дать возможность отложить запуск новых тестов, написанных на фичу, до ее релиза. Блокировка старых тестов бывает не так часто, и, как правило, команды актуализируют код тестов параллельно изменениям в сервисе. Отключаются только тесты на минорную функциональность, и под ответственность команды, которая релизит компонент.
1. Исключаем с помощью сервиса quick-block. После решения задачи тест автоматом начнет запускаться, так как проверяем актуальность задачи в jira перед каждым запуском приёмки.
2. На практике, часто падающие тесты анализируются после сбора статистики, и в причинах их падения мы разбираемся. Исключить пропуск плавающих багов нельзя, но при нашем числе релизов лучше принимать такой риск, чем тормозить релизный цикл за счет ручного разбора упавших flaky-тестов.