Siempre ha sido complicado para mi, como líder de proyecto de una implementación de Odoo y de cierta forma también como cliente final, poder tener la certeza de que estoy probando una funcionalidad tal cual la va a usar el cliente en producción una vez que éste la apruebe. Suena extraño, pero es SÚPER complicado conjugar en un mismo ambiente: la data real actualizada del cliente, las configuraciones acordadas al momento y los últimos cambios en el código, sobre todo si tomamos en cuenta que en un mismo día puede ocurrir (y ocurre varias veces!) que:

• El cliente cargue o actualice data: productos, clientes, cuentas, etc.

• Yo, como líder de proyecto, cambie configuraciones discutidas con el cliente: nueva listas de precio, un nuevo permiso, etc.

• Los desarrolladores mejoran o actualizan funcionalidades vía código según vayan aprobandose las Merge Proposals.

El problema es viejo y conocido, pero nosotros en Vauxoo logramos dar con algo que pareciera haber mejorado este escenario para todos en general: el líder de proyecto, los consultores/desarrolladores, el cliente final, el sysadmin y demas personas que necesiten contexto de lo que verdaderamente esta LISTO.

Voy a pasar a explicar como entendí la escencia del funcionamiento de DeployV, no se si es la mejor forma de explicarlo, pero para al menos para mi fue la mejor forma de entenderlo.

Primeramente, la mejor forma de entender algo es haciéndote la pregunta clave cuya solución es lo que terminas por aprender; algo así como empezar programando la prueba antes que la funcionalidad. En este caso mi pregunta fue:

¿Donde #&%*$"! esta la instancia con todas las actualizaciones que hicimos hoy?

(código, datos, configuraciones)

La respuesta no es sencilla, pero como diría Jack El Destripador, vamos por partes. Esta imagen es la visual principal para el entendimiento de esto.

 Tenemos entonces cuatro ambientes o instancias:

• Updates

• Production

• Test

• Develop 

La instancia de Updates una instancia de pre-Producción que se actualiza cada vez que se aprueba un Merge en cualquiera de los repositorios que la componen y aún no se pasan a producción. Si por ejemplo en el Repositorio addons-vauxoo en la rama principal 11.0 se aprueba el merge request #de2ad24 podemos ver la instancia Update con la siguiente información:

¿Que significa esto? Significa que ahora los cambios introducidos en ese commit ya pueden ser probados en esa instancia si desea.
¿Pero las configuraciones que había hecho en esa instancia? Se perdieron.
¿Y cuando veo los cambios en Producción? Desde Updates pides el pase a Producción en el botón de Schedule. No se pasan a Producción configuraciones que hayas hecho, solamente pasan cambios a nivel de código.

¿Y si quiero probar los cambios antes de entrar a producción? La escencia de Updates es realemente esa. Si queremos probar los cambios de código en lo mas parecido a una instancia de Producción posible entonces hacemos un Regenerate a la instancia de tal manera de cargar una base de datos mas nueva (el backup mas reciente de producción) sin cambiar los commits. Asi estamos mas seguros de saber si algo se rompió funcionalmente.

 La instancia de Test no necesariamente tendrá los últimos cambios hechos al código. La instancia de Test va a contener una copia de la instancia de Producción cada vez que la regeneres. Dicha copia tendrá la base de datos del último respaldo realizado de Producción.

¿Recuerdas que dije que en Updates tienes que pedir expresamente el pase a Producción? Bueno eso quiere decir que en Test tendrás la ultima versión del código solo si pasaste a Producción lo que existe en Updates. En un dibujo sería:

¿Que pasa con las configuraciones que había hecho en Test luego de regenerar la instancia? Se pierden. La instancia de Test es una copia de lo que tenías en Producción.

¿Para que me sirve entonces la instancia de Test? Puedes usarla para probar configuraciones, acciones de servidor, etc., que luego de ser fructiferas debes hacer en Producción.

¿Que configuración voy a tener en Test al regenerar la instancia? Vas a tener la del último respaldo hecho de Producción. Si requieres algo mas actual solicitas expresamente que se haga un resplado en ese momento al Sysadmin.

¿Y cuál es la diferencia entre "regenerar" y "actualizar"? 

El Regenerate construye la instancia de nuevo y carga una base de datos reciente. Si la imagen se construye desde gitlab directo solo le hace pull. El Update solo le hace pull a los repos (no hay proceso de reconstrucción) o pone los commits que uno le especifique y actualiza la base de datos (-u all, no carga una base de datos nueva). Es más bien para probar cambios rápidamente antes de darle Regenerate.

Iconos en las listas de instancias

En la lista de instancias generadas, para el caso de Updates aparecen dos tipos de íconos. El ícono del cohete se refiere a que esa instancia fue pasada a producción en algún momento. El ícono de check mark significa que esa instancia ya se encuentra perfectamente desplegada en Update pero no ha pasado (o nunca pasó) a producción.

La instancia de Producción es el eje central de todo el trabajo en la implementación. Todo lo que acuerdes con el cliente y que hayas verificado que funcione vas a Producción y lo configuras. E inmediatamente que tengas una instancia de Producción con nuevas configuraciones tienes que asegurarte que lo llevas a Test para siempre probar cosas y experimentar sobre lo último que acordaste con el cliente: Alfa y Omega.

¿Y cuando el Sysadmin genere una nueva instancia de Producción que sucede? Sysadmin no toca la configuración, solo despliegua los cambios a nivel de código o ejecuta scripts. Una vez lista Producción y se genere un respaldo con esa configuración ya tendrás posibilidad para generar una copia en Test o Updates y poder seguir tus pruebas con lo último que se acordó.

Ejemplo práctico:

• Cargue un inventario inicial en Producción:

• • NO lo valido, primero genero una instancia de Test.

  • Luego valido el ajuste de inventario y reviso la contabilidad en Test.

  • Si existen discordancias, corrijo en Test hasta que todo este OK.

  • Luego voy a Producción y aplico las correcciones necesarias acordadas en Test.

  • Finalmente valido el ajuste de inventario en Producción.

  
  

Pero ahora quiero probar en Test lo que está en Updates, ¿Qué hago? Tienes dos opciones:

1. Puedes probar en la misma instancia Updates, pero no tendrás las configuraciones que hayas hecho en Producción. Solo probarías los cambios mas recientes aprobados en el código.

2. Pides un pase a Producción de lo que está en Updates, y luego generas una instancia de Test. Con eso tendrás la última versión del código con las configuraciones que tenías en Producción.

Si eres desarrollador y llegaste a esta parte de la lectura sano y salvo, esto es contigo. La instancia de Develop es la única que manipula una persona con perfíl de desarrollador, en el caso que el equipo de proyecto este compuesto de un líder mas el(los) desarrollador(es). 

Develop es la única de las cuatro deidades que se puede crear a discreción y se elimina solo si el desarrollador lo desea. En otras palabras, el desarrollador puede crear una instancia que será copia de Producción, de Updates o Test incluso con Branchs aún no aprobados para Merge.

Las instancias de Develop no son idóneas para que el Líder de Proyecto pruebe algo con el cliente. Es mas para uso interno y de discusión entre el equipo de proyecto.