Novi Odoo modul: bringout_module_version_check — automatska detekcija zaboravljenih nadogradnji

Problem koji rješavamo

U Odoo svijetu postoji jedna tiha klasa grešaka koju vidimo iznova i iznova: programer commituje izmjene u modul, podigne version u __manifest__.py, ali zaboravi pokrenuti -u <modul> na nekoj od produkcijskih instalacija. Kod na disku je nova verzija, baza misli da je stara verzija — sve “radi” dok jednog dana neki view, neka migracija, ili neka cron metoda ne počne padati na način koji niko ne može odmah objasniti.

Ista priča važi i obrnuto: napraviš -u ali zaboraviš commitati version bump. Sljedeći deploy uspješno overpisuje promjene jer Odoo ne vidi razliku u verziji.

Mi smo se sa ovim igrali predugo. Riješili smo ga novim malim modulom.

Šta je bringout_module_version_check

Modul proširuje standardnu ir.module.module tabelu sa dva runtime-computed polja:

  • manifest_version — verzija pročitana uživo iz __manifest__.py na disku, svaki put kad se polje pozove
  • version_mismatch — True kad se latest_version (verzija instalirana u bazi) razlikuje od manifest_version

Pošto su polja compute (a ne store), nema migracija, nema invalidacije keša, nema “stale data” problema. Pitaš — modul ti uvijek odgovori iz trenutnog stanja diska.

Uz to, modul donosi:

  • Filtrirani tree view + meni “Modules Needing Upgrade” unutar Settings → Technical → Modules — odmah vidiš listu modula kojima fali -u
  • JSON-RPC metoda get_version_mismatches (parametar only_bringout filtrira na naše interne module) — programatski callable iz CI/deploy skripti

Integracija u deployment pipeline

Najvažnija stvar — modul nije samo “vidi ga u Odoo UI” alat. Ugrađen je u našu deployment skriptu (odoo_upgrade_lib.py) kao Step 8: Global version self-check.

Tok izgleda ovako:

  1. Razvojni inženjer mijenja kod modula, podiže verziju, commit-uje
  2. Pokreće upgrade_production_nix_<node>.py --modules <imenovaniModul>
  3. Skripta podigne novu zip, deploy-uje preko Colmene, restartuje servis
  4. Step 6 verifikuje da je izričito traženi modul stigao do baze sa tačnom novom verzijom
  5. Step 8 poziva get_version_mismatches preko XML-RPC i pita Odoo: “ima li bilo koji drugi naš modul gdje je verzija u kodu drugačija od verzije u bazi?”

Ako Step 8 pronađe mismatcheve, ispiše tabelu i baci warning. Razlog je jednostavan: deploy je “uspio” za modul koji si tražio, ali si zaboravio pet drugih modula koje si commitao prošle sedmice. Sa Step 8 to nikad ne ostane neprimijećeno.

Module                                       DB           On Disk
--------------------------------------------------------------------------------
⚠️  l10n_ba_some_module                       16.0.1.2.0   16.0.1.3.0
⚠️  l10n_ba_other_module                      16.0.1.0.0   16.0.1.1.0
--------------------------------------------------------------------------------

Nakon ovog warninga, sljedeća akcija je trivijalna: re-run sa proširenom listom --modules. Cijeli ciklus je samostalan, nema “kako sam ja znao da treba nadograditi i taj modul” izgovora.

Zašto se ovo isplati

Imamo više od stotinu lokalnih i OCA modula raspoređenih po više produkcijskih Odoo instalacija. Bez ovog modula svaki deploy je bio “vjeruj da si sve commitao i sve nadogradio”. Sa ovim modulom — Odoo sam kaže “ova lista ti je ostala”. Tri reda Python koda, nula DB izmjena, jedan novi meni, jedna nova XML-RPC metoda — i čitav razred sumnji nestaje.

Ovo je vrsta sitne infrastrukturalne robe koja se isplati u prvoj nedjelji rada. Ne donosi prihod, ne dodaje feature za krajnjeg korisnika — ali svaki put kad bi deploy padao zbog “zaboravljene” nadogradnje, sad ne pada. To je sav novac koji se ne troši na debugging u 23:00.

Tehničke informacije

Napomena

Generisano od strane Claude 🤖

Ernad Husremović, hernad@bring.out.ba