Odoo.sh dla partnerów: dev, staging i produkcja bez psucia czegokolwiek klientowi

Zasada, która oszczędza większość nieprzyjemnych niespodzianek w Odoo.sh, mieści się w jednym zdaniu: nic nie trafia na produkcję bez zielonego builda na prawdziwej kopii bazy klienta, z tym samym commitem, który ma zostać scalony. Dokumentacja wyjaśnia platformę, nie przepływ pracy partnera. Oto nasz.

Trzy etapy i co każdy z nich naprawdę robi

Odoo.sh ma trzy etapy: produkcję (tylko jedna gałąź), staging i development. Różnica polega na tym, od jakiej bazy startuje każdy build:

• Development: nowa baza z danymi demo, instaluje moduły z gałęzi i uruchamia testy; trwa około trzech dni. To jedyny etap, który testuje: testy zależą od danych demo.
• Staging: build duplikuje bazę produkcyjną i ją neutralizuje. Kopia jest usuwana po miesiącu.
• Produkcja: push restartuje serwer; jeśli podniesiesz wersję modułu w __manifest__.py, uruchamia update (odpowiednik -u), a instancja przechodzi w tryb konserwacji. Jeśli się nie powiedzie, wraca do poprzedniej rewizji i przywraca bazę.

Stąd wniosek, którego prawie nikt nie czyta: scalanie przenosi kod, nigdy tego, co ręcznie zmieniłeś w bazie stagingu. To, co ma dotrzeć na produkcję, musi być w XML modułu, z podniesioną wersją.

Struktura gałęzi dla partnera

Przy jednym kliencie wystarczą dev, staging i produkcja. Przy kilku: jedna gałąź developmentu na zadanie; jedna gałąź stagingu na klienta i dostawę, przebudowywana przed każdą walidacją; jedyna gałąź produkcyjna, którą narzuca Odoo.sh; a jeśli moduł trafia do App Store, po jednej na wersję Odoo.

W naszym repozytorium jest dziś 144 gałęzi, w tym 17.0, 18.0, 19.0 i production: 41 ma sufiks -17, -18 lub -19 (jeden konektor, jedna wersja), a 19 to production-pre-<cambio>-<fecha>: commit, który działał na produkcji przed każdym delikatnym wdrożeniem. Powrót do poprzedniego stanu to jeden push.

Build jako bramka: co sprawdza, a czego nie

Build jest zielony (bez błędów i ostrzeżeń), żółty (ostrzeżenia) lub czerwony (błędy); dostarcza się tylko zielony. Build developmentu sprawdza, czy moduły z gałęzi instalują się na czystej bazie z danymi demo i czy ich testy przechodzą. Czego nie sprawdza:

• Modułów spoza gałęzi. Domyślnie instaluje tylko Twoje, bez podmodułów. W ustawieniach: pełna instalacja (podmoduły i wszystkie standardowe, ale bez testów) albo lista nazw technicznych oddzielonych przecinkami, która jest tą przydatną.
• Upgrade'u. Instaluje od zera; nigdy nie uruchamia -u na bazie z historią.
• Prawdziwych danych. To rola stagingu, który nie uruchamia testów.

Dlatego bramka ma dwa skrzydła: build developmentu uruchamia testy, które instalują, nie tylko jednostkowe; a gałąź stagingu wykonuje prawdziwy upgrade na kopii produkcji, czytając update.log do samego końca. Zwróć uwagę na linię 0 failed, 0 error(s) of N tests z N większym od zera: zielony build z zerem testów jest pusty. Więcej przyczyn w artykule moduł Odoo 19 się kompiluje, ale nie instaluje.

Staging z danymi: co rozwiązuje kopia, a co nie

Neutralizacja rozwiązuje to, co niebezpieczne: nie wychodzą e-maile (widać je w zakładce Mails), nie działają zaplanowane akcje, usługi IAP są wyłączone, przewoźnicy i bramki płatności działają w trybie testowym, a neutralize.log mówi, co zostało wyłączone. Czego nie rozwiązuje:

• Anonimizacja nadal należy do Ciebie. Wyłącza procesy, ale nie usuwa danych osobowych. Jeśli zespół nie powinien widzieć danych klienta: Developer nie ma dostępu ani do stagingu, ani do produkcji, Tester ma dostęp do stagingu, a tylko Admin do produkcji.
• Poświadczenia zewnętrznych API podróżują razem z kopią. Konektor na stagingu z kluczami produkcyjnymi rozmawia z Amazon lub Mirakl tak, jakby był produkcją: włącz jego tryb sandbox albo wyczyść klucze.
• Baza stagingu nie odświeża się sama. Domyślnie gałąź aktualizuje poprzedni build, a baza przetrwa między pushami, z już zmienionymi danymi; z New build każdy push startuje od świeżej kopii. Crony uruchamia się ręcznie, a ręczne backupy trwają trzy dni, z limitem pięciu dziennie.

SSH i psql na produkcji: czego się dotyka, a czego nie

Odoo.sh daje powłokę na produkcji. Wchodzimy, żeby czytać (psql, lnav ~/logs/odoo.log), diagnozować za pomocą odoo-bin shell i uruchamiać zestaw testów modułu w trybie transakcyjnym. Czego się nie robi: ręcznego UPDATE ani instalowania modułów z pominięciem builda. Szczegóły, które kosztują popołudnie: scp i sftp są zablokowane, rola Postgresa nie może tworzyć baz, a własne moduły znajdują się w ~/src/user. Ulga: odoo-bin shell robi rollback przy wyjściu w wersjach 17, 18 i 19 (odoo/cli/shell.py).

Upgrade na produkcji: noupdate, base.group_system i migracje

Upgrade uruchamia się przez podniesienie wersji w manifeście; Odoo.sh robi backup oznaczony jako Update (także gdy zmienia się requirements.txt) i wykonuje -u. Tu kryje się najdroższa pułapka, jaką mieliśmy. Zwykły idiom, aby administrator odziedziczył Twoją grupę, wygląda tak:

<record id="base.group_system" model="res.groups">
    <field name="implied_ids" eval="[(4, ref('group_mi_manager'))]"/>
</record>

Działa na nowej instalacji, a przy upgradzie jest po cichu ignorowany. Powód leży w bazie klienta: noupdate znajduje się w wierszu ir_model_data. Przy aktualizacji loader przepisuje tylko rekord if not (update and d_noupdate) (odoo/orm/models.py w wersji 19, odoo/models.py w 17 i 18), a upsert utrzymujący tę tabelę odświeża model i res_id, ale nigdy kolumnę noupdate: raz ustawiona, nie znika. I nie da się tego wywnioskować z addonu: we wszystkich trzech wersjach rekord base.group_system znajduje się w <data> bez noupdate i mimo to może przyjść oznaczony:

select name, noupdate from ir_model_data
 where module='base' and name in ('group_system','group_user');

W naszej produkcji na Odoo.sh zwraca t w obu; w 69 bazach, które nasze środowisko testowe utworzyło od zera, group_user wychodzi t, a group_system wychodzi f. Ten sam XML, dwa wyniki.

Przydarzyło się nam to w naszym konektorze Mirakl 16.15.0: poświadczenia przeniesiono do grupy „Mirakl Manager”. Na nowych instalacjach administrator ją dziedziczył; na zaktualizowanych została bez członków i nikt nie mógł ruszać kluczy. Testy były zielone, bo czysta instalacja stosuje rekord. Poprawka w 16.15.1: zostawić XML i dodać migrations/19.0.16.15.1/post-migrate.py, które zapisuje implikację w SQL w res_groups_implied_rel i res_groups_users_rel z ON CONFLICT DO NOTHING, plus test, który zawodzi, jeśli grupa zostaje pusta.

Migracje: katalog migrations/<versión>/ z plikami pre-*.py, post-*.py i end-*.py, każdy z migrate(cr, version), gdzie version to wersja, która była zainstalowana. Odoo uruchamia je tylko wtedy, gdy moduł jest oznaczony do aktualizacji: na nowej instalacji nie działa żadna, dlatego XML jest potrzebny. Jeśli zmienia się wersja główna, proces jest inny: błędy migracji do Odoo 19 i checklista go-live.

Pułapki, których nie ma w dokumentacji

• Buildy, które zasypiają. Nieużywany build developmentu przechodzi w hibernację, a jego crony nie działają. Jeśli używasz go jako środowiska testowego, utrzymuj go w stanie czuwania: mamy agenta launchd, który co 240 sekund wykonuje curl /web/health i ssh -n … true na każdym buildzie.
• Build, który walidujesz, może być starym. Identyfikator zmienia się przy każdym pushu, a poprzedni jest recyklingowany z opóźnieniem: przez SSH współistnieją dwa. Zanim cokolwiek uznasz za dobre, zrób grep tego, co właśnie zmieniłeś, w ~/src/user.
• Seria w manifeście zawodzi inaczej w każdym kierunku. W wersji 19 manifest 18.0.x lub 17.0.x nie wybucha: serwer ostrzega has an incompatible version, setting installable=False. W drugą stronę, w wersji 17 lub 18, 19.0.x.y.z przerywa odczyt z invalid manifest.

Checklista dostawy do klienta

1. Zielony build (nie żółty) w developmencie, z testami, które instalują, i N większym od zera.
2. Staging przebudowany dziś z produkcji; zewnętrzne poświadczenia w sandboksie lub puste.
3. Podniesiona wersja w manifeście i update.log przeczytany do końca, łącznie z migracjami.
4. Walidacja klienta na stagingu, z cronami uruchamianymi ręcznie i e-mailami sprawdzonymi w Mails.
5. Gałąź production-pre-<cambio>-<fecha> z commita, który działa na produkcji, oraz ręczny backup, jeśli zmiana dotyka danych.
6. Scalanie poza godzinami szczytu, a potem odoo.log, grupa uprawnień z członkami i aktywne crony.

Ten przepływ oferujemy jako inżynierię Odoo dla firm konsultingowych i stosujemy go przy każdym wdrożeniu i migracji do Odoo 19. Jeśli jesteś partnerem lub software house'em, program partnerów technologicznych wyjaśnia, jak pracujemy.

Jeśli prowadzisz ecommerce

Ruszanie konektora marketplace lub reguły zapasów na produkcji to zabawa prawdziwymi zamówieniami: zduplikowane etykiety, zamówienia zaimportowane dwa razy, synchronizacje wykonane w połowie. Przez staging przechodzą nowe moduły, zmiany zapasów i aktualizacje konektorów (Amazon, Mirakl, ManoMano, SEUR, MRW, Correos Express), a tam przewoźnicy i bramki płatności działają w trybie testowym: tam sprawdzisz etykietę bez wyjazdu furgonetki.

Najczęstsze pytania

Przydatne linki w FlexigoTech

Co robimy w tym obszarze