Nexus, gestión de artefactos … y otras especies

 ¿Cómo distinguir una pareja fantástica sobre la mediocridad? Por su coordinación, por esa conexión invisible que supera las fronteras de la percepción física. Mágicamente conectados, así os hará sentir nuestro invitado estrella de hoy Nexus para gestión de artefactos :

con nosotros, directamente desde la luna Sonatype …
Π ε Χ υ Σ
– ¡¡ e l   b i b l i o t e c a r i o !! –

NexusDSC

Su gran aliado nos lo presentó nuestro compañero Javier en otro artículo: Don Apache Maven, centrado en automatizar el ciclo de vida del software. Todavía nos resuena su contundente leitmotiv: “hacer un mal uso de Apache Maven™ requiere más esfuerzo que lo contrario“. Sin embargo, toda actividad ecoLógica se basa en las interacciones, las conexiones y esos son, sin duda, los dominios de Nexus.

Dominios en los que la especie más abundante son los artefactos software, imprescindibles pero indómitos en libertad y con una irrefrenable tendencia a reproducirse geométricamente. En la intimidad atienden también al nombre de librerías.

En la segunda parte de su artículo, Javier nos avanzaba cómo de enredados pueden ser los primeros pasos de un ciclo de desarrollo software solo con Apache Maven, sin utilizar Nexus. Ahora ya sabemos que habíamos caído en manos de … los Antipatrones:

• Desarrolladores que descargan directamente los artefactos desde los repositorios públicos de Maven.

Esta mala práctica penaliza con largos tiempos de descarga, sin contar las veces en que los repositorios públicos están caídos temporalmente y tenemos que esperar para resolver dependencias, sin poder trabajar (te sonará si trabajas con PrimeFaces ;).

En resumen: despilfarro de tiempo y ancho de banda considerable.

¡Glups! ¡Maven se está descargando internet!

• Desarrolladores que se pasan entre ellos los artefactos propietarios (los que no están en el punto anterior) a través de correos electrónicos (¡ay!), mensajería (¡brrr!), carpetas compartidas o incluso peor, pasando por el control de versiones (¡nooooo!). Para rematarlo, cuando ya los tienen hacen un “mvn install:file” con las coordenadas equivocadas (muy fácil, reconócelo, ocurre).

• Utilización del repositorio de código para almacenarlo todo. Simplemente os recordaré que el control de versiones no es nuestro espacio de respaldo y que no se deben subir los artefactos al mismo (engorda pero no alimenta, no es ecoLógico).

• Interminables entregas a producción, construyendo el binario desde cero, penando de módulo en módulo hasta construir el jar, war o ear.

El resultado es siempre una productividad lamentable, un consumo de recursos excesivo y serias dificultades para admitir mayores cargas de trabajo. Esta fábrica necesita un bibliotecario.

Mediante la incorporación de Nexus integramos una biblioteca de artefactos gestionados en nuestros procesos de fabricación software. Nuestro director de orquesta ha encontrado a su pareja perfecta, luce el sol sobre nuestro ecosistema.

La esencia de la aportación de Nexus es ofrecerse como intermediario cercano (“proxy de librerías“) y su constancia actualizando las copias locales de todos repositorios que contribuyen con artefactos a nuestro ciclo de desarrollo:

• Públicos (como Central, Codehaus, Java.net o Apache Snapshots entre otros)
• Privados (son los denominados “3rd party” como  Oracle, IBM, etc.)
• Propios (son tanto los artefactos puestos en producción -releases- como los intermedios -snapshots-)

Copia local Nexus de repositorios públicos

Creo que los beneficios por usar Nexus son masivos y hablan por sí mismos del efecto que tienen sobre nuestra productividad:

• Descargas más rápidas (gracias al “proxy” de librerías).
• Sensatez en la distribución de los artefactos (con aromas a colaboración, agilidad, centralización …).
• Posibilita el desarrollo modular, puesto que ya no necesito bajarme todos los fuentes para compilar el proyecto.
• Tenemos administración centralizada de artefactos a nivel de empresa, lo que permite realizar búsquedas o activar la autentificación y validación contra un directorio corporativo.

Por último,  como recortable, nuestro decálogo para la fabricación ecoLógica de software:

• Mantén controlada tu deuda técnica, es posible que en el futuro no seas capaz de pagar los intereses que genera  – Responsabilidad.
• No improvises … sistemáticamente,  consolida las reglas aplicadas – Institucionalización.
• Descarga a las personas de trabajos repetitivos – Automatización.
• Aprende y aplica lo que aprendes – Conocimiento reutilizable.
• Cuida la maquinaria, te va la vida – Clinker by Klicap – Sostenibilidad.

Seguimos queriendo aprender:

¿A ti también te han invadido los artefactos insaciables?
¿cómo has organizado las librerías?
¿qué proporción suponen las librerías públicas y de terceros sobre el total de tus desarrollos?
¿crees que consumimos almacenamiento por encima de nuestras posibilidades?

 

—————————————–