Consumer-Driven Contract Testing: Pact, CI/CD і незалежний деплой

Consumer-Driven Contract Testing: де розривається незалежний деплой

Два сервіси збираються в різних репозиторіях і викочуються за власним графіком — у цьому й сенс незалежного деплою.

Поки обидві сторони змінюються синхронно, сумісність тримається на негласних домовленостях: поле обов’язкове, формат дати не змінюється, зайві поля можна ігнорувати.

Щойно графіки розходяться, домовленості перестають працювати — споживач чекає на нове поле у відповіді, постачальник перейменував його в межах свого завдання, а обидві збірки при цьому зелені.

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

Несумісність сервісів спливає вже в проді: частина запитів падає, частина повертає скорочену відповідь, і дізнаються про це від користувачів, а не від конвеєра.

Далі команди платять двічі. Спершу відкатом чужого релізу, який «зламав» сусідів. Потім ручними погодженнями релізів — спільним календарем викочувань і синхронними вікнами, де всі чекають на всіх. Незалежний деплой залишається на словах: темп падає до монолітного, а ціна помилки не знижується.

Consumer-Driven Contract Testing закриває саме цей розрив. Споживач фіксує очікування до постачальника контрактом — які запити надсилає і що хоче бачити у відповіді, — а конвеєр постачальника перевіряє ці контракти до викочування, на кожній збірці.

Несумісність виявляється в конвеєрі, а не в проді, і обидві сторони знову випускають релізи у своєму темпі. Нижче — як це влаштовано і що потрібно, щоб контракти не перетворилися на формальність.

Що дають контрактні перевірки сервісам і релізам

Контракт — це специфікація взаємодії, яку формує споживач сервісу: які запити він надсилає і яку відповідь вважає коректною.

Pact перетворює її на перевірюваний артефакт, який постачальник проганяє у себе до викладки, — і ручне приймання на спільному стенді з одночасним підняттям усіх суміжних сервісів перестає бути обов’язковим етапом.

Звідси перший вимірюваний наслідок — швидкість релізів.

Час перевірки сумісності падає з годин ручних прогонів до хвилин автоматичного прогону в збірковому конвеєрі: розбіжність у назві поля або коді відповіді спливає на збірці, а не після викладки, коли її шукають за логами й трасуваннями. Команда перестає синхронізувати вікна викладки із сусідами.

Друге — зникає цілий клас відмов на стику сервісів: мовчазна зміна поля, зайвий обов’язковий параметр, змінений код помилки. Така відмова неприємна тим, що проявляється не одразу і не в тому сервісі, де її зроблено: падає споживач, а причина — у постачальнику. Контрактні перевірки ловлять розбіжність до мержу, тому відмова не доходить до робочого контуру.

Постачальник і споживач після цього збираються незалежно: контракт версіонується і публікується в брокері, споживач піднімає заглушку замість живого сервісу і не чекає на чужий реліз.

Час відновлення скорочується, бо відкат потрібен лише одній стороні — версія контракту позначена, і обидві сторони знають, яку сумісність було перевірено.

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

Варіанти перевірки сумісності: порівняння підходів

Сумісність сервісів перевіряють кількома способами, і різниця між ними — у тому, коли спливе несумісна зміна: на збірці, на спільному стенді чи на бойовому контурі вночі. Чим раніше спрацьовує перевірка, тим дешевша правка і тим менше команд вона зачіпає.

На практиці підходи поєднують: контракти споживача закривають регрес сумісності на кожній збірці, а наскрізні перевірки на стенді залишаються для сценаріїв, які контрактом не описати.

Як ми впроваджуємо контрактні перевірки: етапи роботи

Впровадження контрактних перевірок починається не з коду, а з інвентаризації: реальних зв’язків у сервісу зазвичай більше, ніж видно з документації, — частина викликів іде через спільні бібліотеки, кеш і фонові завдання.

Фіксуємо кожну пару «споживач — постачальник», позначаємо, які поля споживач справді читає, і лише від цього проєктуємо перевірки.

1. Інвентаризація інтеграцій. Збираємо споживачів і постачальників за репозиторіями, журналами викликів і опитуванням команд. На виході — карта зв’язків: де контракт описано, а де він тримається на домовленостях у листуванні.

2. Проєктування схеми обміну. Для кожної пари фіксуємо мінімальний набір полів, формати, обов’язковість, коди відповідей і поведінку при помилках. У схему потрапляє лише те, що споживач реально читає.

3. Версіонування контракту. Руйнівна зміна — нова мажорна версія і паралельна підтримка старої, поки споживачі не перейдуть. Зворотно сумісні розширення проходять без зміни версії.

4. Налаштування перевірок у конвеєрі. Перевірки на боці постачальника генеруються з описів споживачів і запускаються на кожен коміт. Збірка падає до викочування — розбіжність бачить автор зміни, а не черговий.

5. Перевірка на стендах і бойовому трафіку. Спочатку тестовий контур, потім тіньовий режим на частині реальних запитів: розбіжності фіксуються, але викочування не блокується. Так знаходяться сценарії, яких немає в тестових даних.

6. Передача команді. Віддаємо конфігурації, описи контрактів і регламент змін, розбираємо правки на живих задачах. Далі команда змінює схеми сама, а ми долучаємося на спірних змінах.

Що залишається в репозиторії та в документації команди

Контракт живе не в листуванні й не в голові власника сервісу, а в репозиторії та в документації команди. Інакше за пів року ніхто не згадає, які поля мають зберігатися, а яка правка ламає сусідній сервіс.

Нижче комплект артефактів, який після впровадження залишається у вас і підтримується вашими розробниками без нашої участі.

• Файли контрактів за кожним споживачем: видно, які поля, коди відповідей і формати помилок мають зберегтися в новій версії сервісу.
• Схема взаємодії: напрямок викликів, власники сервісів і точки відмови — оновлюється з кожним новим споживачем.
• Регламент змін: хто погоджує правку, що вважається руйнівною зміною, скільки живе стара версія і як оголошується відмова від неї.
• Правила версіонування: як позначається несумісна правка і як споживач закріплюється за перевіреною версією контракту.
• Документація інтеграцій: приклади запитів і відповідей, обробка помилок, обмеження за навантаженням — читається без запуску сервісів.
• Інструкція для нового розробника: як підняти середовище, прогнати перевірки контрактів локально і підключити свій сервіс до спільної схеми.
• Чек-ліст приймання перед викладкою: які перевірки проходять обов’язково, щоб несумісність ловилася до продакшену, а не після.
• Журнал розбіжностей: куди потрапляють знайдені невідповідності, хто їх закриває і в який термін.

Комплект вважається зданим, коли ним користується людина, яка не брала участі у впровадженні: розгортає стенд, проганяє перевірки і одразу бачить, де саме розходяться контракти.

Кейс: незалежні релізи без ручних погоджень

Замовник — платформа з 14 сервісів, які розвивали чотири команди. Будь-яка зміна публічного інтерфейсу запускала ручні погодження: листування в спільному каналі, очікування підтвердження від кожної команди-споживача, спільний прогін на спільному середовищі.

За місяць набиралося понад сорок таких погоджень, а шлях від готового коду до випуску займав шість-вісім тижнів.

Споживачі почали описувати очікування до сервісу у вигляді контракту, а Pact перевіряв їх у збірці обох сторін: постачальник дізнається про несумісну зміну до випуску, а не після.

Контракт версіонується разом із кодом і потрапляє до спільного реєстру, тому ручне підтвердження перестало бути обов’язковим кроком.

Через два місяці супроводу ручних погоджень не залишилося зовсім.

Випуск зміни скоротився із шести-восьми тижнів до двох-трьох днів, частка відмов на стику сервісів упала приблизно в п’ять разів, а розбір несумісності займає хвилини — збірка прямо вказує, який контракт порушено і яка сторона його зламала.

Додатково зафіксували: контракти покривають усі 14 сервісів, перевірка йде на кожну зміну, публікація несумісного контракту блокує випуск. Незалежний деплой став робочим режимом, а спільний канал погоджень перетворився на архів.

Чим контрактні тести відрізняються від інтеграційних?

Контрактний тест перевіряє очікування споживача до постачальника: який запит іде і яка відповідь вважається допустимою. Інтеграційний піднімає живе середовище — базу, брокер, сусідній сервіс — і перевіряє зв’язку цілком. Предмет різний: домовленість про інтерфейс проти фактичної поведінки в середовищі.

Звідси різниця у швидкості зворотного зв’язку. Контрактний прогін порівнює реалізацію зі специфікацією — секунди, без піднятої інфраструктури, тому йде на кожну зміну в гілці.

Інтеграційному потрібен готовий стенд із даними і зовнішніми залежностями — це хвилини, а за нестабільного середовища ще й повторні прогони.

Ізоляція перевірок змінює і порядок роботи команд. Споживач фіксує очікування в контракті й перевіряє свою сторону проти нього, постачальник підтверджує, що не ламає зафіксовані очікування.

Деплой стає незалежним: Pact зберігає контракти як артефакт, і розбіжність видно до спільного прогону, а не на спільному стенді.

Контрактні тести не скасовують інтеграційні — вони знімають з них рутинне навантаження. За інтеграційними залишається те, що контрактом не описати: конфігурація середовища, права доступу, поведінка під навантаженням і наскрізні сценарії.

Обмеження підходу та часті технічні сумніви

Споживчі контракти фіксують форму взаємодії — поля, коди відповідей, обов’язкові значення, — але не замінюють перевірки бізнес-логіки, навантажувальні та наскрізні сценарії.

Підтримка контрактів зростає разом із кількістю пар «споживач — постачальник»: без регулярної ревізії кожен із них застаріває, починає хибно червоніти, і команди перестають довіряти перевіркам.

Власник контракту — споживач: він описує те, що реально використовує, а постачальник підтверджує сумісність на своєму боці. Якщо володіння розмите, зміни проходять повз контракт і незалежний деплой підміняється ручними погодженнями. Нижче — заперечення, які найчастіше розбираємо до старту робіт.

Хто власник контракту і що він зобов’язаний робити?

Споживач описує очікування й оновлює їх, постачальник версіонує свою поведінку. У кожного файлу є закріплений власник і строк ревізії: раз на квартал переглядаємо зв’язки, де споживач більше не звертається до поля. Так набір контрактів скорочується, а не зростає безконтрольно.

Чи можна впроваджувати поетапно?

Так, починаємо з однієї критичної пари «споживач — постачальник». Перевірка спочатку працює в режимі спостереження і не блокує збірку, поки розбіжності не розібрано.

Коли звіт стабільний, вмикаємо обов’язковість і розширюємо на інші пари — по одній, зі збереженням можливості швидкого відкату.