Een upgrade breekt maatwerk omdat Odoo zijn eigen code en data migreert, niet die van jou. Upgradeveilig bouwen komt neer op dicht bij standaard blijven, maatwerk afgebakend houden, en elke upgrade op een stagingkopie testen voordat hij productie raakt.
Je hebt in het weekend van Odoo 17 naar 18 geüpgraded. Maandagochtend is een Studio-veld weg, vuurt een automatiseringsregel op het verkeerde record, is je maatwerk-factuurlay-out leeg, en gooit de websitepagina die vrijdag nog werkte nu een foutmelding. Niemand heeft iets aangeraakt. De upgrade wel.
Dit is de meest voorkomende reden waarom teams jarenlang op een oude versie blijven hangen: de laatste upgrade deed pijn, dus wagen ze er nooit meer een. Maar de breuk is niet willekeurig, en hij is grotendeels te voorkomen. Hier is waarom een upgrade maatwerk breekt, en hoe je bouwt zodat de volgende dat niet doet.
Waarom een upgrade je maatwerk breekt
Een upgrade doet twee dingen tegelijk. Hij migreert je data naar de nieuwe versie, en hij laadt nieuwe versies van elke module. Standaard-Odoo wordt voor je gemigreerd door de upgradeservice van Odoo. Jouw maatwerk niet, omdat Odoo niet weet wat erin zit.
Daar, in die kloof, breken dingen:
Studio-aanpassingen liggen bovenop standaardweergaven. Als de nieuwe versie een veld verplaatst, hernoemt of een scherm herbouwt, wijst jouw Studio-aanpassing naar iets dat niet meer bestaat. De weergave laadt niet of je veld verdwijnt stilletjes.
Automatiseringsregels en serveracties verwijzen naar velden, modellen en triggers. Als een veld wordt verwijderd of een trigger zich tussen versies anders gedraagt, draait de regel nog steeds, maar op de verkeerde aanname. In het ergste geval vuurt hij op elk record in plaats van op één.
Maatwerkmodules zijn code die tegen de API van een specifieke versie is geschreven. Methodenamen, velddefinities en view-overerving veranderen tussen versies. Code die op 17 werkte, kan op 18 een foutmelding geven omdat datgene wat hij aanriep is hernoemd of verwijderd.
Website- en e-maillay-outs erven van standaardtemplates. Als de standaardtemplate verandert, kan jouw override op de verkeerde plek belanden, leeg blijven of de pagina breken.
Er is ook een cascade-effect. Modules zijn van elkaar afhankelijk. Upgrade er één en Odoo upgradet alles waar hij van afhangt, wat veranderingen kan meebrengen die je niet had gepland. En de deprecation-waarschuwing die je twee versies lang negeerde ("deze methode wordt verwijderd") wordt een harde fout op het moment dat de methode daadwerkelijk wordt verwijderd.
De oplossing is dicht bij standaard bouwen en elke upgrade eerst testen
Je kunt Odoo niet tegenhouden om te veranderen. Je kunt wel veranderen hoeveel van je setup van die veranderingen afhangt. Twee principes doen het meeste werk: bouw dicht bij standaard, en upgrade productie nooit blind.
Bouw zo dicht bij standaard als je kunt.
Elke maatwerkaanpassing is een belofte om hem voor altijd te onderhouden. Vraag je voordat je bouwt af of standaard-Odoo dit al doet, of bijna doet. Een configuratie-instelling, een andere workflow, of de manier van Odoo accepteren is gratis bij een upgrade. Een maatwerkmodule niet. Hoe minder je bovenop standaard zit, hoe minder een upgrade kan breken. In onze eigen projecten gaan we hierin nog een stap verder: we grijpen nooit in in de flow van Odoo, we voeden hem. In plaats van maatwerklogica die voorraad over magazijnen verdeelt, berekenen we het minimum en maximum op de standaard bestelpunten en schrijven we die waarden weg. Odoo doet de verdeling dan zelf, zoals altijd, en de upgrade heeft niets van ons om te breken.
Houd maatwerk schoon en afgebakend.
Als je toch maatwerkcode nodig hebt, stop hem dan in nette modules, niet in verspreide Studio-aanpassingen en eenmalige automatiseringsregels door de hele database. Een veld dat in een geversioneerde module is gedefinieerd, is iets wat een developer kan repareren en testen. Een Studio-veld dat met de hand in productie is toegevoegd, is iets wat niemand documenteerde en wat de upgrade niet begrijpt. Erf standaardweergaven en -modellen op de ondersteunde manier over, zodat je aanpassingen er netjes overheen liggen in plaats van kernschermen te vervangen.
Neem deprecation-waarschuwingen serieus.
Wanneer een log zegt dat een methode of veld deprecated is, is dat je enige waarschuwing. Repareer het op de huidige versie terwijl alles nog werkt. Als je wacht, houdt het op een waarschuwing te zijn en wordt het een kapot scherm op de dag dat je upgradet.
Test de upgrade eerst op een stagingkopie.
Dit is de stap die de maandagochtendverrassing voorkomt. Maak een volledige kopie van je productiedatabase, draai de upgrade op die kopie, en controleer alles: je Studio-schermen, je automatiseringsregels, je maatwerkmodules, je websitepagina's, je rapporten. Je vindt de breuk op een veilige plek, repareert hem, en pas dan raak je productie aan. Staging bestaat zodat je dingen kunt breken zonder gevolgen.
Los op staging op, rol dan uit.
Werk de kapotte items op de stagingkopie door totdat de geüpgradede database schoon is. Pas de maatwerkmodules aan de nieuwe API aan, herricht of herbouw de Studio-aanpassingen, hertest de automatiseringsregels. Wanneer staging een echte run met echte data doorstaat, rol je dezelfde upgrade naar productie uit met vertrouwen, niet met hoop.
Het stuk waar mensen over struikelen
Een paar dingen overkomen vrijwel iedereen
Een stagingtest op lege of voorbeelddata bewijst niets. De breuk zit in je echte maatwerk en je echte data. Test op een echte kopie van productie, niet op een verse demodatabase.
Studio-aanpassingen zijn het stille risico. Ze voelen als configuratie, dus mensen vergeten dat ze bestaan, en zijn dan verbaasd als een upgrade ze laat vallen. Behandel elke Studio-aanpassing als maatwerk dat getest moet worden.
De cascade is groter dan je denkt. Eén module upgraden kan afhankelijke modules meetrekken. Test de hele database na een upgrade, niet alleen de delen waarvan je denkt dat je ze hebt veranderd.
"Het werkte in de upgrade-preview" is niet hetzelfde als "het werkt". De upgradeservice van Odoo migreert standaardmodules en geeft je een testdatabase. Het lost je maatwerkcode niet op. De maatwerkkant is jouw verantwoordelijkheid, elke keer weer.
Snelle checklist
- Je bouwt dicht bij standaard en behandelt elke maatwerkaanpassing als iets dat je moet onderhouden.
- Maatwerkcode leeft in nette, geversioneerde modules, niet in losse Studio-aanpassingen en ad-hocregels.
- Standaardweergaven en -modellen worden op de ondersteunde manier overgeërfd, niet vervangen.
- Je handelt naar deprecation-waarschuwingen op de huidige versie, voordat ze fouten worden.
- Elke upgrade draait eerst op een volledige kopie van productie, met echte data.
- Je test Studio, automatisering, maatwerkmodules, website en rapporten op staging voordat je uitrolt.
FAQ
Waarom brak mijn Odoo-upgrade mijn Studio-maatwerk?
Omdat Studio-aanpassingen bovenop standaardweergaven liggen, en de upgrade die weergaven eronder heeft veranderd. Wanneer een veld wordt verplaatst, hernoemd, of een scherm in de nieuwe versie wordt herbouwd, wijst jouw Studio-aanpassing naar iets dat niet meer bestaat, dus laadt hij niet of verdwijnt hij. Odoo migreert standaardmodules voor je, maar niet je maatwerk.
Migreert Odoo maatwerkmodules automatisch tijdens een upgrade?
Nee. De upgradeservice van Odoo migreert standaard-Odoo-data en -modules. Maatwerkmodules zijn code die tegen de API van een specifieke versie is geschreven, en ze aanpassen aan de nieuwe versie is jouw verantwoordelijkheid. Test ze op een stagingkopie en repareer de breuk voordat je productie upgradet.
Hoe test ik een Odoo-upgrade veilig?
Maak een volledige kopie van je productiedatabase, draai de upgrade op die kopie, en controleer je Studio-schermen, automatiseringsregels, maatwerkmodules, websitepagina's en rapporten. Repareer alles wat op de kopie breekt. Rol pas naar productie uit als de stagingrun slaagt met echte data. Upgrade productie nooit blind.
Wat betekent "upgradeveilig" in Odoo?
Het betekent dat je setup zo dicht mogelijk bij standaard blijft, dat je maatwerk in nette geversioneerde modules leeft in plaats van verspreide Studio-aanpassingen, dat je standaardweergaven op de ondersteunde manier overerft, en dat je vroeg naar deprecation-waarschuwingen handelt. Hoe dichter je bij standaard zit, hoe minder een upgrade kan breken, en hoe sneller elke upgrade verloopt.