Odoo mas de 2000 modulos a disposicion de las empresas
Descubra módulos de terceros, módulos de OCA, de avanzosc, de empresas independientes... github, runbot y más


RUNBOT: ¿Qué es y para qué sirve?

Como consultor funcional y responsable de proyectos en avanzosc, uno de mis caballos de batalla es intentar que la calidad de código y la funcionalidad de nuestros módulos sea comprobada antes de que sean instalados en entornos productivos.

Hasta hace relativamente poco tiempo y en la mayoría de las soluciones de mercado, la única forma de hacer esto, era tener un entorno "pruebas/demo" donde los técnicos instalaban su recientemente creado o modificado módulo y los funcionales intentábamos encontrar los agujeros o fallos de código antes de presentarlo al cliente e instalarlo en su entorno.

Para minimizar el impacto de errores y tener un entorno funcional donde testear el código y todas las mejoras que se van introduciendo, Odoo cuenta con una impresionante herramienta llamada runbot.


Runbot: Las cajas de colores

Cada caja de colores corresponde en runbot a una instancia, un "build" de Odoo, incluyendo parte del código completo. 

Por cada versión/PR... etc se mantienen únicamente los 4 últimos "build". Según se van añadiendo o fusionando nuevas cosas, nuevos builds aparecen a la izquierda y los más antiguos desaparecen por la derecha

Si cogemos la fila marcada con una estrella amarilla y la etiqueta 14.0, estamos mirando la versión estable 14.0 de Odoo.  "Master", sería la versión futura. Si cogemos la de abajo estaremos mirando la versión anterior 13.0.y más abajo aún, cada una de las versiones de SAAS que mantiene Odoo. 

Cada fila contiene cajas que están en "verde" (todos los test fueron correctos y está funcionando), "rojo" (algo falló y probablemente no funcione), "azul" (Se está creando un build, o está pendiente)

Cada caja contiene además varias puertas azules, que si pulsamos nos llevan directamente a una base de datos en esa versión que podemos testear. Las puertas con etiqueta Odoo serían la edición "community", enterprise sería la edición "enterprise" y desing theme, sería para testear diferentes "themes" de Odoo.

En cualquiera de estos entornos, podemos crear cosas, borrar, cambiar, instalar módulos... hacer un poco lo que queramos con ello igual que si hiciésemos una instalación en local. Con la diferencia de que esto es efímero. En cuanto haya otros 4 builds la base de datos en la que hemos estado probando desaparecerá. 



Pull Request --> Enlace github / runbot

Algunos conceptos muy básicos:

Github: es el repositorio donde se publica el código de las ramas oficiales de Odoo, tanto la la versión community como los módulos enterprise. La versión enterprise se publica en ramas privadas y es necesario tener privilegios de acceso para poder descargar el código de ellos. En cambio la versión community es pública y abierta para su descarga a cualquier usuario de Github.

Puesto que Github es la herramienta seleccionada por Odoo para publicar su código, la mayoría de los proyectos realizados por la comunidad de Odoo se publican también en dicho repositorio. 

El código / módulos / aplicaciones se publica en RAMAS (Branch) temáticas, o de una empresa, o de una asociación o una persona individual.  Es el caso de los módulos de OCA("odoo community association") publicados en http://www.github.com/OCA o los nuestros propios publicados en http://www.github.com/avanzosc

Un Pull request o PR es código que se quiere fusionar o incorporar en un módulo existente previamente, porque lo mejora, extiende o soluciona un error. También puede ser código nuevo que directamente crea un nuevo módulo en una rama o proyecto de Github. .

Así por ejemplo, si alguien encuentra un problema o "issue", para el que hay que modificar un módulo, dicha modificación se sube a github mediante un Pull Request o PR. Por tanto, decimos que si alguien quiere aportar una mejora o funcionalidad nueva a un proyecto de la comunidad de Odoo debe realizar un PR contra la rama correspondiente

Cada PR puede corresponder a un módulo nuevo [ADD], corrección [FIX], mejora [IMP]. Estas etiquetas se añaden en el nombre de cada módulo. Además, cada uno de ellos está numerado y este número aparece justo debajo del nombre  por ejemplo, #8026

Cada vez que alguien realiza un nuevo PR, sea para lo que sea, es necesario comprobar que no "rompe" nada de lo que está programado en la versión estable. Existe en Odoo la posibilidad de incluir en el módulo test automáticos que pueden realizar esta validación, pero esto sería otro capítulo. Veamos ahora cómo comprobar la validez de un PR en runbot.


Runbot de OCA

Todos los ejemplos vistos hasta el momento se basan en la rama principal de Odoo publicada por la casa madre en Bélgica. La herramienta runbot.odoo.com permite testear el core base pero... también existe un runbot de la comunidad gestionado por OCA: Odoo Community Association, la comunidad mundial internacional de Odoo y es

runbot.odoo-community.com


El funcionamiento básico es exactamente igual que el de Odoo, con la diferencia de que sus ramas están publicadas en https://github.com/OCA. De esta rama principal derivan decenas de proyectos comunitarios, en los que la comunidad mundial publica módulos y mejora los existentes a diario. 

Cada proyecto OCA corresponde a una temática concreta y extiende el área del core en dicha temática. Así, por ejemplo, stock-logistics-workflow incluye módulos que extienden el área de stock, y sale-workflow incluye módulos que extienden el core en ventas. 

Si miramos en la imagen, podemos ver en la parte de arriba a la izquierda un desplegable donde se puede seleccionar la rama de github que se desea testear. Por tanto, por ejemplo si queremos entrar a validar o probar módulos de sale-workflow, tendremos que seleccionar dicha rama en el desplegable y entrar en cualquiera de las puertas azules que estén disponibles.

Si hacemos un poco de scroll hacia abajo, veremos que cada PR es a su vez una fila. Cada número de PR en Github aparece en runbot. Solo tenemos que buscarlo y de nuevo pulsar la puerta azul para ver nuestro nuevo código instalado en esa instancia y podemos probarlo, detectando prosible problemas o mejoras a realizar. 

Para completar el ciclo, si se ve que el PR es correcto y se aprueba la fusión con el codigo base, se indica en Github un comentario incluyendo +1. Si no se aprueba o hay algún problema se indica igualmente incluyendo -1. 

Esta forma de hacerlo, permite a los técnicos revisar el código antes de la fusión y modificarlo bien actualizando el PR existente, bien creando otro nuevo que a su vez se podrá testear en Runbot. La enorme, increible ventaja de Runbot es que puedes PROBAR código ANTES de que la fusión se realice con el código base.

En TODOS los casos, todas las bases de datos, el usuario y password a utilizar es admin/admin tanto en el runbot de Odoo core, como en el runbot de la comunidad.


Metodología de implantación Odoo Avanzosc
Nos basamos en la formación