Behavior contract перед зміною source state

Міграція має зберігати не лише happy-path output. Контракт поведінки охоплює inputs, outputs, errors, side effects, порядок і timing там, де вони спостережувані, idempotency, retries, persistence та recovery behavior.

Контракт не означає, що implementation або внутрішня структура залишаються незмінними. Він визначає, що саме потрібно порівняти між source і target та яке відхилення потребує рішення owner.

Пофазний migration plan

ФазаEvidence gateРішенняRollback/hold
Discoverysource state і scope відтворюваніproceed до analysishold при критичних unknowns
Analysischangelog, graph і matrix мають anchorsобрати pilotзвузити scope або hold
Pilotbounded slice і behavior checksперевірити target hypothesisповернутися до source checkpoint
Verificationfocused + contract checksexpand або reworkrollback при discrepancy
Expand / holdrisk gate і owner decisionзбільшити охоплення або зупинитиdisable/rollback за процедурою
Retirementexit criteria і migration evidenceвидаляти старий path лише після доказівзалишити coexistence

Поля фази, які не можна пропустити

  • одна bounded scope та відповідальний owner;
  • конкретний evidence gate, а не загальне «перевірити»;
  • exit criteria, які можна спостерігати або відтворити;
  • практичний rollback або hold action із відомою точкою повернення;
  • рішення GO, HOLD, narrow або rollback із поясненням і відкритими unknowns.

План не є доказом виконаної міграції

Документований migration plan описує майбутню послідовність та критерії рішень. Він не доводить, що dependencies оновлені, pilot пройшов, production сумісний або rollout завершено. Фактичний результат зʼявляється лише після реальних команд, тестів, review і запису evidence.

Якщо behavior contract неможливо перевірити або compatibility matrix містить blocking Unknown, коректне рішення — HOLD, а не оптимістичне GO.

Канонічне джерело уроку · JavaRush

Відкрити матеріал JavaRush