| Ambos lados, revisión anterior
Revisión previa
Próxima revisión
|
Revisión previa
|
plugins:metodologiacolaboradores [2014/05/22 14:23]
fcristina [Requisitos] |
plugins:metodologiacolaboradores [2021/11/10 15:48] (actual)
fcristina [Introducció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. | 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 ===== |
| 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. |
| * 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. | * 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: | * 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), los nuevos registros para el componente CORE incorporados con respecto a los existentes en la base de datos del componente. Esto lo podemos hacer 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 replicar 400 registros. Si en ambas bases de datos se obtiene el mismo valor, significará que no ha habido cambios a nivel metadatos. También es factible evaluar las diferencias basándonos en el período que queremos abarcar, verificando la fecha de creación de los registros en esta tabla. | * 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**. | * 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 correspondiente 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, 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. |
| * Con las sentencias SQL incluidas en el archivo .sql “truncado” (ignorar el preinstall.sql que genera el exportador) y los cambios en metadatos exportados a los archivos .xml, se debe generar el .jar (ver http://libertya.org/wiki_dev/doku.php?id=plugins:creacionjar) 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: |
| * 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. |
| * 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 |
| |
