Как организовано версионирование микросервисов и библиотек

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

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

Как отвечать

Разведите три вещи, которые часто смешивают:

• версия библиотеки: SemVer, MAJOR.MINOR.PATCH. MAJOR ломает совместимость, MINOR добавляет возможности, PATCH исправляет ошибки. Версии зависимостей зафиксированы в lock-файлах (package-lock.json, poetry.lock) или явно в pom.xml, поэтому сборка воспроизводима;
• версия сервиса: образ тегируется номером релиза и хэшем коммита, в Git ставится тег. Сервис отдаёт свою версию через служебный эндпоинт, например /actuator/info в Spring Boot;
• версия API: /v1 и /v2 в пути или заголовок. Она меняется только при ломающем изменении контракта и не обязана совпадать с версией сборки.

Что с этим делает QA:

• в каждом баг-репорте указывает версию сервиса и окружение, а не только «на тесте»;
• проверяет, что на стенде стоит нужный тег, а не latest;
• для связи сервисов опирается на контрактные тесты (Pact, Spring Cloud Contract): потребитель фиксирует ожидания, провайдер проверяет, что их не сломал;
• при MINOR-релизе прогоняет сценарии старых клиентов на новом сервере;
• сверяет changelog с тем, что реально попало в сборку. Если в команде принят Conventional Commits, версия и changelog часто собираются автоматически.

Добавьте пример из своей практики: баг, который оказался несовпадением версий. Если такого не было, скажите честно и опишите, как проверили бы.

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

Тестируют на образе с тегом latest. Невозможно понять, что именно проверено, и повторить результат.

Считают PATCH-обновление безопасным без регресса. Исправление ошибки тоже меняет поведение, и кто-то мог на прежнее поведение опираться.

Путают версию сервиса с версией API и предлагают /v2 на каждый релиз. Клиенты от этого только страдают.