Integración Continua - Parte 1

Integración Continua

Vamos sin rodeos. Hace un buen rato que no escribía una entrada en el blog. Así que vamos al grano. En la siguiente serie de entradas, me ocuparé de un tema muy interesante (al menos para mi): Integración Continua.

Les parecerá un tópico normal, seguramente en los últimos años/meses han escuchado mucho de esto. Pero, ¿en realidad han tenido alguna relación directa con un algún ambiente de integración continua? Hasta hace algunos meses, yo no. Quizá en alguno que otro experimento, tras bambalinas, pero no de manera directa.

Oracle. "Es el producto que yo manejo", se diría por ahí (1). Así que exploraremos algunos conceptos básicos y una serie de herramientas que podrían ayudar a desplegar un entorno de integración continua, para Oracle Fusion Middleware.

Servicios y Microservicios: SOA

Como ésta entrada no está dedicada a discutir si los microservicios reemplazan a SOA, ni tampoco a determinar si SOA es el padre de los microservicios, vamos a centrarnos en la forma en que se construye (típicamente) una aplicación.

En la mayoría de los proyectos en que hemos participado existen pequeños grupos de personas, que en conjunto hacen un equipo de trabajo completo. Cada uno de esos grupos realiza una tarea definida, trabaja en el ámbito en el que está especializado: administración del proyecto, desarrollo (cualquier tecnología), pruebas, infraestructura, soporte y demás. Así cada equipo colabora con una pequeña parte del proyecto, para al final construir una aplicación integral en la que conviven todas las piezas. ¿Les suena esto en donde cada quien hace un pedazo de todo el trabajo? ¿Servicios? ¿SOA? Acordamos no hablar de eso, sigamos.

Agilidad

Otro concepto que hemos escuchado mucho es el de la agilidad. Aquí es donde comienza a tener importancia la metodología que utilizamos para implementar un proyecto de software. Lo sentimos por aquellos que se identifican con la metodología en cascada, pero desde mi punto de vista eso ya quedó atrás. Muchos años atrás.

Las metodologías ágiles nos ayudan a implementar estrategias iterativas que permiten descubrir errores en etapas más tempranas del proyecto. Por lo tanto, podemos corregirlos de manera anticipada y durante cada iteración, también podemos incluir funcionalidad nueva que haga que el desarrollo sea incremental.

Una parte fundamental de ser ágil es: el negocio cambia constantemente. ¿Qué tan constantemente? Tal vez les suene que a la mitad de los proyectos o, incluso, ya prácticamente cuando se encuentran desplegando sus componentes, al usuario se le ocurre cambiar alguna regla o definición de negocio. O varias.

Entre más pequeñas sean las piezas que construimos y más rápido las pongamos en pruebas, validación y operación, la vida se vuelve mucho más simple. Podemos agregar, modificar o eliminar funcionalidad de acuerdo a las nuevas necesidades. Una vez por año, una vez por mes. Quizá una vez por día. Al usuario eso no le interesa, su interés se centra en qué tan rápido ve funcionando el producto que solicitó.

¿Se imaginan generar un JAR, WAR, EAR, EXE, o cualquier cosa que ustedes generen, una vez al día? ¿Desplegarlo, probarlo, validarlo, monitorearlo y dar soporte a la producción? Ahora imaginen eso, multiplicado por las decenas o cientos de componentes que generaron. Quizá justo en este momento quieran darle una oportunidad al concepto de integración continua.

Concepto

El concepto de libro es el siguiente: la integración continua es una práctica de la ingeniería de software enfocada en mejorar la calidad y reducir el tiempo de entrega de una pieza de software. Esto se logra aplicando pequeños pero frecuentes esfuerzos en el control de la calidad. Uno de los fines de la integración continua es ayudar a las organizaciones a automatizar despliegues y pruebas de los componentes desarrollados.

Prácticas clave

Para lograr establecer un entorno de integración continua, es necesario llevar a cabo una serie de prácticas clave:

1. Un control de versiones que es utilizado para dar seguimiento a los cambios.
2. Los desarrolladores realizan commit hacia el control de versiones todos los días.
3. El producto (build) es realizado después de cada commit.
4. El build debe ser automático.
5. El despliegue debería ser automático hacia los ambientes de desarrollo, pruebas y producción.
6. Las pruebas del producto deberían estar automatizadas.
7. Los resultados del build deben ser públicos, de esta manera cualquier persona podrá enterarse cuando sus cambios son incorrectos e impiden que el build se complete de manera satisfactoria.
8. Los entregables deben estar disponibles para desarrolladores, equipo de pruebas y cualquier otro stakeholder del proyecto.

Soporte de integración continua, Oracle

Como mencionamos en un principio, esta serie de entradas se centrará en tecnología Oracle. ¿Cómo Oracle soporta un entorno de integración continua?

1. Oracle JDeveloper se integra con los sistemas de control de versiones más comunes.
2. Capacidad de realizar el build desde la línea de comandos usando Maven, así el build puede ser automatizado.
3. Capacidad de crear nuevos proyectos usando los arquetipos de Maven.
4. Capacidad de descargar las dependencias de los repositorios de Maven.
5. Capacidad de parametrizar los scripts, así los builds pueden ser desplegados hacia varios entornos (desarrollo, pruebas, producción).
6. Capacidad de incluir pruebas de los proyectos en el ciclo de vida de Maven.
7. Capacidad de poblar el repositorio de Maven con dependencias de Oracle desde un directorio de instalación de productos de Oracle (Oracle Home).
8. Capacidad de gestión de los builds con servidores de integración continua (como Hudson).

Componentes de integración continua

En el mercado hay disponibles un buen número de opciones tecnológicas para la implementación de un entorno de integración continua. Algunos de estos componentes pueden ser de uso gratuito (open source) y algunos otros pueden ser productos comerciales. Para nuestro ejemplo vamos a usar lo siguiente:

1. Apache Subversion como sistema de control de versiones.
2. Apache Maven para creación y automatización de los builds.
3. Apache Archiva como administrador del repositorio de Maven.
4. Apache Hudson como servidor de integración continua.

Apache Subversion

Un control de versiones funciona como repositorio de artefactos de código. A este repositorio tienen acceso los desarrolladores usando un cliente de Subversion. Los equipos de desarrollo pueden copiar artefactos desde y hacia el repositorio. El control de versiones lleva un registro de quién y qué ha cambiado en los artefactos de código (aquel que rompa el build, deberá pagar el desayuno del día siguiente).

• Se integra de manera natural con JDeveloper.
• Soporta distintas opciones de autenticación, incluyendo la autenticación vía un certificado.
• Funciona bien en entornos de red.
• Para proyectos de Oracle SOA Suite, provee de commit atómico, que permite actualizar varios archivos como parte de un mismo commit.

Apache Maven

Maven es un sistema de administración de proyectos y builds. Tiene capacidades de administración de proyectos (no piensen en MS Project, por favor) en términos de:

• Nombrado y versionamiento.
• Dependencias.
• Ubicación del código.
• Ubicación de los builds.
• Plantillas de proyectos.
• Proceso de liberación.

También tiene capacidades de administración de builds en términos de:

• Cómo ejecutar el build.
• Pasos a realizar en cada fase.
• Parametrización del build.
• Extensión del framework.

Una instalación típica de Maven consiste de la instalación de Maven en la máquina de cada desarrollador, un repositorio de Maven compartido al interior de la organización y múltiples repositorios públicos de Maven donde están almacenadas las dependencias. Estos repositorios públicos almacenan librerías que pudieran ser usadas como dependencias en el desarrollo de nuestros proyectos.

Apache Archiva

En ocasiones nos viene a la mente ¿por qué usar un administración de repositorios de Maven? La respuesta a esto es que algunas organizaciones encuentran útil tener un repositorio interno de Maven. Las razones pudieran ser las siguientes:

• Actuar como intermediario o caché de repositorios externos. Así el repositorio central (interno) descargaría las dependencias una única vez y las almacenaría en caché para que los desarrolladores las puedan utilizar.
• Para almacenar los artefactos que se desarrollen al interior de la organización y que estos puedan ser compartidos con otros equipos de desarrollo o proyectos.

Apache Hudson

Hudson es un servidor de integración continua muy utilizado y nos ayudará a automatizar el proceso de creación de builds. Los pasos que se contemplan en la automatización pueden ser los siguientes:

• Iniciar el proceso de build siempre que un desarrollador realice un commit hacia el sistema de control de versiones.
• Descargar el código del sistema de control de versiones.
• Compilar el código.
• Ejecutar pruebas unitarias.
• Empaquetar el código en un archivo con formato de despliegue (JAR, por ejemplo).
• Desplegar el archivo hacia un ambiente de ejecución.
• Ejecutar pruebas de integración.
• Enviar notificaciones ante fallas en el proceso.

Resumen

En la primer entrada de esta serie, hemos explorado algunos conceptos, beneficios y necesidades que se cubren al implementar un entorno de integración continua al interior de una organización.

Se ha dado un breve resumen de lo que cubriremos en las siguientes entradas del blog, para mostrar cómo un entorno de integración continua nos proporciona capacidades de automatización de builds, administración del código, documentación, automatización de pruebas, despliegue hacia distintos entornos (desarrollo, pruebas, producción), entre otras.

Vamos a usar tecnología de Apache para: control de versiones (Subversion), administración de proyectos y builds (Maven), administración de repositorios de Maven (Archiva) y servidor de integración continua (Hudson).

Citas

(1) Gerardo "Ellera" Nieves