Diferencias

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

--- plugins:metodologiacolaboradores [2014/05/22 14:27]
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.
+Nota: Considerar de manera opcional a esta metodología el desarrollo de un [[plugins:microcomponents|microcomponente]].
 ===== 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).
-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.
@@ Línea 42: / Línea 43: @@
   * 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), 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**.
-    * 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, 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 =====
 ==== 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:
@@ Línea 62: / 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.
+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 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
     * 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.
@@ Línea 76: / Línea 92: @@
     * 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

Diferencias

Herramientas de la página