Nástroj spring-boot-migrator: automatizovaná migrácia po overiteľných krokoch – OpenRewrite zvládne mechanickú prácu, AI vyrieši zvyšok a o výsledku rozhodujú testy, nie dojem. Všetko nižšie sú namerané výsledky z reálnych behov, nie sľuby.

Namerané, nie sľúbené
1 · Motivácia
Problém: flotila približne 100 vzájomne previazaných aplikácií na Spring Boot 2. Tá je dávno po konci podpory (bez bezpečnostných záplat) a každý ďalší rok technologický dlh prehlbuje – manuálna migrácia jednej aplikácie cez štyri hlavné verzie (2.x → 2.7 → 3.0 → 3.5 → 4.0 vrátane premenovania javax → jakarta) pritom typicky viaže skúseného vývojára na dni až týždne. Pri stovke aplikácií sa to násobí.
1 · Motivácia
Jazykový model vie kód prepísať, ale nezaručí, že sa aplikácia bude správať rovnako. Preto je nástroj postavený opačne – AI nikdy nerozhoduje o úspechu. Rozhodujú tri nezávislé brány: build a unit testy, charakterizačná sada curl testov (zaznamenané správanie pôvodnej verzie ako záväzný kontrakt) a code/security review.
AI je motor, brány sú volant a brzdy.
Pred migráciou sa z kódu vygenerujú curl testy a na bežiacej starej verzii sa nahrá „golden master“ – presné odpovede API. Po každom kroku migrácie musí nová verzia odpovedať identicky. Zmena správania sa tak zachytí pri kroku, ktorý ju spôsobil, nie až v produkcii.
2 · Z čoho sa skladá
/spring-migrate – migrácia jednej aplikácie (na interné závislosti sa interaktívne pýta). /spring-fleet – plán vĺn z grafu závislostí a prehľadová tabuľka stavu flotily.Pod kapotou: OpenRewrite (deterministické prepisy kódu, open-source od Moderne), Claude Code (Anthropic) ako AI agent a štandardné nástroje Maven/Gradle. Git je jediný zdroj pravdy – jeden krok = jeden commit.
3 · Ako sa spúšťa a čo potrebuje
# inštalácia (raz)
/plugin marketplace add mjancik404/test-workflows
/plugin install spring-boot-migrator@test-workflows
# migrácia – nástroj sa sám pýta na interné závislosti a poradie
/spring-migrate <git-repo> [--fleet <adresár-flotily>]
# flotila: plán vĺn podľa závislostí a stav
/spring-fleet plan <adresár> · /spring-fleet status <adresár>
3 · Ako sa spúšťa a čo potrebuje
4 · Princíp behu
Nástroj pracuje v slučke s tvrdo vynútenými bránami. Na pôvodnej verzii si najprv vytvorí merateľný kontrakt správania (sadu curl testov so zaznamenanými odpoveďami a kontrolou pokrytia), potom aplikáciu posúva po jednej hlavnej verzii. Po každom kroku musí prejsť všetkými bránami: build a unit testy, zhoda správania s golden master a cielené review. Ak niektorá brána zlyhá, AI hľadá príčinu – najprv v znalostnej báze známych pascí – a opravuje aplikáciu, nikdy testy. Výsledkom každého kroku je commit s uloženým dôkazom, výsledkom celého behu report a retrospektíva, ktorá poznatky vráti do znalostnej bázy pre ďalšie aplikácie.
4 · Princíp behu
Migračná slučka vrátane spätnej väzby: poznatky z každého behu zrýchľujú ďalšie aplikácie. Červená brána = stop; opravuje sa aplikácia, nikdy testy.
4 · Princíp behu
Pri kroku na Spring Boot 4 sada testov spadla 7/8: Boot 4 potichu zmenil predvolenú hodnotu a /actuator/health začal vracať iné telo odpovede. Build zelený, unit testy zelené – videla to len charakterizačná sada. Nástroj príčinu sám dohľadal v metadátach frameworku a opravil ju jedným riadkom. Presne tento typ tichých zmien správania je dôvod, prečo brány existujú.
5 · Výsledok + git + review
| Krok | OpenRewrite recept | Manuálne zásahy | Brány |
|---|---|---|---|
| 2.6.15 → 2.7.18 | UpgradeSpringBoot_2_7 | 0 | curl 8/8 |
| 2.7.18 → 3.0.13 | UpgradeSpringBoot_3_0 (javax→jakarta) | 0 | curl 8/8 |
| 3.0.13 → 3.5.16 | UpgradeSpringBoot_3_5 | 0 | curl 8/8 |
| 3.5.16 → 4.0.7 | UpgradeSpringBoot_4_0 | 1 riadok | curl 8/8 |
6 · Náklady a úspory
7 · Výhody · Nevýhody · Riziká
6 · Náklady a úspory
3–5 aplikácií rôznej zložitosti. Merať: čas behu, ľudský čas (review a zásahy), náklady na AI, počet nálezov review, paritu sady testov. Po pilote reálna kalkulácia na celú flotilu – čísla budú vaše, nie naše odhady.
