Hola a todos, os deseo un muy feliz 2023.
2 Answers
Ignacio ya ha dado las pautas principales, y el resumen es que no existe "solución buena", y es lo que ha creado Odoo con esta dualidad.
Mi estrategia es la contraria (OpenUpgrade), eso sí, por las siguientes razones:
- El servicio de migración enterprise es una caja negra, de la que luego hay que hacer "ingeniería inversa" para saber cómo deja los datos para ser utilizados en el resto de módulos OCA.
- También el mismo hace a veces "limpieza de más", eliminando columnas, campos, etc, de los que otros módulos OCA se estaban beneficiando para no perder información.
- Como OpenUpgrade es parte de OCA y los implicados en su desarrollo utilizamos módulos OCA, la fusión de módulos, renombramientos, etc están incluidos en el propio OpenUpgrade (ejemplo: https://github.com/OCA/OpenUpgrade/blob/14.0/openupgrade_scripts/apriori.py ), y no hay que duplicar esfuerzos o hacer cosas raras post-upgrade.
- Siendo uno de los desarrolladores de OpenUpgrade, también he visto que nos esmeramos más en cierto pulido de detalles que el servicio enterprise. Ejemplo: nuestro mecanismo para v12 para convertir los fragmentos HTML de Bootstrap 3 a Bootstrap 4 que Odoo no tuvo en cuenta. Y en v16 pasará lo mismo con BS4 a BS5.
- Esto alguno lo puede ver como una desventaja, pero en realidad no lo es, y es que con OpenUpgrade, hay que pasar por cada versión intermedia. ¿Por qué no lo considero una desventaja? Porque eso permite ir aplicando cada transformación de las versiones intermedias de los módulos OCA. Esto no significa que haya que tener todos los módulos de tu BD migrados a cada una de las versiones intermedias, ojo. Simplemente, que si hay módulos OCA migrados a esas versiones y tienen scripts de migración, los incluyes en tu addons_path y se ejecutan para llegar al resultado final esperado. En cambio, con migraciones enterprise, se obtiene la BD en la versión final, y realizar las transformaciones intermedias puede ser una locura, y tantas variaciones como versión inicial y final haya.
- En OpenUpgrade intentamos mantener una política de eficiencia suficiente para tener las migraciones terminadas en un tiempo razonable, pero dejamos que muchas cosas se procesen en ORM por completitud. El servicio de enterprise realiza todo en SQL puro, lo que es más eficiente, pero te puedes encontrar con campos no rellenados que luego sean problemáticos.
- Como OpenUpgrade se ejecuta en local, es más fácil de instrumentar e incrustar en un pipeline completo de cara a la migración definitiva, aunque todo sea dicho, el servicio enterprise también dispone de API.
Por último, la principal desventaja que puede haber con OpenUpgrade es la disponibilidad de los scripts, que históricamente siempre ha ido por detrás que la de enterprise, aunque bueno, llevan prometiendo varios años migración a la última versión en el mismo momento de la salida de la misma, y de momento no lo han conseguido, y creo que el servicio de migración a 16.0 todavía sigue en beta.
Mis consejos:
- Como ya se ha dicho a lo largo del hilo, utiliza OpenUpgrade.
- Reduce al máximo el número de módulos enterprise utilizados. Hay muchos módulos OCA que son equivalentes.
- Nunca uses ni permitas usar Odoo Studio. Eso del código como datos te va a traer muchos dolores de cabeza.
Muchísimas gracias Pedro por la explicación tan detallada. Finalmente he logrado, tras muchas horas de desvelo estos días, migrar de V12 enterprise a V14 enterprise, empleando OpenUpgrade. He decidido optar por Open Upgrade porque, por una cuestión de pura proporción en la cantidad de código (Enterprise VS CE/OCA), es más sencillo detectar qué cambia Enterprise en sus modelos de datos exclusivos y actuar en consecuencia elaborando los scripts SQL necesarios para esa capa enterprise. Gracias por los consejos a los dos (Ignacio y Pedro).
Hola,
Como bien has dicho OpenUpgrade ignora los Enteprise, y la migración Enterprise ignora los de OCA. Al final no hay método que te haga ambos.
Nosotros usamos la migración enterprise y nos hemos creado nuestro propio sistema que convierte los datos de los módulos OCA. Pero podría ser igual al revés migrar con OpenUpgrade y crear tu propio sistema para adaptar los enteprise.
En ambos casos vas a tener que crear un sistema que te permita adaptar lo que no migra uno de los sistemas, ya sea usando comandos SQL o utilizando el XML-RPC. Este el reto de usar híbridos Enterprise con OCA, son una solución muy buena pero a la hora de migrar tienes este problema.
Saludos,
Ignacio
Ignacio Ibeas
Acysos S.L. (www.acysos.com)
Odoo Partner (https://www.odoo.com/es_ES/partners/acysos-s-l-80090)
Asociado Asociación Española de Odoo (https://www.aeodoo.org/members/acysos-s-l-24)
Odoo Community Association (https://odoo-community.org/members/acysos-s-l-ignacio-ibeas-760)
Github (http://www.github.com/acysos)
Odoo Apps (https://www.odoo.com/apps/modules/browse?author=Acysos S.L.)
C/ Miguel Astrain 18, 1º Oficina A
31006 Pamplona, Navarra.
ignacio@acysos.com
Tel. 948238905
---------------------- // -------------------
La información contenida en este mensaje de correo electrónico es
confidencial, para ser leída por la(s) persona(s) a quién se dirige. El
acceso a este mensaje por otras personas no está autorizado. Si Ud. no es la
persona a la que va dirigido, cualquier divulgación, copia o distribución de
la información queda prohibida y puede ser ilegal. Asimismo, cualquier acción
tomada o dejada de tomar basada en la información contenida en este mensaje
queda prohibida y puede ser ilegal.
The information in this e-mail is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this e-mail by anyone is
unauthorised. If you are not the intended recipient, any disclousure,
copying, distribuition or any action taken or omited to be taken in reliance
on it, is prohibited and may be unlawful.