Przepisanie aplikacji Ruby on Rails z MongoDB na PostgreSQL: Lekcje z migracji kodu na żywo i chmury

Gdy nasz klient—dynamicznie rozwijająca się platforma HR i EdTech—zgłosił się do nas, by przemyśleć swoją infrastrukturę, ich aplikacja Ruby on Rails już obsługiwała znaczne obciążenie. To, co zaczęło się skromnie na Heroku, rozrosło się do rozbudowanego systemu hostowanego na AWS, napędzającego codzienną pracę tysięcy nauczycieli, administratorów i uczniów w wielu krajach. Lata rozwoju, przejęć i technicznych improwizacji pozostawiły po sobie kruchy monolit działający na MongoDB. Raportowanie stało się wąskim gardłem. Rozwój spowalniał. A wraz z rosnącym znaczeniem RODO, przejście do europejskiego dostawcy chmury stało się koniecznością.

To historia o tym, jak Selleo pomogło przeprowadzić tę transformację—przepisując warstwę danych, migrując z MongoDB do PostgreSQL i przenosząc infrastrukturę z AWS do Elastisys—wszystko to bez zakłócania działania platformy czy użytkowników. A tutaj znajdziesz więcej historii sukcesu Selleo z wykorzystaniem Ruby on Rails.

Dlaczego PostgreSQL był właściwym wyborem

MongoDB był świetnym wyborem—kiedyś. Jego elastyczność pozwalała na szybkie prototypowanie i błyskawiczne wdrażanie nowych funkcji. Jednak z czasem szybkość bez struktury zaczęła ujawniać swoje słabości. 

Wraz z dojrzewaniem platformy pojawiły się nowe wyzwania:

• Reporting and analytics became core to business intelligence,
• Data relationships grew increasingly complex,
• Regional teams needed consistency and reliability.

PostgreSQL, dzięki integralności transakcyjnej i relacyjnemu schematowi, stał się naturalnym krokiem naprzód. Ale dotarcie tam? To było wyzwanie samo w sobie.

Planowanie migracji bez zakłócania produkcji

To nie była zwykła zmiana bazy danych—była to operacja na otwartym sercu na działającym systemie.

Od pierwszego dnia eksperci Ruby on Rails z Selleo współpracowali z zespołem klienta. Nie tylko pisaliśmy kod—wspólnie projektowaliśmy dalszą drogę. Razem mapowaliśmy ryzyka, identyfikowaliśmy przypadki brzegowe i tworzyliśmy szczegółową mapę drogową. Nie byliśmy cichym dostawcą. Byliśmy partnerami strategicznymi na pierwszej linii.

Nasza praca toczyła się równolegle na dwóch ściśle skoordynowanych torach:

• Data layer rewrite: Moving from Mongoid to ActiveRecord,
• Data migration orchestration: Supporting the client’s external consultant during the live migration from MongoDB to PostgreSQL,
• Infrastructure transition: From AWS to GDPR-compliant Elastisys.

Każdy kamień milowy był wspólnie określany, priorytetyzowany i poddawany przeglądom. Każda zmiana przechodziła przez transparentne, asynchroniczne workflowy. Pętle feedbacku były krótkie. Niespodzianek było niewiele.

Przepisywanie warstwy danych, model po modelu

Kod legacy ma tendencję do gromadzenia chaosu. Modele Mongoid z dokumentami osadzonymi. Inne z dynamicznymi atrybutami. Żaden z nich nie pasował idealnie do SQL. Dlatego zwolniliśmy tempo.

Zaczęliśmy od wyodrębnienia kluczowych encji—użytkowników, zadań, klientów. Dla każdej z nich zbudowaliśmy czyste odpowiedniki w ActiveRecord. Przepisaliśmy scope'y, zadania w tle i interfejsy API. Co najważniejsze, zachowaliśmy sygnatury metod, by frontend pozostał nietknięty. Wspólnie rozwiązywaliśmy trudniejsze fragmenty. Dokładnie przeglądane. I zakotwiczyliśmy cały proces w solidnym pokryciu testami — uruchamiając zarówno walidacje MongoDB, jak i Postgresa równolegle.

Dwie bazy danych — i spokojny sen w nocy

Ostatecznie mieliśmy dwie wersje aplikacji na środowisku staging: starszą, opartą na MongoDB, oraz nową, zbudowaną na PostgreSQL. Zduplikowaliśmy klientów frontendowych, aby QA mogło przeprowadzić testy A/B i porównać zachowanie danych w obu systemach.

Przygotowaliśmy skrypty audytowe. Porównywaliśmy identyfikatory, stany, znaczniki czasu. Wychwytywaliśmy przypadki brzegowe, zanim stały się problemem na produkcji. Odpowiedzialność za integralność danych była po naszej stronie — śledziliśmy anomalie i wykrywaliśmy je wcześnie. Gdy testy potwierdziły, że wszystkie blokery zostały usunięte, skoordynowaliśmy działania ze wszystkimi zespołami i interesariuszami, aby dać zielone światło na wdrożenie produkcyjne. Zaplanowaliśmy uruchomienie na spokojny weekend, zbieżny ze świętami publicznymi w kluczowych regionach klienta. Ten margines zrobił różnicę.

Od AWS do Elastisys: strategiczna zmiana infrastruktury

Chociaż migracją infrastruktury kierowali zewnętrzni partnerzy klienta, Selleo było blisko. Jako wcześniejsi architekci ich środowiska AWS, doradzaliśmy w zakresie praktyk DevOps, przeglądaliśmy plany migracji i pomagaliśmy dostosować nowy stack do wymagań zgodności i operacyjnych.

Przejście do Elastisys — europejskiego dostawcy zgodnego z RODO— nie było tylko technicznym zwrotem. To była decyzja strategiczna. Klient zyskał przejrzyste rozliczenia, suwerenność danych i długoterminowy spokój. Pipeline’y CI/CD zostały przepisane. Wbudowano obserwowalność. Nowa infrastruktura była nie tylko zgodna z przepisami —była gotowa na skalowanie.

Weekend wdrożenia: historia cichego sukcesu

Było cicho. Za cicho. Podczas ostatniego weekendu migracji uruchomiliśmy skrypt konwersji danych produkcyjnych. Przełączyliśmy połączenie z bazą danych. Wyłączyliśmy logowanie poza wybranymi kontami testowymi. Przeprowadziliśmy ręczne testy smoke na wszystkich krytycznych ścieżkach. Gdy wszystko się zgadzało, otworzyliśmy bramy.

W poniedziałek rano użytkownicy logowali się jak zwykle. Te same procesy, te same funkcje. Ale pod maską wszystko było inne.

Wnioski, które wyciągnęliśmy

Trudno pojąć pełną skalę migracji, dopóki nie znajdziesz się w jej środku — żyjąc każdym ograniczeniem, każdą decyzją, każdą niewiadomą. Niektóre rzeczy stają się jasne dopiero po przejściu przez taką migrację:

• Don’t touch the data until your app logic is airtight,
• Test staging like it’s production—because it might as well be,
• Treat infrastructure migration as its own standalone project,
• Write logs like your future self will depend on them (they will),
• Great migrations begin with collaboration, not just code.

Planujesz własną migrację?

Niezależnie od tego, czy zastępujesz MongoDB, przenosisz monolit Rails, czy migrujesz ze względu na zgodność — nie musisz robić tego sam.

W Selleo pomagamy firmom przechodzić przez kluczowe migracje bez zbędnych emocji. Nasze zespoły Ruby on Rails piszą czysty kod, biorą odpowiedzialność za dostarczane rezultaty i głęboko wchodzą w Twój kontekst. Przewidujemy. Planujemy. Dbamy, byś nie działał po omacku.

Od refaktoryzacji baz danych po migracje do chmury — robiliśmy to, wspieraliśmy i zapewnialiśmy trwałość zmian.