Antes de comenzar me gustaría comentar que la palabra distribuible está entre comillas porque la RAE parece que no la reconoce, sin embargo, creo que mucha gente la usamos. Este pequeño post lo he clasificado dentro de las categorías Herramientas y Software QA que tengo definidas en mi blog. Lo que justifica este hecho es que hablaré de Apache Maven y sobre cómo mejorar ciertos procesos típicos en la vida de un proyecto software. Para ello hablaré de los “distribuibles”, empaquetados, ensamblados o como se quieran llamar a esas estructuras (comprimidas o no) de directorios y archivos que se usan dentro del marco tecnológico JAVA como son los JAR, WAR, AAR, EAR, etc.
En esas estructuras de directorios normalmente encontramos ficheros compilados (p.e, .class), archivos de propiedades (p.e, .properties), archivos de configuración (p.e, .xml), recursos gráficos (p.e, .png), metainformación (p.e, manifest.mf) y algunos otros más. Personalmente me gustaría destacar todos aquellos archivos que formen parte de la configuración de una aplicación. Las configuraciones más comunes son las referentes a la conexión de base de datos, sistema de correo, sistemas LDAP, etc.
Una muy buena aproximación para mejorar la facilidad de mantenimiento, automatización y personalización de estos “distribuibles” es usar Maven y sacarle partido a los distintos plugins que existen (packaging types / tools) y la gestión de perfiles. Con esto podremos conseguir generar el WAR de nuestra aplicación web configurado para el entorno de producción de nuestro cliente. Bastará con realizar un proceso como el siguiente:
- Realizar un export del sistema de control de versiones correspondiente a la versión que se desee, que entiendo que estará etiquetada en directorio tags de nuestro repositorio.
- Dar de alta un perfil con la configuración del entorno que nuestro cliente nos ha facilitado.
- Ejecutar algo similar a: mvn package -P oracle -Denv=client-dev
- Desplegar, manual o automáticamente, nuestro WAR (artefacto) donde corresponda.
Doy por supuesto que los miembros del equipo de desarrollo estarán muy familiarizados con la generación de estos distribuibles, sin embargo, son otros perfiles los que, durante el desarrollo del proyecto y/o tras su finalización, tendrán que continuar con su soporte, mantenimiento y evolución. Un ejemplo con el que muchos se pueden sentir identificados es el típico proyecto de llave en mano para un cliente que nos encarga algo a medida. En ese contexto, si el cliente nos demanda que le enviemos un SNAPSHOT para que su personal vaya haciendo pruebas, ¿Qué “distribuible” preparamos?
Es muy frecuente que si se trata de un proyecto software, haya sido un departamento, área o división de desarrollo quien nos haya realizado el encargo. Con esto quiero decir, que el perfil que va a recibir nuestro “distribuible” es probable que con unas simples instrucciones sea capaz de generar el “distribuible” apropiado a partir de un export del repositorio. Ahora bien, no basta con hacer un export, comprimirlo y enviarlo al cliente con las instrucciones, entre otras porque en el repositorio es muy probable que haya información sobre nuestros entornos de desarrollo, múltiples perfiles configurados o simplemente, información que no es útil para el cliente y que únicamente provoca ruido. Con lo cual, parece razonable pensar que vamos a necesitar un “distribuible” con las fuentes de nuestro proyecto que, acompañadas de una guía de instalación y configuración, permitan que el propio cliente pueda ir asumiendo estas tareas que tarde o temprano serán de su plena responsabilidad.
La opción planteada me parece lógica. El cliente nos demanda las fuentes del proyecto, nosotros se las entregamos con los archivos justos y precisos que necesitan para la configuración, pruebas unitarias/integración y la posterior generación del WAR, JAR, AAR o el que corresponda, que se desplegará en el entorno correspondiente.
Con la intención de dar un pasito más y pensando en los perfiles del departamento, área o división de infraestructuras, creo que agradecerán si les ahoramos hacer un export, tener instalado maven, tener instalado el JDK correspondiente y otros pequeños detalles que pueden hacer que algo fácil y mecánico, se retrase durante días. En prácticamente todas empresas e instituciones que conozco es el personal de sistemas o infraestructuras quien verdaderamente realizara los despliegues en los entorno de producción, por lo tanto, nos interesa facilitar al máximo las cosas.
Entiendo que para un administrador de sistemas le resultará más cómodo descomprimir un archivo comprimido (zip, tar.gz, etc.), editar el archivo de configuración que estará documentado en la correspondiente guía de la que antes hablaba y colocar la estructura de directorios y archivos en el lugar correspondiente para su despliegue. Este nuevo caso nos encontramos con que necesitamos preparar un “distribuible” con los binarios de nuestro proyecto.
Son muchas las circunstancias que puede hacer que el administrador del servidor de aplicaciones del cliente necesite volver a desplegar una aplicación determinada, como por ejemplo, cambios en la configuración de red, DNS, modificaciones en las credenciales (usuarios/contraseñas), migraciones, etc, ¿En todas esas situaciones es necesario que haya un desarrollador presente? Si las cosas se hacen bien, podemos ahorrarnos mucho trabajo. Tengo que reconocer que la realidad es otra, pero lo bueno es saber que existen otras formas de hacer las cosas.
Para concluir me gustaría añadir que aparte de lo que podamos generar en nuestra fase de empaquetado (package) y que además lo tenemos automáticamente con Maven, es muy recomendable preparar al menos otros dos “distribuibles” adicionales, uno con los fuentes y otro con los binarios. Para ello es de gran utilidad el plugin de Maven Assembly. Como me he extendido demasiado, aprovecharé otro post para poner algún ejemplo con este plugin. En Opina lo usamos para generar opina-bin-1.0.8.zip, que es el binario de la versión 1.0.8 de Opina que está listo para ser descargado, descomprimido, configurado y desplegado.
