Как происходит интеграция нескольких сервисов на стенде

Что проверяют

Понимаете ли вы, как устроен стенд, на котором тестируете: откуда там берутся сервисы, каких они версий и что делать, если соседний сервис сломан. Частый уточняющий вопрос: как вы понимаете, что упало, ваш сервис или его зависимость.

Как отвечать

Расскажите путь от коммита до работающей связки сервисов:

• сборка и выкладка: каждый сервис собирается в Docker-образ, CI (GitLab CI, Jenkins, GitHub Actions) выкатывает его на стенд. Обычно это namespace в Kubernetes с Helm-чартами или docker compose для небольших систем;
• конфигурация: адреса соседей, строки подключения и фича-флаги приходят через переменные окружения или values-файлы, а не зашиты в код. Миграции базы накатываются при деплое через Liquibase или Flyway;
• версии: на общем стенде важно знать, какая версия каждого сервиса сейчас стоит. Помогает эндпоинт с версией сборки или описание стенда в Git;
• внешние системы: платёжные шлюзы, СМС, партнёрские API на стенде заменяются заглушками (WireMock, MockServer), иначе стенд зависит от чужой доступности;
• проверка после выкладки: health-check и readiness-пробы, затем быстрый смоук, затем интеграционные и сквозные сценарии;
• контракты: чтобы не узнавать о несовместимости на стенде, команды проверяют контракты заранее, например через Pact или сверку с OpenAPI-спецификацией в CI.

Для разбора падений назовите сквозной идентификатор запроса, трассировку (OpenTelemetry, Jaeger) и централизованные логи (ELK, Loki). По trace id видно, на каком сервисе запрос оборвался.

Опишите, как было у вас: общий стенд или отдельный на каждую ветку, кто его выкатывает, как договаривались, кто сейчас его занимает. Ценятся реальные детали, а не схема из статьи.

Где спотыкаются

Не знают, что стоит на стенде. Тестируют задачу, а рядом лежит сервис трёхдневной давности, и баг оказывается несовместимостью версий.

Заводят баг на свой сервис, не посмотрев логи соседей. Проще найти запрос по trace id и показать, где он упал.

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