Feature-флаги для интеграций: удобно в проде, больно в тестах
В PDP и PDP Mobile внешние интеграции можно выключать через конфиг точечно — на уровне отдельных домов и ЖК. Но за гибкость приходится платить комбинаторной сложностью тестирования.
В PDP и PDP Mobile мы сделали так, что внешние интеграции — CRM, 1С, валидация адресов, СКУД, банк-эквайер — можно выключать через конфиг. Не глобально, а точечно: на уровне отдельных домов и ЖК. По сути, feature-флаги рулят доступностью функционала там, где это реально нужно.
Звучит кайфово: меньше хардкода, больше гибкости, быстрее катим изменения. Но есть нюанс, и он классический для 2025-го, когда все любят конфигурируемость: комбинаторная сложность тестирования.
Каждая комбинация on/off у CRM, 1С, адресного сервиса, СКУД и эквайринга — это уже отдельный сценарий. То есть “просто проверим флажки” быстро превращается в квест уровня “почему оплата есть, а пропуск не выписался”.
Мы столкнулись с тем, что optional integration — это не “опционально для QA”. Это архитектурная гибкость, за которую платишь матрицей сценариев.