![](https://habrastorage.org/getpro/habr/post_images/563/98e/76b/56398e76be6355ad5999b262208a17c9.gif)
![](https://habrastorage.org/webt/xi/ny/b7/xinyb7sar_jz5ueywnjobp8rfrs.jpeg)
Фильм “Аэроплан”, 1980г.
Примерно так я себя чувствовал, когда выливал очередной рефакторинг на прод. Даже если весь код покрыть метриками и логами, протестировать функционал на всех окружениях — это не спасет на 100% от факапов после деплоя.
Первый факап
Как-то мы рефакторили наш процессинг интеграций с Google Sheets. Для пользователей это очень ценный функционал, т.к. они используют много инструментов одновременно, которые нужно связывать между собой — отправлять контакты в таблицу, выгружать ответы на вопросы, экспортировать пользователей и т.д.
Код интеграций не рефакторился с первой версии и его становилось все сложнее поддерживать. Это начало аффектить наших пользователей — выявлялись старые баги, которые мы боялись править из-за сложности кода. Пришло время что-то сделать с этим. Никаких логических изменений не предполагалось — просто написать тесты, подвигать классы и причесать имена. Конечно, мы протестировали функционал на dev окружении и пошли деплоить.
Через 20 минут пользователи написали, что интеграция не работает. Отвалился функционал отправки данных в Google Sheet — оказалось, что для дебага мы отправляем данные в разных форматах для прода и локального окружения. При рефакторинге мы задели формат для прода.
Интеграцию мы починили, но все же осадочек от веселого пятничного вечера (а вы думали!) остался. На ретроспективе (встрече команды по завершению спринта) мы стали думать, как предотвратить такие ситуации в будущем — нужно улучшить практики ручного тестирования, авто-тестирования, работу с метриками и алярмами, а кроме этого нам пришла идея использовать фича-флаги для тестирования рефакторинга на проде, собственно, об этом и пойдёт речь.