TestGrow - тестирование ПО

Иногда слышу, что деплой - это залить новую версию на сервер. На самом деле у компаний есть целые стратегии того, как именно обновлять продукт, чтобы пользователи ничего не заметили (или хотя бы заметили как можно меньше). Существуют разные подходы. Blue/Green деплоймент - это когда у вас есть два окружения, одно активное, другое запасное. Выкатили новую версию на неактивное, переключили трафик на это окружение и готово. Быстро и удобно, но требует лишних ресурсов. Feature Toggle означает, что задача добавлена в код релиза, но спрятана за флагом (выключателем). Если нужно, чтобы задача заработала, то включили для определенных пользователей, не нужно - выключили. Отлично работает для экспериментов, но усложняет тестирование, потому что система ведет себя по-разному для разных групп включенных/выключенных Feature Toggle. Canary deployment - это когда новая версия раскатывается постепенно, то есть сначала для части пользователей, потом для большего числа, и только после этого для всех. Это снижает риски, потому что если что-то сломается, пострадает только малая часть аудитории. Rolling updates - новая версия накатывается по чуть-чуть на разные серверы, чтобы не было простоя. В какой-то момент часть пользователей сидит на старом коде, часть на новом. Хорошо для масштабных систем, но требует мониторинга. A/B тестирование. Казалось бы, это больше про маркетинг и продукт, но на самом деле это тоже стратегия деплоя. Две версии живут параллельно, пользователи распределяются между ними, а команда смотрит, какая лучше работает. Для тестировщика эти стратегии не просто термины из DevOps. Они напрямую влияют на то, как подходить к тестированию. В Blue/Green баг может проявиться только после переключения, в Canary его увидит ограниченная группа, а с Feature Toggles придется проверять кучу комбинаций включенных/выключенных флагов. Также стратегия деплоя может влиять на тестовое покрытие и объемы тестирования в целом, потому что в некоторых случаях, например, при работе Feature Toggles, продукт может пойти на риск и проверить только критичные проверки в релизе в надежде, что при проблеме на продуктиве будет возможность быстро отключить задачу. А какая стратегия деплоймента практикуется в вашей компании?👇 Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний