WikiLibertya

Herramientas de usuario

Herramientas del sitio

Traza:
plugins:metodologiacolaboradores

Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

Ambos lados, revisión anterior Revisión previa
Próxima revisión 		Revisión previa
plugins:metodologiacolaboradores [2014/05/22 14:36]
fcristina [Actualización de Instancia en desarrollo con modificaciones del Core] 		plugins:metodologiacolaboradores [2021/11/10 15:48] (actual)
fcristina [Introducción]
Línea 6: Línea 6:
  
 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.   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 ===== ===== Requisitos =====
Línea 22: Línea 24:
 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). 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 (http://libertya.org/wiki_dev/doku.php), 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.+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 ahora con el repositorio público SVN del proyecto Libertya en Google Code (http://code.google.com/p/libertya/) correspondiente a los fuentes LY.  Los fuentes del Core de Libertya se encuentran alojados en https://libertya.googlecode.com/svn/trunk/.  +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/.  
  
-Esta división de descargas de archivos por un lado y repositorio SVN por otro se fundamenta en que ambos servicios presentan cada uno una serie de ventajas y desventajas, por lo que se buscó lograr el escenario más favorable en cada caso. 
  
 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. 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.
Línea 44: Línea 45:
     * 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:     * 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.         * 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**).  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**. +        * 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**.     * 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.     * 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, el cual se instala simplemente desde la opción **Instalador de Componentes** (perfil **System Administrator**), y seleccionando el .jar 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 con todas las modificaciones realizadas por el colaborador en su componente.+  * 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 ===== ===== Incorporar las modificaciones de un componente al core de Libertya =====
  
 ==== Iniciando el desarrollo ==== ==== 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.  Dicha información será volcada en la wiki de Google Code (http://code.google.com/p/libertya/wiki/Branches).+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.  
  
-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 (http://libertya.org/wiki_dev/doku.php?id=plugins:copiadechangelog), el cual es descartado cuando la funcionalidad (fuentes + cambios en bbdd) son incorporados al core.+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: Para ésto, se deberán realizar los siguientes pasos:
Línea 64: Línea 72:
   * 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.   * 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 ==== ==== 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: 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 http://libertya.org/wiki_dev/doku.php?id=plugins:creacionjar):+  * 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     * Detener la bitácora de desarrollo del componente
     * Exportar el componente (archivos install.xml, postinstall.xml)     * 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.     * 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.     * 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:   * Dar aviso de la finalización del subproyecto.  De esta manera será posible:
     * Validar las modificaciones.     * Validar las modificaciones.
Línea 78: Línea 92:
     * Incorporar los cambios a nivel base de datos al core mediante el .jar de instalación.     * 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     * Actualizar la wiki con el status actual del subproyecto
- 
plugins/metodologiacolaboradores.1400769419.txt.gz · Última modificación: 2021/04/30 19:21 (editor externo)

Herramientas de la página

Excepto donde se indique lo contrario, el contenido de este wiki esta bajo la siguiente licencia: CC Attribution-Noncommercial-Share Alike 4.0 International
CC Attribution-Noncommercial-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki