Kiedy wstrzymać upgrade Odoo 18→19→20 i jak ocenić ryzyko
Spis modułów, status gałęzi OCA i pomiar czasu migracji OpenUpgrade na kopii produkcyjnej - kryteria decyzji o upgradowaniu Odoo 18→20.
Migracja o wersję główną Odoo rzadko rozbija się o sam rdzeń systemu. Zwykle zawodzi to, co leży obok standardu: repozytoria OCA, dodatki zewnętrznych dostawców i własne rozszerzenia sprzed kilku lat, których autora nie ma już w firmie. Do tego dochodzą skrypty migracji, których nikt nie uruchomił na kopii prawdziwej bazy. Decyzja „migrujemy teraz” albo „czekamy” powinna wynikać z kilku sprawdzalnych pomiarów. Data premiery nowej wersji nie jest jednym z nich.
Skąd bierze się ryzyko migracji
Zmiany w wersji docelowej
Zacznij od release notes wersji, na którą chcesz przejść. Szukasz w nich trzech rzeczy: zmian w API, usuniętych lub przemianowanych pól i nowych modułów standardowych. Ten ostatni punkt łatwo przeoczyć. Jeśli Odoo dodało do standardu funkcję, którą dotąd pokrywał wasz moduł, po migracji możecie mieć dwa mechanizmy robiące to samo, na przykład dwa pola o podobnym znaczeniu na jednym formularzu.
Do notatek dla Odoo 20 podchodzimy ostrożnie. Release notes skupiają się na nowościach dla użytkownika, a zmiany techniczne opisują skrótowo. Brak wpisu o usunięciu modułu nie oznacza, że moduł przetrwał. Dyskusje społeczności, takie jak wątek na Reddicie o usuniętych modułach z listy źródeł, traktuj jako sygnał do sprawdzenia kodu. Nie są potwierdzeniem.
Moduły OCA i zewnętrzne
Spisz wszystkie repozytoria, z których korzysta projekt. Przy każdym module odpowiedz na trzy pytania. Czy jest krytyczny dla procesu biznesowego? Czy ma gałąź dla wersji docelowej? Czy ktoś go aktywnie utrzymuje?
Najgorszy przypadek to moduł krytyczny, bez gałęzi dla nowej wersji i bez maintainera. Wtedy jego przeniesienie spada w całości na was, a termin migracji zależy od tego, ile ta praca potrwa.
Koszt adaptacji
Policz trzy rzeczy: liczbę modułów do przeniesienia, liczbę testów automatycznych, które je pokrywają, i szacowany czas poprawek. Moduł bez testów kosztuje więcej, niż wynika z liczby linii kodu, bo każdą zmianę trzeba sprawdzać ręcznie. Jeśli koszt adaptacji przewyższa to, co daje natychmiastowa migracja, wstrzymanie jest rozsądnym wyborem.
Trzeba też uczciwie przyznać, że dopóki nie uruchomisz migracji na kopii bazy, taki szacunek ma duży margines błędu.
Jak sprawdzić kompatybilność przed migracją produkcji
Runbot i Nightly
Runbot pokazuje stan buildów gałęzi Odoo. Na zbudowanej instancji przeklikasz standardowe procesy w nowej wersji i zobaczysz, czy coś z waszego codziennego obiegu zniknęło albo działa inaczej. Nightly udostępnia paczki budowane co noc, z których postawisz lokalne środowisko testowe.
Oba narzędzia mówią jednak wyłącznie o standardzie. Waszych modułów tam nie ma. Błędy importów i konflikty z rozszerzeniami wyjdą dopiero na waszym środowisku.
OpenUpgrade
OpenUpgrade to repozytorium OCA ze skryptami migracji bazy dla Odoo Community. Migracja idzie wersja po wersji, więc droga z 18 na 20 prowadzi przez 19, a każdy krok sprawdzasz osobno. Najpierw ustal, czy repozytorium obsługuje oba kroki i czy obejmuje moduły, których używacie. Potem:
- uruchom migrację na kopii produkcyjnej bazy, nie na danych demo,
- zapisz każdy krok, który wymagał ręcznej interwencji,
- zmierz czas trwania, bo od niego zależy długość okna migracyjnego.
Własne moduły i testy regresyjne
Każdy moduł przechodzi przez testy jednostkowe i integracyjne, a potem przez ręczne scenariusze z obszarów, w których błąd boli najbardziej: fakturowanie, magazyn, księgowość. Dobry scenariusz to pełna ścieżka, na przykład od zamówienia sprzedaży przez wydanie towaru do zaksięgowanej faktury. Tam, gdzie zmienił się front-end, dochodzą testy interfejsu. Moduł, który nie przechodzi testów i nie ma szybkiej poprawki od autora, trafia na listę ryzyk.
Testy podepnij pod CI, na przykład GitHub Actions, tak żeby uruchamiały się po każdej synchronizacji z gałęziami OCA i upstream. Raport z nocnego przebiegu pokazuje regresje szybciej niż tydzień ręcznego klikania.
Wstrzymanie upgrade'u to też plan
Kiedy ogłosić freeze
Freeze ma sens, gdy krytyczne moduły nie mają kompatybilnych wersji, gdy testy pokazują regresje wymagające długich poprawek albo gdy migracja schematu wymaga zmian strukturalnych w danych. Ogłoś go z konkretną datą i warunkiem odblokowania, na przykład: „wracamy do migracji, gdy wszystkie moduły magazynowe dostaną gałąź dla wersji 19”. Freeze bez kryteriów szybko zamienia się w odkładanie tematu bez końca.
Gałęzie i hotfixy
Model gałęzi musi pozwalać na naprawy produkcji w trakcie prac nad migracją. Wystarczą trzy rodzaje gałęzi: stabilna production, robocza feature/upgrade-20 do adaptacji kodu i krótkie gałęzie hotfix/ na pilne poprawki. Każdy hotfix z produkcji trafia też do gałęzi upgrade. Inaczej po migracji wrócą błędy, które już raz naprawiliście.
# gałąź do prac nad migracją
git checkout -b feature/upgrade-20 production
git merge --no-ff feature/bugfix-compat
# pilna poprawka na produkcję
git checkout production
git merge --no-ff hotfix/critical-fix
# ta sama poprawka w gałęzi migracyjnej
git checkout feature/upgrade-20
git merge --no-ff hotfix/critical-fix
Rollback
Plany migracji często zakładają, że do każdego skryptu powstanie skrypt odwrotny. W Odoo to fikcja. Migracja zmienia schemat i dane w sposób, którego nie da się sensownie cofnąć kodem. Realny rollback to odtworzenie kopii bazy i filestore sprzed migracji oraz powrót do poprzedniej wersji kodu.
Przećwicz go na środowisku testowym i zmierz, ile trwa. Przygotuj też komunikat dla użytkowników na wypadek cofnięcia zmian. Musi jasno mówić, co stanie się z dokumentami wprowadzonymi już po migracji, bo o to zapytają w pierwszej kolejności.
Checklista przed decyzją go/no-go
Audyt modułów
- inwentaryzacja modułów własnych i zewnętrznych,
- status gałęzi OCA dla wersji 19 i 20,
- dostępność skryptów OpenUpgrade dla obu kroków migracji.
Testy i harmonogram
- środowisko testowe z aktualną kopią produkcji,
- lista scenariuszy regresyjnych z podziałem na obszary,
- terminy okien migracyjnych i zarezerwowany czas na rollback.
Kryteria odblokowania
Przykładowy zestaw kryteriów:
- 100% krytycznych scenariuszy przechodzi,
- brak blokujących błędów w standardzie widocznych na Runbot i Nightly,
- poprawki dostępne dla ponad 80% zależności.
Ostatni próg wymaga komentarza. Osiemdziesiąt procent modułów nic nie znaczy, jeśli w brakujących dwudziestu jest moduł od fakturowania. Dlatego moduły krytyczne liczymy osobno i dla nich próg wynosi 100%. Procent ma sens tylko dla pozostałych.
Dokumentacja i komunikacja
Spisz kroki operacyjne migracji w kolejności, w jakiej będą wykonywane, razem z osobą odpowiedzialną za każdy z nich. Użytkownicy powinni wcześniej wiedzieć, kiedy system będzie niedostępny, jakie procesy wstrzymać na czas okna i co się stanie, jeśli trzeba będzie wrócić do starej wersji. Jeśli tej listy nie da się dziś napisać, bo zbyt wiele zależy od modułów bez kompatybilnych wersji, to też jest odpowiedź na pytanie, czy migrować teraz.
Źródła
Chcesz sprawdzić, jak Odoo sprawdziłoby się w Twojej firmie?
Skontaktuj się z nami - przeanalizujemy Twoje obecne procesy i pokażemy, od których 2–3 obszarów warto zacząć, żeby możliwie szybko zobaczyć efekt wdrożenia.