День 1562. #BestPractices
Лучшие Практики Безопасного Развёртывания и Масштабирования Приложений. Окончание
Начало
Продолжение

7. Добавьте эксперименты и A/B-тестирование
При добавлении каких-либо изменений, таких как новая функция или изменение UX, отлично подходит A/B-тест, чтобы убедиться, что изменение является положительным и не создаёт никаких проблем. Добавьте механизм для разделения ваших пользователей на 2 или более групп и запускайте для них разный код. Контролируйте обе группы эксперимента: контрольную и экспериментальную (группу A и группу B). Есть ли увеличение в журналах ошибок? Как насчёт всплесков жалоб от клиентов? Проверьте информационные панели, есть ли аномалии?
Такие эксперименты отлично подходят для выявления проблемных изменений, если у вас есть хороший способ сопоставить телеметрию с экспериментальными группами. Нужно просто при запуске сессии регистрировать все сессии экспериментальной группы, а затем сопоставлять их с проблемными сессиями.

8. Проводите пассивное тестирование
Пассивные тесты — отличный способ убедиться, что ваши изменения ведут себя правильно в большой среде, которую вы не до конца понимаете. Учтите, что, когда вы делаете какую-то оптимизацию или рефакторинг в огромном приложении, вы не можете с полной уверенностью предсказать, что ничего не сломали. Конечно, у вас есть набор тестов, но вы никогда не знаете наверняка, что он охватывает все случаи. Вместо этого вы можете сделать пассивный тест. Выполняйте любую оптимизацию или изменение, которое вам нужно, в темноте, работая пассивно, в дополнение к исходной реализации. Запустите как старый (активный) код, так новый (пассивный), а затем сравните результаты в логах. Разверните новый код в производственной среде и убедитесь, что поведение исходного и изменённого кода совпадает. Как только вы увидите, что они идеально совпадают, вы можете уверенно переключиться со старого кода на новый.

9. Тестируйте
Тесты оставлены напоследок, потому это вроде бы и очевидно, но тем не менее важно и о них нужно упомянуть.
Одним из самых важных механизмов, позволяющих убедиться, что следующее развёртывание не сломает ничего существенного, является набор тестов. Это должно быть стандартной практикой в наши дни, но множество проектов даже сейчас всё ещё существуют без них. Когда у вас есть тесты, обязательно применяйте их, что обычно означает добавление политики в пулл-реквесты, которая гарантирует, что все тесты пройдены.
Когда у вас есть непрерывный процесс интеграции, пришло время рассмотреть стратегию тестирования. Вы стремитесь к определённому уровню покрытия кода? Все ли новые функции требуют некоторого количества тестов? Автоматически применять такие правила сложно, но всё же полезно определить политику для команды и попытаться следовать ей самостоятельно и при обзорах кода.
Помимо модульных тестов, хорошо иметь приличное количество интеграционных и сквозных тестов. Они не определят основную причину, если тест не пройдёт, но отлично подойдут для обнаружения ошибок и проверки работоспособности вашей системы в целом. Модульные тесты, как правило, легко ломаются при рефакторинге или изменении поведения, даже если система работает так, как ожидалось, в то время как сквозные тесты обычно остаются нетронутыми, если вы не вносите ошибки. Можно даже удалить некоторые или большинство модульных тестов после завершения разработки и оставить только интеграционные и E2E-тесты. Или, по крайней мере, будьте гибкими, чтобы со временем отказаться от модульных тестов в пользу более глобальных.

Источник: https://michaelscodingspot.com/safe-application-deployment/