A la
nostra reunió semestral del mes de desembre l’equip de Coopdevs,
vam abordar l’estratègia que volem prendre pel que fa a les
migracions d'Odoo aquest any 2024 i en el futur. Atès que la major
part de les instàncies d’Odoo dels nostres clients estan ara a la
versió 12 i Odoo SA ha llançat ja la versió 17 no podíem esperar
més per a fer-ho. En aquest article intentem explicar tots els
aspectes que hem valorat per a poder definir la nostra estratègia
que expliquem al final i està basat en el que els nostres companys
de CoopItEasy explien al seu blog .
Què suposa migrar una instància d'Odoo?
Migrar una instància d’Odoo no suposa només fer una actualització de programari, com podem fer al nostre ordinador o dispositiu mòbil, ja que cada instància d’Odoo és diferent una de l’altra. També cal tenir en compte que cal migrar tant el codi com la base de dades.
Pel que fa al codi cada instancia d’Odoo dels nostres clients és diferent perquè incorpora:
- Una col·lecció variable dels mòduls del nucli d’Odoo que publica Odoo SA,
- Una col·lecció variable de mòduls desenvolupats i suportats per la comunitat de la OCA
- En la majoria de casos, mòduls personalitzats (codificats) per Coopdevs per a satisfer requeriments particulars com adaptacions en factures, modificacions en un formulari…
Quan abordem una migració cal avaluar cada mòdul instal·lat a la instància per a assegurar-se que tots estiguin disponibles en la versió de destí. De no ser així, cal investigar si els els processos que aquell mòdul cobria es fan amb un nou mòdul ja disponible o hi ha pendent la migració del codi del mòdul. Aquesta part té un cost en hores molt elevat, ja que cal anar a revisar cada mòdul, investigar la documentació de migració per saber en quin estat està la migració que estigui fent la comunitat i, en el cas de que calgui, col·laborar en aquesta tasca.
Pel que respecta a la base de dades, els canvis al codi en els salts de versió acostumen a tenir impacte en l'estructura de les dades i cal disposar de fitxers «script» que permetin migrar les taules de dades d'una versió a una altra, per a que s’adaptin al nou codi.
Tot i la variabilitat de cada instància, hi ha una part de la feina que suposa una migració que és comuna a totes les instàncies, però hi ha una altra part que es específica de cada cas.
Perquè migrar?
Els motius que ens empenyen a seguir el ritme de migració impulsat per Odoo S.A., l'editor del programari Odoo, estan fortament lligats a la qualitat del servei que oferim i a la nostra capacitat de treballar de manera eficient.
Concretament, quins són els avantatges?
- La migració us permet aprofitar les actualitzacions de seguretat, sense les quals no podem garantir el nivell de protecció necessari per a les dades allotjades.
- La migració també facilita el manteniment del servidor.
- La migració permet acoblar-se amb la comunitat OCA de forma que podem compartir millor esforços i sinergies, més funcionalitats i, per tant, una reducció de costos.
- Finalment, la migració també permet accedir a millores i noves funcions disponibles a les versions recents d'Odoo.
- A banda d'aquests motius, ens cal limitar el nombre de versions d'Odoo en les que què treballem a l’hora. Volem "sincronitzar" les bases de dades que allotgem perquè canviïn de versió en una sola onada, en cas contrari el treball de migració és molt complicat d'organitzar i finançar.
En darrera instància, cal arribar a un equilibri entre el sobrecost pel balanç del client (si migrem massa sovint) i el risc que podem assumir en termes de seguretat (si no migrem amb prou freqüència).
La política de migracions d'Odoo S.A.
Odoo SA llança una nova versió cada any i assegura el manteniment tècnic de dues versions anteriors a la darrera versió. Per exemple, quan es va publicar la versió 16 l'octubre de 2022, Odoo va deixar de mantenir la versió 13 i només manté les versions 14, 15 i 16. Això vol dir que Odoo no farà un control de seguretat per al codi de les versions antigues i ja no solucionarà els errors que puguin aparèixer.
Al cap d'un temps, ja no tenim cap opció: hem de migrar a una versió més recent d'Odoo perquè, en cas contrari, ens exposem a vulnerabilitats de seguretat. Algunes organitzacions que s’auto-allotgen l’Odoo, trien aquesta opció per a la seva instància (i fins i tot hi ha integradors d'Odoo que no sempre dominen les eines de migració), però això no és el que volem oferir des de Coopdevs.
Odoo SA no ens facilita la vida perquè les noves versions sempre contenen modificacions que no són compatibles amb les versions anteriors. Per exemple, si utilitzem dades d'una base de dades Odoo 12 al codi d’Odoo 13, es generen tants errors que ja no podem utilitzar la base de dades. Per tant, cal migrar la base de dades d'una versió a una altra i per fer-ho, cal fer servir un codi especial, els fitxers «script» de migració. Aquestes són les instruccions utilitzades per actualitzar les bases de dades perquè siguin compatibles amb la nova versió d'Odoo.
Però els obstacles no s'aturen aquí. Odoo SA, encara que elogia la seva solució de «codi obert», no publica de forma oberta els fitxers «script» de migració. Els manté en versió propietari i només els utilitza pels clients del seu servei Odoo Entreprise. Aquest és un tema recurrent a la comunitat de codi obert (Open Source), per exemple en aquest fil de discussió a LinkedIn on el fundador d'Odoo Fabien Pinckaers, sosté que Odoo SA ofereix , malgrat tot, una solució de codi obert. És una mica com si cada any l’ajuntament canviés les direccions dels carrers i no ho fes públic, cadascú ha de refer el seu mapa per poder planificar la ruta que fa cada vegada.
Per tant, hem de provar i descobrir per nosaltres mateixos els canvis fets a cada versió d'Odoo i després, reescriure els nostres propis scripts de migració que publiquem —aquests si que amb el model open source— als nostres respositoris. Per a fer-ho, utilitzem l'eina Open Upgrade, junt amb d’altres organitzacions de la comunitat OCA. Això enforteix cada cop més la nostra voluntat de poder contribuir i col·laborar amb els membres d'aquesta comunitat, amb qui si que compartim la seva filosofia sobre el codi obert.
Paral·lelament a la migració de la base de dades, també cal migrar el codi proporcionat per comunitat OCA i si és el cas, el codi personalitzat creat per Coopdevs per a cada client, perquè sigui compatible amb les versions més recents d'Odoo. Tot això ens ocupa també molt de temps.
Els reptes de la migració freqüent
Migrar amb freqüència és difícil, per diverses raons.
- Migrar amb freqüència és més car que no migrar o fer-ho de forma esporàdica, perquè la feina s'ha de fer diverses vegades: migrar el codi, provar, monitoritzar, gestionar bases de dades, validació amb els clients... Tanmateix, també hi un efecte invers a mida que passa el temps: com més sovint migrem, més desenvoluparem les nostres habilitats i les eines d'automatització, menys haurem de tornar a aprendre com migrar i més ràpid anirà cada migració. Per tant, la comparació no és tan senzilla.
- Migrar requereix mobilitzar molts recursos. Per donar un ordre de magnitud, el volum de treball per migrar la setantena d’instàncies dels nostres clients i les internes ascendeix a més de mil cinc-centes hores de feina.
- A banda del problema del finançament, que esperem resoldre amb una nova fórmula de subscripció, hi ha el problema dels recursos personals disponibles. Això requereix mobilitzar molt temps a un equip gran de persones i, per tant, canviar de forma important la nostra organització interna.
Però també te els seus avantatges:
- Migrar amb freqüència integrarà el treball de migració als nostres fluxos de treball. Això requerirà un millor coneixement dels mòduls existents i desenvolupar eines automatitzades per facilitar la tasca de migració.
- Això també ens permet fer present les migracions periòdiques als clients i tenir-ho en compte quan ens demanen desenvolupaments personalitzats (reduir-los o fer-los de la forma més genèrica possible per agrupar-les amb altres clients). Com diu Matthieu del supermercat Bloum: "És com totes aquestes decoracions que has fet a casa, quan t'has de moure, són moltes caixes addicionals".
- Estar al dia en les versions d'Odoo permet posar els nous clients a les versions recents, tenint migrat tot el codi específic (no estàndard). Les noves organitzacions tenen accés a un producte millor i es beneficien de tota la nostra base de codi. Això presenta, per tant, un avantatge comercial i permet incorporar més fàcilment nous actors que puguin sumar a l’estructura comú.
- Finalment, migrar amb freqüència ens permet treballar colze amb colze amb els nostres socis que utilitzen i ofereixen serveis al voltant de l'edició Odoo Community dins de la OCA. De fet, com més esperem per migrar, més fem el paper de “free rider” (polissó), perquè ens beneficiem del treball de migració de codi i escriptura de fitxers script d'Open Upgrade que hagin fet altres proveïdors (i que en cas de que no s’hagi fet al final haurem de fer igual.
- Treballar al mateix temps que altres en aquestes tasques permetria augmentar la visibilitat i la credibilitat de Coopdevs i unir-nos amb altres membres de l'OCA per sumar els nostres esforços i organitzar-nos. Aquest és també un tema que es tracta regularment a l'OCA. Si potenciem la nostra participació a OCA podem contribuir a aconseguir una solució de finançament global per a Open Upgrade que beneficiarà tots els usuaris de l'edició Odoo Community i, per tant, als nostres clients!
Objectiu: migrar cada dos anys
Després de valorar aquest complex escenari, hem pensat quina estratègia volíem adoptar d’ara en endavant sobre les migracions. Hem descartat seguir el ritme d’Odoo SA de migrar cada any perquè no disposem ni de prou personal ni de prou volum de negoci que ens permeti seguir aquest ritme.
Migrar cada 3 o 4 anys, en canvi, ens sembla massa llarg perquè suposa quedar massa endarrerits, tenir moltes versions actives i assumint riscos de seguretat perquè els clients més antics estaran fora del suport dels mòdul del nucli d’Odoo SA. Per tant la nostra estratègia general seria:
- Migrar de versió les instàncies cada dos anys i repercutir el cost de la migració mitjançant els pagaments mensuals al llarg dels dos anys previs.
- Fer servir només versions parells implementant 1 o 2 versions per darrere de la darrera d’Odoo en la mesura del possible, ja que la comunitat necessita un temps entre que Odoo llança la seva i en migren els mòduls i creen els fitxers script de migració i en funció de les funcionalitats a cobrir podria no ser possible.
- Incoporar-nos en la mesura del possible a la dinàmica de participació a la OCA per a evitar l’efecte polissó.
Previsó de calendari per a la migració dels Odoo a Coopdevs
* Odoo SA publica cada mes d'octubre una nova versió (V17 va sortir a octubre de 2023)2024 | 2025 | 2026 | 2027 | 2028 | |
Versió Odoo SA* | V17 | V18 | V19 | V20 | V21 |
Darrera versió suportada | V14 | V15 | V16 | V17 | V18 |
Noves implantacions Coopdevs | V16 | V16 | V18 | V18 | V20 |
Migracions Coopdevs | V12->V14 | V14->V16 | V16-V18 | V16-V18 | V18->V20 |