Payday Loans Online

Archivo etiqueta migracion openerp

Migraciones de versión en OpenERP

Acabo de llegar de Bélgica. Han sido 3 intensísimos días y lo cierto es que estoy bastante cansada pero durante todo el viaje venía pensando a ver cómo os iba a explicar claramente la situación que teniamos hace 3 días y la que tenemos ahora. Es increible cómo un malentendido y un poco de obcecación tanto por nuestra parte como por la parte de OpenERP nos ha podido llevar por la calle de la amargura durante el último año cuando en 2 horas de reunión hemos podido enfocar y resolver el mayor problema que encontrábamos a la hora de ofrecer OpenERP a nuestros clientes: Las migraciones de datos.

Este tema ha sido uno de los más hablados, el que más discordia ha creado en la comunidad y el que más preocupados nos tenía a los partners.

Para aquellos que llegais ahora o no entendeis nada de lo que estoy diciendo, intento resumir.

  • La mayoría de los editores de software que llegan al nivel de expansión de OpenERP en el mundo, deciden optar por un modelo mixto de módulos “licenciados” o de pago como estrategia de negocio. Lo que sería una versión comunidad sin coste de licencias y una versión “enterprise” con módulos de pago, o con una licencia particular. Por contra, OpenERP siempre ha defendido la publicación libre de todos sus módulos y por tanto, la diferencia entre la versión comunidad y la versión enterprise, es la contratación o no de la garantía de OpenERP, la cual incluye soporte a errores (bugs) y migración de versión.
  • En su momento, OpenERP decidió NO publicar sus scripts de migración de datos, de una versión a otra, lo cual es totalmente lícito (cualquier empresa del mundo requiere definir sus líneas de negocio, si no, no serían empresas sino ONGs) pero trajo innumerables críticas tanto de partners como de la comunidad ya que la única forma de migrar OpenERP de una versión a otra, era contratando la garantía. Hasta aquí perfecto y sin problema siempre y cuando un cliente utilizase los módulos del core.

Pero se da el caso de que NINGUN cliente utiliza SOLO los módulos del core, sino que además, existen módulos no oficiales (denominados módulos de localización) que adaptan el sistema a los requerimientos fiscales de cada país y por tanto su instalación es imprescindible en cada uno de ellos. Así, en españa tenemos la localización española, en Venezuela la venezolana, en Suiza la Suiza…

Además de los módulos de localización, la mayoría de los clientes suele adaptar el sistema a sus necesidades específicas por lo que solicitan módulos a medida o también pueden requerir otros módulos publicados por la comunidad o por partners de OpenERP. Estos módulos al no ser parte del core, evidentemente, no se incluyen en el contrato de garantía.

No obstante era posible solicitar la migración de TODOS los módulos de una instalación, sea esta cual sea y tenga los módulos que tenga, siendo el precio de 800€ por cada 1000 líneas de código extra por CADA implantación. Cada cliente que solicitase el servicio debía pagar esta cantidad. Esto era comprensible para módulos específicos de un cliente que los haya mandado desarrollar pero no para los módulos de localización, ya que son requeridos en cada una de las implantaciones que hacemos. Casualmente, la localización española es una de las más maduras y fuertes que existen y el número de líneas es considerable, con lo cual el importe a pagar por cada uno de nuestros clientes en cada versión (cada 18 meses) no era asumible. Por tanto, determinamos que el servicio ofrecido por OpenERP, NO CUBRIA las necesidades de nuestros clientes y nos empezamos a preocupar.

Después de 2 años … innumerables emails, reuniones, skypes y todo lo habido y por haber… nuestra percepción era que OpenERP no nos escuchaba. La percepción de OpenERP era que nosotros íbamos por libre y a nuestro aire, sin contrubuir a su estrategia de negocio y sin apoyarles en su expansión, lo cual en bastantes ocasiones en los últimos meses nos ha llevado a situaciones tensas y malos ratos innecesarios.

Hasta aquí, el pasado… ahora… el futuro:

  • El no liberar los scripts de migración es decisión de OpenERP, es su estrategia de negocio y están en su perfecto derecho de definir dicha estrategia
  • OpenERP asume que los módulos de localización española son requeridos por todos los clientes españoles por lo tanto, se incluirán como módulos NO Extra en las migraciones. Es decir, no existirá coste extra en la garantía “oficial” para estos módulos. No obstante, en toda migración se requieren servicios extra para validar, testear y probar la migración con lo cual CADA PARTNER decidirá el coste extra que incluirá en la garantía oficial para asumir las horas de servicio para realizar la migración.
  • Los módulos que sean específicos de un cliente podrán ser migrados de 2 formas:
    • El  partner asume la migración –> OpenERP no incluye coste extra para las líneas incluidas en estos módulos
    • OpenERP asume la migración de estos módulos –> El cliente deberá asumir el coste de 800€ por cada mil líneas de código en módulos personalizados.
  • Si un partner demuestra que un módulo extra o desarrollado a medida es utilizado por más de 10 clientes con garantía, entonces el partner podrá proponer el módulo para que sea incluido dentro del contrato de garantía, con la migración incluida sin coste adicional (como hemos dicho antes, esto sólo sería necesario si el partner prefiere que openERP realice el trabajo de migración del módulo).
  • EN TODOS ESTOS CASOS, tanto la garantía de soporte (bugs) de los módulos de localización como los que se desarrollen a medida deberá ser asumida por el partner y la inclusión de los módulos se refiere UNICAMENTE a la migración de datos. No al soporte técnico de los módulos.

Como veis el escenario cambia totalmente. En este caso, el contrato de mantenimiento con OpenERP pasa a ser una garantía real, requerida y necesaria. Por fin vamos a poder ofrecer a nuestros clientes OpenERP enterprise con garantía. Una vez resuelto el tema con OpenERP S.A, ahora solo hemos de ver si es necesario cambiar algo internamente en la forma de organizar la localización o el sistema actual sigue siendo válido, pero esto es ya otra historia distinta a definir entre nosotros.

Por último, daros una pincelada sobre cómo funciona técnicamente el servicio ofrecido por OpenERP porque lo cierto es que hasta ayer ninguno lo habiamos entendido bien. No entendíamos cómo en caso de no querer asumir el coste de 800€ por cada 1000 líneas de código podiamos asumir nosotros parte de una migración y OpenERP otra. Ahora sí lo entendemos. Aquí va:

Entendamos primero en qué consiste una migración de datos entre versiones:

  • En una instancia a migrar tenemos 2 partes: módulos python + BBDD postgresql.
  • En principio, supongamos módulos python de una versión y bbdd postgresql de la misma versión. Si por algún motivo hubiese cambios en la lógica de la aplicación sin cambios estructurales en la base de datos, no hay ningún problema ya que el sistema internamente provee de un proceso automático de actualización, es por esto que en la migración de versiones menores (6.0.1, 6.0.2), no existe ningún problema. Solo cambia la parte python, por lo con ejecutar un “actualizar todos” desde el propio interfaz, el sistema queda actualizado.
  • El problema viene cuando hay cambios estructurales en la base lo cual es inevitable cuando se publica una versión mayor ( esto es 5.0 a 6.0, o en su caso 6.0 a 6.1 ). En este caso, es necesario transformar una estructura en la otra, sin perder los datos que previamente se hubiesen cargado. Esto es lo que ofrece el sistema de garantía de OpenERP.

Veamos ahora cómo sería el proceso a seguir:

  • OpenERP provee una herramienta que nos permite “subir” una bbdd de una versión y devuelve la misma base de datos “migrada” a la nueva versión. SOLO las tablas correspondientes a los módulos del core serán migradas. Todo el resto de tablas, será mantenido exactamente igual que estaba. (Nota: A fin de proteger la confidencialidad de datos de los clientes, la base de datos se sube y se recibe encriptada)
  • OpenERP migra SIEMPRE los módulos python oficiales a la nueva versión.
  • Bien OpenERP(con el coste antes mencionado) o bien el partner migra los módulos python no oficiales, sean de localización o sean a medida, para que puedan ser instalados en la siguiente versión. (Para facilitar el trabajo al partner, OpenERP provee de una herramienta denominada runbot, donde el partner puede testear los módulos los cambios que serán necesarios realizar en el código python)
  • El partner, realizará la instalación de la nueva versión con los módulos python migrados, desencripta la base de datos recibida y lo sube a la nueva instancia creada. Reinicia el servidor con Update==ALL.
  • En este punto, la migración en sí, ya está realizada.
  • Por último, el partner con su cliente testea los datos y cada uno de los procesos funcionales que utiliza para verificar que todo ha quedado correcto. Si hubiese algún problema o proceso que el sistema automático ha generado, se reporta a OpenERP como bug. El arreglo de este bug en el proceso de migración está incluido en el contrato de garantía.
  • El proceso puede ser repetido tantas veces como sea necesario, es decir, el partner puede subir la base de datos encriptada de su clientes tantas veces como se requiera, hasta que se obtenga la validación de la migración por parte del cliente, hasta llegar al grado de depuración requerido.

Creo que estos son los puntos más importantes, aunque si los que estuvisteis en la reunión, veis que falta o me he equivocado en algo, por favor, no dudeis en ponerlo en los comentarios para que pueda rectificar o ampliar el post.

Por último, comentaros que muy en breve tendremos un post en el blog de OpenERP donde nos explicarán en detalle el proceso de migración y ampliarán la información que doy aquí de forma resumida. Prometo traducíroslo en cuanto se publique.

No me queda más que agradecer a OpenERP y en especial a Fabien y Marc el tiempo que nos dedicaron. Mención especial también a Rubén, por “meter caña” ;)

A Nhomar de Vauxoo, por su apoyo y su valiosa intervención en la reunión. A Nacho de Alfa90, el haber expuesto con suma claridad el problema por parte del cliente, lo cual ayudó en gran medida a que OpenERP entendiera (por fin!) nuestra visión del tema. Y como no… a Santi de Pexego, figura imprescindible en la localización española con quien la mayor parte de las veces comparto la forma de ver las cosas.

Muchas gracias a todos:

Ana

P.D: Edito a 17/04/2012 para incluir el link que sobre el mismo tema ha escrito Santi en el blog de Pexego. Merece la pena:

http://www.pexego.es/blog/2012/04/15/openerp.-sobre-vision-y-modelo-de-negocio

,

13 Comentarios

Nueva solución para la Migración entre versiones de OpenERP

Como siempre… Albert Cervera de Nan-tic, nos sorprende con esta buenísima noticia. Os paso íntegro el post en castellano, que creo que merece la pena. Aquí el link original al artículo. Incluyo también links a las traducciones en inglés y catalán.

Castellano: http://www.nan-tic.com/es/presentando-kafkadb

Inglés: http://www.nan-tic.com/en/presenting-kafkadb

Catalá: http://www.nan-tic.com/ca/presentant-kafkadb

Presentando KafkaDB

Enviado por Albert Cervera … el Lun, 07/11/2011 – 11:13.

Hoy queremos presentaros KafkaDB, nuestra nueva criatura que acabamos de publicar en bitbucket. KafkaDB es una herramienta que simplificará la tarea de migrar bases de datos entre versiones de OpenERP, pero también se podría extender para permitir la migración entre versiones entre otras aplicaciones basadas en PostgreSQL. En la página principal del proyecto, podéis encontrar información detallada sobre el diseño y como utilitzarla, pero ahora quería haceros cinco céntimos de cómo hemos llegado hasta aquí.

Los requerimientos

Desde que OpenERP SA anunció que las herramientas de migración no formarían parte del software público empezamos a dar vueltas en cómo podríamos implementarlas de forma reutilizable. Algunas empresas buscaron soluciones a corto plazo, simplemente mirando de solucionar el problema para uno o dos clientes que querían pasar de la 4.2 o la 5.0 a la 6.0 y posponiendo la búsqueda de una solución real. Nosotros estábamos convencidos que de la misma manera que la herencia había permitido a OpenERP tener centenares de módulos hechos y liberados por muchos desarrolladores, podríamos conseguir lo mismo con las migraciones.

Así que básicamente teníamos que implementar algo que solucionara los siguientes requerimientos:

  • Modular: tenía que proveer un mecanismo mediante el cual se pudieran reutilizar las transformaciones de datos de una base de datos a otra.
  • Rápido: dada la medida de las bases de datos de algunos de nuestros clientes, sabíamos que tendríamos que mover la información a nivel de base de datos.
  • Fácil de compartir: además de ser modular, queríamos asegurarnos que sería sencillo para todo el mundo compartir sus transformadas. Dado que la información sobre la migración no estaría incluida en los módulos, necesitábamos que fuera sencillo de compartir, así cómo de encontrar qué transformadas había disponibles.

Búsqueda y desarrollo

Nos ha costado un cierto tiempo hasta llegar al diseño actual de KafkaDB. El proceso empezó con una pequeña prueba de concepto utilizando Python y openetl, un ETL creado por OpenERP SA, pero abandonado este mes de junio. Descartamos esta opción, no tan sólo porqué estaba abandonado, sino también porqué la API no era intuitivo. Además, a pesar de que no llegamos a hacer pruebas, parecía que podía ser relativamente lento.

La primera alternativa fue buscar otro ETL basado en python. Esta vez el candidato fue el Brewery. Éste tenía una API bastante mejor pero no disponía de algunas funcionalidades básicas que necesitábamos y a pesar de que habríamos podido contribuir al proyecto, necesitábamos centrarnos en solucionar los problemas que teníamos, no a implementar un ETL desde cero.

Habríamos querido que fuera en python, especialmente para hacer más sencillo que la gente contribuyera, pero empezamos a buscar alternativas en otros lenguajes. Scriptella fue el primer candidato y éste basa su configuración en un fichero XML, así que nos pareció atractivo. Ya sabíamos que el sistema que escogiéramos acabaría teniendo un fichero de configuración, así que a primer vistazo parecía que esta podía ser una buena opción porque el sistema ya dependía de uno. A pesar de esto, no nos convenció el comportamiento por defecto de algunas opciones del sistema, además del hecho que el XML parecía que podría ser poco práctico puesto que fácilmente podíamos llegar a las 400 tablas.

Así que Àngel, uno de mis socios y nuestro experto en Kettle y grandes migraciones de datos, empezó a jugar con la API de Kettle y mirar a ver qué se podía hacer con transformadas manuales y algunos automatismos. Pronto se dio cuenta, que no tan sólo podía cumplir todos los requerimientos que teníamos, sino que además, permitíamos que personas que no fueran desarrolladores también se podían migrar su base de datos. Por ejemplo, varios de nuestros clientes se lo podrían hacer ellos mismos si lo desearan!

Además, Kettle es probablemente el ETL estándar de facto y especialmente entre la comunidad OpenERP (gracias a Terminatooor, un conector para Kettle creado por Akretion, especialmente diseñado para funcionar con OpenERP).

En resumen, a pesar de que KafkaDB no está acabado del todo todavía, estamos convencidos que constituye una buena base para el sistema de migraciones flexible que necesitamos, no tan sólo para migrar información entre versiones de OpenERP, sino también entre aplicaciones diferentes siempre y cuando se necesite reutilizar el proceso para diferentes bases de datos con estructuras parecidas.

3 Comentarios