Integración Continua en Aplicaciones Web con Oracle ADF – Parte 1

Por Alexis Lopez Oracle ACE Associate
Publicado en Abril 2016

En esta serie de 5 artículos, introduciremos a los lectores al uso de la buena práctica de Integración Continua en aplicaciones Web desarrolladas con Oracle ADF.

En esta primera parte, hablaremos del marco de trabajo Oracle ADF, del concepto de integración continua, el por qué es necesario y presentaremos el diagrama de un ambiente de desarrollo que sigue esta buena práctica.

En las siguientes entregas hablaremos de cómo se integran todas las herramientas de nuestro ambiente de desarrollo.
> Ya puedes leer la segunda entrega de esta serie haciendo click aquí.

Acerca de Oracle ADF

Para quienes no lo conocen, Oracle ADF es un marco de trabajo para el desarrollo de aplicaciones Web usando tecnologías Java. A continuación algunas de sus principales características:

  • Sigue el patrón de arquitectura Modelo-Vista-Controlador (MVC)
  • Ha sido desarrollado sobre Java EE :
    • Versión 11g → JavaEE 5
    • Versión 12cR1 → JavaEE 6
    • Versión 12cR2 → JavaEE 7
  • Visual y Declarativo : Incluye muchas funcionalidades que no requieren codificación.
  • Interfaz de usuario moderna : Cuenta con 150+ componentes modernos.
  • Flujos de navegación avanzados (TaskFlows) que permiten definir el proceso a desarrollar.
  • Seguridad integrada.
  • Herramientas para desarrollo:
    • JDeveloper → Es la herramienta por defecto, incluye todas las características para trabajar con Oracle ADF de forma visual y declarativa.
    • Eclipse(OEPE) → Herramienta alterna, pero no incluye todas las funcionalidades para trabajar con Oracle ADF de forma visual y declarativa.

La versión actual, al momento de escribir este artículo, es ADF 12cR2 la cual incluye una actualización de tecnologías a Java EE 7, Java SE 8 y muchas otras funcionalidades importantes hoy en día, como la posibilidad de crear servicios tipo REST a partir de nuestro modelo. Sobre dicha versión trabajaremos a lo largo de esta serie de artículos.

Oracle ADF tiene un modelo de licenciamiento que se sale del alcance de este artículo, pero vale la pena mencionar que el desarrollo de aplicaciones que hacen uso de Oracle ADF es gratuito, porque JDeveloper se descarga gratuitamente e incluye un servidor Weblogic integrado en el que se puede probar el desarrollo. Es al momento de pasar de desarrollo a producción en donde hay que tener en cuenta el tema de licenciamiento.

Si el licenciamiento es un inconveniente, existe una versión de Oracle ADF que es gratuita tanto para desarrollar como para desplegar en ambientes productivos.

Acerca de Oracle ADF Essentials

Hace 3+ años se liberó una versión de Oracle ADF llamada Oracle ADF Essentials y desde entonces se ha mantenido al día con cada nueva versión que se libera de Oracle ADF. Esta versión es un subconjunto de las tecnologías clave de Oracle ADF, a saber:

  • ADF Faces → Librería que contiene los componentes para el diseño de interfaz de usuario.
  • ADF DvT → Librería que cuenta con componentes para la creación de gráficos (barras, tortas, etc.).
  • ADF Controller → Para la creación de flujos avanzados de navegación.
  • ADF Binding → Para enlazar las demás capas de la arquitectura MVC con el modelo.
  • ADF Business Components → Para mapear el modelo de base de datos.

Se dice que ADF Essentials es gratis para desarrollar y gratis para desplegar porque se desarrolla con JDeveloper y se despliega sobre el servidor de código abierto Glassfish.

En cuanto a los componentes que se quedan por fuera de este subconjunto, se encuentran: ADF Security, que maneja la seguridad de forma declarativa y otra funcionalidad que permite la creación de controles de datos a partir de servicios Web también de forma declarativa, pero lo anterior no quiere decir que no podamos implementar la seguridad o servicios Web programáticamente. Por otro lado, el servidor Weblogic ofrece más funcionalidades que el servidor Glassfish, especialmente en lo que respecta al despliegue de aplicaciones.

Acerca de Integración Continua

La integración continua es una práctica que requiere que los desarrolladores integren código al repositorio de código fuente lo más a menudo posible, luego, cada commit es compilado, probado y comprobado automáticamente por medio de varias herramientas, lo que permite detectar fallos cuanto antes y mejorar la calidad de nuestro código.

Entre los beneficios que se obtienen al usar dicha práctica se encuentran:

  • Ayuda a prevenir el paso de código defectuoso a ambientes productivos. Esto es debido a que cuando los desarrolladores integran su código a menudo y éste es probado y comprobado automáticamente, se reduce el riesgo de pasar código defectuoso a otros ambientes.
  • Permite analizar el estado y calidad del código.
  • Permite la automatización de esos procesos manuales que se repiten y repiten y que son propensos a errores humanos, como por ejemplo la construcción del archivo desplegable (ejecutable).
  • Aumenta la confianza del equipo a la hora de entregar el desarrollo, pues se conoce que cada prueba automatizada será ejecutada y los estándares de desarrollo serán comprobados automáticamente.

Desde el punto de vista de negocio, los beneficios se traducen en reducción de costos:

  • En algún momento el software deberá integrarse, entonces mientras más a menudo se integre, el tiempo de integración al final del proyecto será menor.
  • La detección de fallos es inmediata, por lo que se puede corregir más rápido. No quiere decir que no vayan a existir fallos, pero es menos costoso encontrar y solucionar un fallo durante el desarrollo, que cuando la aplicación se encuentra en otra fase.
  • Aumenta la visibilidad del estado del desarrollo, lo que se traduce en mejor comunicación entre negocio y desarrollo.

Para poder llevar a cabo la práctica de integración continua se requiere:

  • Cultura en el equipo de desarrollado para que se integre el código lo más a menudo posible.
  • Contar con un único repositorio de código fuente.
  • Automatizar la construcción y administración de dependencias.
  • Crear pruebas automatizadas.
  • Contar con un servidor de integración, en el cual se construya el software y se ejecuten sus pruebas automatizadas.
  • Contar con un repositorio en el cual se almacenen los últimos ejecutables y que sea de fácil acceso por todos los miembros del equipo.
  • Automatizar el proceso de despliegue de la aplicación.

Los anteriores requerimientos se satisfacen con el uso de un conjunto de herramientas que veremos más adelante en esta serie de artículos.

¿Por qué necesitamos la Integración Continua en aplicaciones Web desarrolladas con Oracle ADF?

En realidad la Integración Continua es necesaria en cualquier desarrollo de software independiente de la tecnología usada. Sin embargo, como es objeto de este artículo, hablaremos de la necesidad de contar con esta práctica en los desarrollos Web con Oracle ADF.

Existen diferentes arquitecturas para el desarrollo de aplicaciones Web usando este marco de trabajo y es una muy buena práctica conocerlas todas para determinar cuál de ellas se adapta mejor a nuestra aplicación. En el canal de YouTube de Arquitectura ADF se puede encontrar la definición, ventajas y desventajas de cada una de ellas y cuándo sería apropiado usarlas, este es un gran recurso que invitamos a revisar.

Una de las arquitecturas, comúnmente usada para aplicaciones de tamaño mediano-grande, es la denominada “Suma de todas las partes”. Para quienes no la conocen, en resumen, lo que propone es dividir la aplicación en diferentes “módulos” y luego crear una aplicación que los una a todos. Se tienen módulos comunes a todos los demás y módulos que se especializan en algunos procesos que son diseñados y desarrollados por medio flujos de trabajo cerrados (Bounded TaskFlows). De esta arquitectura se desprenden otras apropiadas para aplicaciones de mayor tamaño.

Cuando usamos la anterior arquitectura o una de sus derivadas en nuestras aplicaciones Web, vamos a encontrar una serie de dificultades con el paso del tiempo, entre las que se encuentran:

  • A medida que se crean/versionan los módulos, la administración de dependencias se vuelve compleja, es decir, qué proyecto usa cuál versión del módulo.
  • Las pruebas unitarias/integración/regresión de los módulos comienzan a requerir más tiempo y más recursos. Muchos fallos son encontrados en etapas posteriores a desarrollo.
  • Los estándares de calidad y desarrollo definidos para la aplicación son difíciles de verificar debido a que no es posible asignar recursos para que realicen solo esta tarea o no se cuenta con el tiempo suficiente para realizarla.
  • No es claro en dónde almacenar las librerías generadas de cada uno de los módulos de la aplicación: ¿Directorio compartido? ¿Repositorio de código fuente?
  • La creación del archivo “ejecutable” de la aplicación es un proceso propenso a errores humanos: ¿Tenemos la última versión de las librerías de los módulos? Puede que para algunos clientes se usen algunas librerías y no otras.
  • El despliegue de la aplicación en los servidores de los diferentes clientes puede ser dispendioso dependiendo de la cantidad de clientes.

La solución a muchos de los anteriores puntos se da al adoptar la práctica de Integración Continua en nuestras aplicaciones Web desarrolladas usando Oracle ADF. Esto es debido a que contaremos con herramientas que nos permitan automatizar:

  • Administración de dependencias de cada uno de los módulos.
  • Ejecución de las pruebas automatizadas.
  • Auditoría del código fuente para revisar mejores prácticas y estándares de desarrollo.
  • Creación de archivos “ejecutables”.
  • Despliegue de la aplicación a diferentes servidores.

Conclusión

En esta primera parte repasamos algunas de las características del marco de trabajo Oracle ADF y su versión gratuita Oracle ADF Essentials. Conocimos lo que significa la Integración Continua y analizamos lo beneficioso que puede ser el hacer uso de esta buena práctica en nuestras aplicaciones Web desarrolladas con Oracle ADF:

  • Para gestionar, automáticamente, la construcción y administración de dependencias de los módulos de la aplicación. Por lo que podremos contar con aplicaciones realmente modularizadas, en las que solo los módulos y versiones que especifiquemos harán parte de la aplicación final.
  • Para probar y comprobar, automáticamente, el código fuente por medio de pruebas automatizadas y auditoría de código. Lo que se traduce en un incremento de la posibilidad de encontrar fallos durante la etapa de desarrollo y una mejora en la calidad del código fuente.
  • Para automatizar el proceso de creación y despliegue de los archivos “ejecutables”. Reduciendo el riesgo de errores humanos y el tiempo requerido tanto para la creación como para el despliegue de éstos.

En las siguientes entregas nos enfocaremos en analizar cada uno de los puntos del siguiente gráfico y sus relaciones para que entendamos cómo interactúan todas las herramientas en un ambiente de Integración Continua:

integracion continua ADF


Información Adicional

Los siguientes enlaces ofrecen mayor información y profundidad respecto a este tema:

Desarrollando Aplicaciones con Integración Continua: https://docs.oracle.com/middleware/1212/core/MAVEN/toc.htm

Oracle ADF (en inglés): http://www.oracle.com/technetwork/developer-tools/adf/overview/index.html

Oracle ADF Essentials (en inglés): http://www.oracle.com/technetwork/developer-tools/adf/overview/adfessentials-1719844.html

Oracle JDeveloper (en inglés): http://www.oracle.com/technetwork/developer-tools/jdev/overview/index-094652.html

ADF Architecture TV (en inglés): https://www.youtube.com/user/adfarchtv

Glassfish para ADF Essentials (en español): http://www.acelopez.com/oracle-adf/glassfish-para-adf-essentials/


> Ya puedes leer la segunda entrega de esta serie haciendo click aquí.

Alexis Lopez (@aa_lopez) es consultor independiente Java/ADF/BPM. Ha sido profesor universitario de cursos relacionados con tecnologías Java y conferencista en congresos reconocidos como: Oracle Open World, JavaOne, Campus Party y OTN Tour. Cuenta con un título de ingeniero de sistemas y las siguientes certificaciones y reconocimientos: Oracle Ace Associate, OCP Java 8, OCPJMAD, OCPWCD, especialista de implementación de Oracle ADF y Oracle BPM. Es líder del grupo de usuarios Java de Cali-Colombia (www.clojug.org), miembro del comité de dirección del grupo de usuarios virtual de Java (virtualjug.com) y blogger activo en www.acelopez.com

Este artículo ha sido revisado por el equipo de productos Oracle y se encuentra en cumplimiento de las normas y prácticas para el uso de los productos Oracle.