Modernizacja platformy SaaS — od serwera aplikacyjnego sprzed dekady do pełnego DevOps

Punkt wyjścia

Platforma udostępnia dane o pojazdach przez API i panel klienta. Jej rdzeń działał na serwerze aplikacyjnym, którego ostatnia wersja ukazała się kilkanaście lat temu. Budowa i wdrożenie były ręczne: kompilacja „ad hoc”, kopiowanie artefaktów, restart. Każda zmiana wymagała osoby, która pamiętała, jak to zrobić — i odwagi.

Co zrobiliśmy

Modernizacja rdzenia bez zatrzymywania biznesu. Usługę przepisaliśmy na Spring Boot, zachowując wszystkie istniejące protokoły (REST i SOAP) oraz cztery mechanizmy uwierzytelniania używane przez klientów. Zanim przełączyliśmy pierwszego klienta, zbudowaliśmy testy porównawcze: te same żądania trafiały do starego i nowego systemu na wspólnej bazie, a wyniki — odpowiedzi, rozliczenia, stan bazy — były porównywane automatycznie. Ruch przełączaliśmy stopniowo, przez wydanie canary, z możliwością natychmiastowego powrotu.

Nowe interfejsy. Nowy panel klienta (Next.js, GraphQL) z kontem, płatnościami, uwierzytelnianiem OAuth2 i MFA. Nowy panel administracyjny, który stał się jedynym miejscem pracy zespołu: obsługa klientów, system kuponów, raporty, a później także zadania procesów BPM.

Integracje. Kilku zewnętrznych dostawców danych z mechanizmem przełączania awaryjnego, CRM i system księgowy połączone przez Apache Camel, procesy biznesowe w silniku BPM.

Pełny DevOps. Każde repozytorium ma pipeline: build, testy, obraz, wdrożenie. Cztery środowiska — test, beta, canary i produkcja — działają na klastrze Kubernetes, który zbudowaliśmy i utrzymujemy na własnym sprzęcie. Certyfikaty, DNS i monitoring są zautomatyzowane.

Praca z agentami AI. Modernizację prowadzimy z agentami AI jako stałą częścią warsztatu. W głównej usłudze liczba testów wzrosła od zera do ponad dwustu, a dokumentacja techniczna — od zera do kilkudziesięciu dokumentów, w tym planów migracji i opisów decyzji architektonicznych.

Efekt

• Wdrożenie zmiany to dziś minuty i jeden pipeline, a nie dzień pracy.
• Nowe usługi trafiają na produkcję w dniach — np. silnik procesów BPM w cztery dni od pierwszego commita.
• Stary i nowy system działały równolegle do momentu, w którym testy porównawcze potwierdziły zgodność. Klienci nie musieli niczego zmieniać po swojej stronie.