Debido al número creciente de colaboradores Libertya, se propone implementar una modalidad de trabajo que permita facilitar las tareas tanto para el colaborador como para los encargados de mantener el núcleo de la aplicación.
El presente documento tiene por objeto orientar a los desarrolladores de la comunidad Libertya respecto de la metodología de trabajo implementada en las tareas de ampliación/modificación de la aplicación.
Nota: Considerar de manera opcional a esta metodología el desarrollo de un microcomponente.
Es necesario que los colaboradores tengan un fluido conocimiento del framework Libertya, así como de la Arquitectura Libertya Components.
Este requisito es importante por los siguientes motivos:
El conjunto de archivos Libertya a descargar para una versión dada se encuentra alojado en el proyecto Libertya de Source Forge (https://sourceforge.net/projects/libertya/), incluyendo instaladores, binarios, bases de datos, y documentación (tanto de Libertya como de los componentes).
Tal como se detalla en la documentación para el desarrollo de componentes, todo componente debe implementarse a partir de una versión estable de Libertya. Sin embargo en ciertos casos es necesario poder realizar ampliaciones que se apoyen sobre versiones intermedias.
Es por esto que se cuenta con el repositorio público SVN del proyecto Libertya en SourceForge (https://sourceforge.net/p/libertya/) correspondiente a los fuentes LY. Los fuentes del Core de Libertya se encuentran alojados en https://sourceforge.net/p/libertya/src/trunk/.
Adicionalmente, una base de datos actualizada de Libertya CORE se genera y pone a disposición para su descarga en SourceForge (http://sourceforge.net/projects/libertya/files/libertya/dev/dumps/). De esta manera, es posible contar en todo momento con la versión de desarrollo más actualizada.
Para un colaborador, la inclusión de los cambios del core en sus fuentes locales es una tarea relativamente trivial, en la que simplemente un diff permite determinar los cambios realizados en los fuentes.
Sin embargo, la inclusión de cambios a nivel base de datos es un tanto más compleja. Aunque el dump generado periódicamente de manera automática puede llegar a serle de utilidad, si un colaborador se encuentra desarrollando una actividad que por ejemplo requiere cambios en el diccionario de datos, no es viable que éste descarte su base de datos (con eventuales cambios realizados), simplemente para contar con las últimas modificacions del core. El posible esfuerzo posterior de replicar manualmente los cambios realizados por el colaborador sobre la nueva base de datos descargada no justifica esta forma de trabajo.
Para evitar este escenario, se debe actualizar la base de datos donde se desarrolla el componente con las últimas actualizaciones del core. Para ésto, debemos utilizar el dump automático como base para la creación de un archivo .jar de actualización de su instancia de desarrollo (similar a cualquier archivo de actualización de CORE, como por ejemplo org.libertya.core.upgrade_11.10-13.01.jar). Este archivo deberá contener los archivos preinstall.sql, install.xml y postinstall.xml que reflejan los cambios de CORE sobre la base de datos durante el período contemplado en la actualización.
La generación de este archivo de actualización de la base de datos de desarrollo con los cambios realizados en la base de datos Libertya CORE implica:
Finalmente, para instalar el .jar simplemente es necesario acceder a la opción Instalador de Componentes (perfil System Administrator), y seleccionar el archivo previamente armado. Con ésto se logra actualizar la base de datos de desarrollo de un componente en donde se cuenta con un CORE actualizado, y además manteniendo todas las modificaciones realizadas por el colaborador en su componente.
Previamente a iniciar cualquier tipo de modificación/ampliación al core, es necesario acordar el objetivo y alcance de la funcionalidad a implementar a fin de poder coordinar las actividades entre todos los colaboradores.
Toda colaboración será centralizada a través de un issue o ticket de SourceForge (https://sourceforge.net/p/libertya/tickets/), ya sea tareas relacionadas con mejoras o correcciones.
Para cada issue a resolver, se creará un branch con la siguiente convención: Prefijo GC _ Nro de issue. Por ejemplo el branch GC_27 se encontrará relacionado con las modificaciones correspondientes al ticket 27.
En los casos en que se esté desarrollando funcionalidad que luego deberá ser incorporada al Core Libertya, se deberá crear y trabajar bajo un Componente Temporal de Desarrollo (Funcionalidad de copia de Changelog en instalación), el cual es descartado cuando la funcionalidad (fuentes + cambios en bbdd) son incorporados al core.
Para ésto, se deberán realizar los siguientes pasos:
La ubicación en donde deberán almacenarse los archivos preinstall.sql, install.xml y postinstall.xml (o eventualmente librerías o cualquier tipo de archivo adicional) será en el directorio /data/core/issues/ de cada branch. Por ejemplo, para el issue 27 será:
/branches/GC_27/data/core/issues/
El número y distribución de los archivos dentro de dicho directorio dependerá de cada requerimiento. Sin embargo, en todos los casos dichos archivos deben ser incorporados en formato comprimido (zip, gzip, jar, etc.) a fin de reducir el tamaño de los mismos lo más posible.
Una vez finalizadas las actividades correspondientes a las modificaciones/ampliaciones por parte de un colaborador, se deberán realizar las siguientes actividades: