Comprendiendo las estrategias disponibles para administrar los objetos de base de datos
Existen tres estrategias principales que se pueden adoptar para administrar los objetos del esquema de la base de datos que utiliza nuestra aplicación APEX.
El primer enfoque es la opción "completamente manual". Nosotros creamos y mantenemos los scripts SQL personalizados independientemente de la definición de la aplicación APEX. Ejecutamos nuestros propios scripts para crear tablas, vistas, triggers, paquetes y otros objetos en la primera instalación de nuestra aplicación, y para recrear o alterar adecuadamente los objetos existentes a medida que nuestro equipo entrega nuevas versiones de la aplicación para testers y usuarios de producción.
Con este enfoque, editamos los scripts SQL fuera del APEX Builder usando nuestro editor favorito y nos debemos asegurar de que se agreguen al repositorio de control de fuente del equipo.
La segunda forma es la opción "totalmente autónoma" que utiliza la función de Suporting Objects de APEX, en esta forma, definimos los scripts SQL de instalación, actualización y desinstalación como parte de la definición de nuestra aplicación APEX en el APEX Builder. En tiempo de instalación de la aplicación, APEX utiliza una consulta que nosotros proporcionamos para decidir si ejecutar los scripts de instalación o la secuencia de comandos de actualización. Los scripts se pueden ejecutar condicionalmente según una condición que nosotros configuremos.
Usando este enfoque los scripts se exportan junto con el resto de los artefactos del archivo de la aplicación APEX.
La tercera y más simple técnica es la opción "totalmente automatizada" que utiliza las características Liquibase de SQLcl que describo a continuación. SQLcl genera archivos XML que representan todos los objetos del esquema de nuestra base de datos y puede automáticamente actualizar una base de datos de destino para que sus objetos de esquema coincidan con las definiciones exportadas desde un entorno de origen.
Exportar objetos de esquema de base de datos usando SQLcl
Si bien el equipo puede estar más familiarizado con el mantenimiento de scripts SQL personalizados para instalar y actualizar las aplicaciones y objetos de esquema de base de datos, al menos debería ser consciente de lo que SQLcl podría estar haciendo automáticamente por ellos. SQLcl ofrece, por lejos, el enfoque más sencillo para exportar definiciones de objetos de esquema de base de datos y aplicar cualquier cambio a otros ambientes. SQLcl incluye funciones “Liquibase” mejoradas por Oracle para seguimiento, control de versiones e implementación de cambios en la base de datos.
Basado en un popular marco de seguimiento de cambios de código abierto, exportar todas las definiciones de objetos de la base de datos del esquema actual implican un simple comando lb generate-schema.
Al igual que con APEX, podemos emplear la opción -split para obtener un archivo separado para cada definición de objeto de base de datos, bien organizado en subdirectorios:
$ sql username/password@host:puerto/servicio
SQL> lb generate-schema -split
La ejecución de este comando produce un archivo de registro de cambios llamado controlador.xml en el directorio actual que actúa como una tabla de contenido para el resto de los archivos creados. Todos los demás archivos exportados se guardan en subdirectorios con el nombre del tipo de objeto de esquema de base de datos que representan.
Por ejemplo, ejecutar este comando en una aplicación APEX típica podría producir subdirectorios como table, sequence, ref_constraint, index, trigger, view, package_spec y package_body. Cada subdirectorio contendrá uno o más archivos de texto que describirán un objeto de esquema de un tipo similar.
Crear una utilidad apexexport2git personalizada
Por medio de un sencillo script al que llamaré apexexport2git que sirve para Mac, Linux y Windows podemos combinar la exportación apex y los comandos SQLcl lb generate-schema con creación de directorio, copia de archivos y el comando git add. Ese script exporta una aplicación APEX y sus definiciones de esquema de base de datos a un área de trabajo de Git con un solo comando.
Por ejemplo, para exportar la aplicación APEX 500 al área de trabajo de Git en el directorio greatapp, escribiría lo siguiente:
$ apexexport2git 500 /home/teamdev/greatapp username/password@host:puerto/servicio
La Figura 1 ilustra los seis pasos que realiza el script.
- El paso 1 crea un directorio provisional temporal y lo convierte en el directorio actual.
- Los pasos 2 y 3 usan SQLcl para ejecutar el comando de exportación apex para guardar definición de la aplicación APEX y el comando lb generate-schema para escribir las definiciones de objetos del esquema de la base de datos en el directorio actual.
- El paso 4 copia los artefactos de la aplicación APEX al área de trabajo de Git.
- El paso 5 copia los artefactos de objetos de la base de datos en un subdirectorio de base de datos en el área de trabajo de Git.
- El paso 6 le pide a git que agregue cualquier archivo que haya sido agregado, modificado o eliminado a la lista de trabajo para que puedan ser promovidos cuando sea el momento adecuado.
Figura 1: apexexport2git exporta una aplicación APEX y las definiciones de un esquema de BD a Git
Con un script como este, un miembro del equipo puede exportar fácilmente los artefactos de la aplicación APEX y los objetos del esquema de base de datos a un área de trabajo de Git en cualquier ciclo. Estos cambios pueden entonces ser confirmados a Git y enviados al repositorio permanente del equipo para convertirse en parte del registro histórico de progreso del equipo en la aplicación.
El equipo hará esto a demanda cuando se termine una serie de características o correcciones y permitir que sus compañeros de equipo en control de calidad para que puedan comenzar a realizar pruebas
Ver el historial de cambios de la aplicación
Con un repositorio Git como fuente de verdad para nuestra aplicación, es fácil obtener una vista panorámica de todos los cambios realizados al proyecto. Muchas herramientas son compatibles con Git y una particularmente popular es el editor gratuito Visual Studio Code.
Al instalar la extensión gratuita Git Graph, como se muestra en la Figura 2, podemos visualizar rápidamente el historial de todos los cambios realizados a nuestra aplicación.
Está organizado cronológicamente por transacciones confirmadas y un útil comentario proporcionado en el momento en que se realizó cada confirmación, esto permite ver qué errores y características se agregaron con el tiempo.
Haciendo clic en una confirmación particular, la expande para mostrar los archivos modificados como parte de ese elemento de trabajo.
Figura 2: Git Graph en VS Code mostrando el historial de Git para una aplicación APEX
Al hacer clic en cualquier nombre de archivo para cualquier confirmación, podemos ver fácilmente qué cambió el desarrollador en ese archivo. La Figura 3 muestra la pestaña de comparación de archivos de Visual Studio Code que se abre al hacer clic en el archivo p00003.yaml en la imagen anterior, una captura de pantalla de Git Graph para el mensaje de confirmación ampliado "Corrección a la consulta de predicción para utilizar valores reales del reclamo". Utiliza color para resaltar los cambios realizados en la declaración SQL relacionada con un informe clásico en la página 3 para implementar la visualización de una predicción de aprendizaje automático basada en datos reales de reclamos de seguros en lugar de los valores codificados que se utilizaban anteriormente.
Incluso si la página 3 ha sido modificada muchas veces desde que la funcionalidad relacionada con esta confirmación ha sido implementada, Git y Visual Studio Code cooperan para mostrar los cambios basados en la versión anterior de los metadatos tal como existían en el repositorio en el momento en que se realizó el cambio.
Figura 3: Diferencias Lado a Lado de la Página 3 del archivo YAML legible cambiado en una confirmación particular
Juntos, creamos las aplicaciones del futuro!
Mi nombre es José Preda.
* José es Analista de Sistemas e Ingeniero de Software con especializaciones en tecnologías de Oracle, Microsoft, redes, infraestructura tecnológica y gestión de recursos humanos. Posee más de 30 años de experiencia en el área de tecnología, es de Paraguay, vive y trabaja en San Luis, Argentina. Fue consultor, capacitador y soporte técnico para Base de Datos y herramientas de Oracle, desde el año 2013 es miembro activo del Grupo de Usuarios Oracle de Argentina del cual es miembro del directorio desde el año 2023. Es CEO de su propia Consultora: Soft San Luis, una startup especializada en brindar formación profesional, consultoría, mentoría y soluciones con tecnología Oracle y Oracle APEX a empresas, equipos de desarrollo de consultoras y a particulares. En 2024 ha sido reconocido como Oracle ACE Associate por la Corporación Oracle por sus contribuciones a la Comunidad de Usuarios de Tecnologías de Oracle
Comentarios
Publicar un comentario