WikiLibertya

Esta página es de solo lectura. Puedes ver la fuente pero no puedes cambiarla. Pregunta a tu administrador si crees que esto es incorrecto.
====== Metodología de desarrollo para colaboradores Libertya ======

===== Introducción =====

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 [[plugins:microcomponents|microcomponente]].

===== Requisitos =====


Es necesario que los colaboradores tengan un fluido conocimiento del framework Libertya, así como de la [[:start|Arquitectura Libertya Components]]. 
 
Este requisito es importante por los siguientes motivos:

  * Todo desarrollador debe poder discernir respecto de si una ampliacion corresponde ser incorporada al núcleo de Libertya, o bien es factible el desarrollo de un componente adicional específico para el caso.
  * El uso de bitácora de desarrollo, así como la gestión de la misma en conjunto con la importación y exportación de ésta (mediante los archivos install.xml, postinstall.xml, etc.), es de suma importancia a fin de poder sincronizar versiones a lo largo del tiempo (más de ésto luego).
  * En el caso de necesitar realizar replicación de changelog, es necesario conocer el concepto de Componente Temporal de Desarrollo, y lo que ésto implica a fin de facilitar la inclusión de los metadatos de un componente en el Core de Libertya.

===== Descargas Libertya =====

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.

===== Actualización de Instancia en desarrollo con modificaciones del Core =====

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:

  * Verificar las modificaciones/ampliaciones a incluir en el archivo **preinstall.sql** (cambios de base de datos a nivel SQL) para el período a contemplar en la actualización.  Este archivo se encuentra alojado en el directorio **/data/core/upgrade_from_XX.XX** de los fuentes, y cada sentencia SQL contiene un comentario con la fecha y hora de inclusión.  De esta manera podemos saber qué parte del script debemos incluir en el **preinstall.sql** del archivo .jar que estamos generando.
  * Crear una nueva base de datos y restaurar el dump descargado desde SourceForge (base de datos referencial con las nuevas modificaciones de CORE).  Sobre la misma realizar las siguientes actividades:
    * Verificar en la tabla **AD_Changelog** (la cual contiene la información para generar luego los archivos **install.xml** y **postinstall.xml**, los cuales contienen la información de cambios en base de datos a nivel metadatos Libertya), cuales son los nuevos registros para el componente CORE incorporados con respecto a los existentes en la base de datos del componente.  Esto se realiza:
        * La primera vez que se desea realizar una actualización de CORE: comparando el resultado de la ejecución del query: //select max(ad_changelog_id) from ad_changelog_dev where componentprefix = 'CORE'// en ambas base de datos.  Por ejemplo, si en la base de datos en desarrollo del componente este valor nos da **1.250.000**  y en la restaurada a partir del dump automático **1.250.400**, significa que deberemos exportar 400 registros. Si en ambas bases de datos se obtiene el mismo valor, significará que no ha habido cambios a nivel metadatos.
        * A partir de la segunda vez que se desea realizar una actualización de CORE: verificar el campo **Ultimo Changelog de Componente** en la ventana **Componentes Instalados** (perfil **System Administrator**) para el componente **CORE**.  Se deberá exportar entonces a partir del siguiente valor del allí indicado.  Por ejemplo si allí se indica **1.300.000**, significa que deberemos exportar a partir del cambio **1.300.001**. 
    * Probablemente se encuentre activa la bitácora de desarrollo de LY CORE, con lo cual primeramente será necesario desactivarla a fin de poder exportar los cambios.  Eso se realiza desde la ventana **Componentes**, bajo el perfil **System Administrator**.
    * Exportar el componente CORE mediante la funcionalidad **Exportar Componente** en el perfil System Administrator (la versión de componente a especificar dependerá de los registros de **AD_Changelog** a exportar, pero en términos generales debería ser siempre la versión más actual), e indicar el rango de **AD_Changelog_ID** a incluir en la exportación de una versión de componente dada. Siguiendo el ejemplo de actualización por primera vez, deberá indicarse en los parámetros de exportación como Changelog inicial el valor **1.250.001**.  Tildar además el check **Parche**, a fin de que posteriormente al momento de instalar la actualización, LY interprete la misma como una adición a una versión estable.
  * Pisar el archivo **preinstall.sql** autogenerado con las sentencias SQL obtenidas desde el archivo **prinstall_from_XX.XX.sql**. Con este archivo y los cambios en metadatos exportados a los archivos .xml, se debe generar el .jar (ver [[plugins:creacionjar|Creacion del archivo jar con componentes y metadatos]]) a utilizar en la actualización de la instancia de base de datos de desarrollo del colaborador.
 

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.
===== Incorporar las modificaciones de un componente al core de Libertya =====

==== Iniciando el desarrollo ====

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 ([[plugins:copiadechangelog|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:

  * Crear un branch (en función de lo acordado y especificado en la wiki) con respecto del trunk del proyecto.
  * Descargar y restaurar una instancia actualizada de la base de datos (via dump automatizado).
  * Detener la bitácora del componente CORE, crear el componente de desarrollo correspondiente e iniciar su bitácora.  
  * Implementar los cambios y ampliaciones correspondientes tanto en fuentes como en metadatos.  Recordar llevar el log de sentencias SQL ejecutadas, dado que será necesario posteriormente.
  * En caso de ser necesario, incorporar la eventuales modificaciones realizadas en el core sobre la base de datos de desarrollo del componente temporal, tal como se detalló previamente.

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.
==== Finalizando el desarrollo ====

Una vez finalizadas las actividades correspondientes a las modificaciones/ampliaciones por parte de un colaborador, se deberán realizar las siguientes actividades:

  * Generar el componente .jar de instalación con los cambios realizados en el componente temporal de desarrollo.  Para ésto se deben realizar las siguientes tareas (más información en [[plugins:creacionjar|Creacion del archivo jar con componentes y metadatos]]):
    * Detener la bitácora de desarrollo del componente
    * Exportar el componente (archivos install.xml, postinstall.xml)
    * Omitir el archivo preinstall.sql generado y “pisar” su contenido con el log de sentencias SQL que se fue llevando de manera manual.
    * Generar el instalador definivo en un archivo .jar.  De aquí se extraerá el changelog y se impactará en la base de datos de Core, replicándose además la bitácora de cambios.
    * Realizar una prueba de instalación del componente desarrollado, a fin de validar que no se presenten errores.  Obviamente, esta actividad deberá ser realizada sobre una base de datos distinta a la del desarrollo.
  * Dar aviso de la finalización del subproyecto.  De esta manera será posible:
    * Validar las modificaciones.
    * Realizar el merge correspondiente del branch hacia el trunk SVN.
    * Incorporar los cambios a nivel base de datos al core mediante el .jar de instalación.
    * Actualizar la wiki con el status actual del subproyecto
WikiLibertya

Herramientas de usuario

Herramientas del sitio

Herramientas de la página
