День 1200. #Testing
Тестирование в Реальной Жизни. Окончание
Коротко о различных нестандартных типах тестов и о том, что нужно иметь в виду при их использовании.

Начало

3. Выпуск в производство
На тестовой лаборатории всё не заканчивается. При развёртывании в рабочей среде нужно следовать некоторому регламенту. Обычно есть три подхода.

При первом подходе у вас есть ещё один парк хостов того же размера. Вы развёртываете резервный парк (что может занимать много времени) и атомарно заменяете старые рабочие хосты новыми рабочими хостами (с помощью балансировщика нагрузки или других подобных средств). Это хороший способ, потому что таким же образом можно откатиться на предыдущую версию. Однако это сопряжено с несколькими рисками: вам нужно платить за вдвое больший размер парка, вы можете получить ложные проблемы (например, неисправный хост, неисправный балансировщик нагрузки, неисправный коммутатор и т. д.), при откате также могут возникнуть проблемы (из-за изменения кэшей).

Второй подход основан на поэтапном развёртывании. Вы развертываете часть рабочих хостов и даёте им «прогреться» в течение некоторого времени. Если метрики остаются неизменными, вы предполагаете, что всё сработало правильно, поэтому вы можете развернуть ещё несколько хостов. Это хорошо, потому что вы не платите за гораздо больший парк, но усложняет откат (поскольку для отката требуется время, и процесс может завершиться ошибкой), может возникнуть риск повреждения производственных данных (если на только что развёрнутом хосте в приложении с отслеживанием состояния что-то сломалось). Кроме того, может потребоваться дублирование кэшей, поскольку половина вашего парка продуктов использует старые ключи кэша, а другая половина использует новые ключи.

Третий подход заключается в использовании A/B-тестов или любых переключателей. Вы просто реализуете условие if в своем коде, которым вы можете управлять с помощью некоторого переключателя после развертывания. Таким образом, сначала парк работает только с кодом A. Затем развёртывается приложение с кодом A и B и запускается только код A, потому что переключатель выключен. После развёртывания можно выборочно включить код B на нескольких хостах. Это хорошо, потому что можно контролировать, сколько клиентов получат новое поведение, и легко откатить его. Однако, помимо недостатков предыдущего решения, это также создаёт риск возникновения ошибки в условии if. Не говоря уже о том, что, если у вас несколько переключателей, может быть сложно отследить, что происходит.

4. Повторяющиеся тесты
Имейте в виду, что после развёртывания в рабочей среде всё равно следует повторить тесты бизнес-логики. Недостаточно предположить, что если что-то работало правильно в пре-продакшне, то и в продакшене всё будет хорошо. В рабочей среде используется другая сетевая инфраструктура, другие хосты, другие базы данных, поэтому нужно повторить тесты, чтобы быть уверенным, что всё работает правильно или же откатить изменения.

5. Тесты на проникновение
Аналогичный принцип применим и к тестам на проникновение. Их нужно запускать во всех средах. Производственная среда должна быть физически отделена от среды тестирования, поэтому необходимо убедиться, что конфигурация рабочей среды безопасна и надёжна.

Источник: https://blog.adamfurmanek.pl/2022/02/19/types-and-programming-languages-part-9/