Работали ли вы с Pact для контрактного тестирования в CI/CD?

«Работали ли вы с Pact для контрактного тестирования в CI/CD?» — вопрос из категории CI/CD, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Да, я интегрировал Pact в CI/CD-пайплайны для обеспечения надежности взаимодействия микросервисов. Pact позволяет потребителю (consumer) и поставщику (provider) API независимо разрабатываться, имея общий, исполняемый контракт.

Как это работает в пайплайне:

  1. Consumer Test: Тесты потребителя (например, фронтенд или сервис-заказчик) запускаются с Pact-моком, который записывает все ожидаемые взаимодействия в файл контракта (.pact).
  2. Publish Contract: Контракт публикуется в Pact Broker (например, после успешного прохода пайплайна потребителя).
  3. Provider Verification: Пайплайн поставщика (бэкенд-сервис) забирает актуальный контракт из брокера, запускает реальный сервис и проверяет, что его ответы соответствуют ожиданиям потребителя.
  4. Can-I-Deploy: Перед деплоем любого из сервисов выполняется проверка can-i-deploy через Pact CLI, которая блокирует деплой, если контракт не верифицирован, предотвращая поломки в production.

Пример шага верификации в GitLab CI для сервиса-поставщика (на Python):

provider_verification:
  image: python:3.9
  script:
    - pip install pact-python pytest
    - python -m pytest tests/contract/test_provider.py --pact-broker-url=${PACT_BROKER_URL} --publish-verification-results --provider-version ${CI_COMMIT_SHA}

Ключевые преимущества для DevOps:

  • Раннее обнаружение breaking changes: Поломка API обнаруживается на этапе CI, а не в production.
  • Декомпозиция и скорость: Команды могут работать независимо, не дожидаясь поднятия всех зависимостей для интеграционных тестов.
  • Документация: Pact Broker служит источником истины о текущих и исторических контрактах между сервисами.