Większość instancji Odoo działa na wersji o jeden albo dwa kroki w tyle, i prawie zawsze z tego samego powodu: aktualizacja wersji Odoo przeraża, więc się ją odkłada. Odłóżcie ją wystarczająco wiele razy, a utkniecie na niewspieranym wydaniu, gdzie każdy kolejny skok jest trudniejszy od poprzedniego. Wyjściem nie jest odwaga - to próba generalna. Oto jak sprawić, by aktualizacja na żywo była tą nudną częścią.

Dlaczego stare wersje się piętrzą

Odoo wypuszcza dużą wersję co roku, a wsparcie dla starszych wydań w końcu wygasa. Każda aktualizacja niesie prawdziwe ryzyko: zmiany schematu, przestarzałe pola i niestandardowe moduły napisane pod starą wersję, które mogą nie przetrwać nowej bez zmian. Ponieważ ryzyko jest realne, a nagroda wydaje się abstrakcyjna („przecież już teraz działa"), aktualizacja zsuwa się na liście priorytetów. Kłopot w tym, że luka się kumuluje. Bycie o jedną wersję w tyle to małe zadanie; bycie o cztery w tyle, na niewspieranym wydaniu z latami nagromadzonych customizacji, to projekt. Bycie na bieżąco jest tańsze niż nadganianie.

Nie można przeskoczyć wersji

Kluczowe, często pomijane ograniczenie: aktualizacje Odoo są sekwencyjne. Nie można skoczyć z 17 prosto na 19. Każda wersja nakłada własne zmiany schematu bazy danych na poprzednią, więc ścieżka to 17 do 18, potem 18 do 19, krok po kroku. Próba pominięcia wersji ryzykuje uszkodzeniem danych i zerwanymi zależnościami. Dlatego aktualizacja wersji Odoo ze starego wydania to łańcuch, nie pojedynczy skok - i dlatego robienie tego ostrożnie, krok po kroku, liczy się tym bardziej, im bardziej jesteście w tyle.

Oceń, zanim czegokolwiek dotkniesz

Bezpieczna aktualizacja zaczyna się od uczciwej oceny, zanim cokolwiek się zmieni. Pytania są konkretne: które zainstalowane moduły mają zmiany łamiące kompatybilność w wersji docelowej? Jakie kształty danych się przesuwają - usunięte pola, zmienione typy, połączone modele? Co w waszej instancji jest standardowym Odoo, a co jest niestandardowe albo zewnętrzne, a więc waszą odpowiedzialnością do zaadaptowania? Celem oceny jest wyniesienie każdej niespodzianki z momentu przełączenia do dokumentu, który możecie przeczytać na spokojnie. Niespodzianka podczas oceny to informacja; niespodzianka podczas przełączenia to incydent.

Ocena to też moment, w którym oddzielacie aktualizację wersji od przeniesienia serwera. Jeśli zmieniacie sprzęt w tym samym czasie, potraktujcie to jako osobną migrację i zróbcie ją przed albo po aktualizacji, nigdy jako jedną ślepą operację.

Przećwicz na jednorazowej kopii

Oto dyscyplina, która zamienia przerażającą aktualizację w rutynową: nigdy nie aktualizujecie najpierw bazy na żywo. Bierzecie jednorazową kopię - pełny klon produkcji, dane i wszystko - i uruchamiacie na niej cały łańcuch aktualizacji. 17 do 18, potem 18 do 19. Community do Enterprise, jeśli to część planu. Przechodzicie przez każdy krok, patrzycie, co się psuje, naprawiacie niestandardowe moduły, które tego wymagają, i powtarzacie od czystej kopii, dopóki cały łańcuch nie jest nieskazitelny.

Dopiero gdy próba generalna jest bezbłędna - czysta aktualizacja, działające moduły, dane nietknięte - planujecie prawdziwe przełączenie. A ponieważ już przeszliście dokładnie tę ścieżkę na prawdziwych danych, przebieg na żywo nie kryje niespodzianek. To ta sama sekwencja, którą właśnie udowodniliście, zastosowana do systemu, na którym zależy. Brama najpierw-podgląd obowiązuje też tutaj: agent pokazuje każdy krok, zanim go uruchomi, więc zatwierdzacie plan, który już widzieliście zakończony sukcesem.

Udowodnione, potem wyrzucone

Przeszliśmy cały łańcuch 17-do-18-do-19 oraz aktualizację edycji Community-do-Enterprise na prawdziwych jednorazowych maszynach, a potem je zniszczyliśmy - więc przepis jest znany, a pułapki spisane, zanim wasze dane w ogóle wejdą w grę. To idealny kształt dla tego typu pracy: ryzykowna nauka dzieje się na jednorazowej infrastrukturze, a zanim dotrze do waszego systemu produkcyjnego, jest już przećwiczoną rutyną. Zrobiona w ten sposób, aktualizacja na żywo jest antyklimatyczna, a dokładnie tak powinna się czuć aktualizacja. Jeśli wolelibyście, żeby agent przeszedł przez to za was, ta funkcja żyje w Zoxron MCP.

Jeszcze jedno warto powiedzieć wprost: bycie na bieżąco to nie zajęcie na pokaz. Każda wspierana wersja dostaje poprawki bezpieczeństwa i łatki błędów, które utrzymują ERP niezawodny, a nowsze wydania niosą prawdziwe usprawnienia, za które już zapłaciliście, jeśli jesteście na Enterprise. Zostawanie w tyle wymienia mały, zaplanowany wysiłek teraz na duży, wymuszony wysiłek później - zwykle w najgorszym momencie, gdy coś w końcu przestaje działać, a aktualizacja staje się pilna zamiast planowana. Przećwiczone aktualizacje to sposób, by ta decyzja zostawała na waszym własnym kalendarzu.

FAQ

Jak bezpiecznie zaktualizować Odoo do nowej wersji?

Najpierw oceńcie - znajdźcie zmiany łamiące kompatybilność i pracę przy niestandardowych modułach - potem przećwiczcie całą aktualizację wersji Odoo na jednorazowej kopii produkcji. Naprawcie, co się psuje na kopii, powtarzajcie, aż łańcuch jest czysty, i dopiero wtedy przełączcie system na żywo. Przebieg na żywo nie powinien kryć niespodzianek, bo już udowodniliście dokładnie tę ścieżkę.

Czy można przeskoczyć wersje Odoo podczas aktualizacji?

Nie. Aktualizacje Odoo są sekwencyjne - 17 do 18 do 19, krok po kroku. Każda wersja nakłada zmiany schematu, które budują na poprzedniej, więc pomijanie ryzykuje uszkodzeniem danych i zerwanymi modułami. Stara instancja jest aktualizowana jako łańcuch pojedynczych kroków, nie jeden skok.

Jak przetestować aktualizację Odoo przed wdrożeniem na żywo?

Sklonujcie produkcję do jednorazowego środowiska i uruchomcie tam całą aktualizację, wliczając wszystkie niestandardowe moduły. Zweryfikujcie dane i procesy na kopii. Gdy ta próba jest nieskazitelna, zaplanujcie prawdziwe przełączenie - kopia jest miejscem, gdzie znajdujecie i naprawiacie problemy, więc baza na żywo nigdy nie staje się eksperymentem.