Hoy retomo la serie de post de 10 min (como ¿Qué es Jenkins? Explicado en menos de 10 min para quienes no lo conocen de nada o Simplifica drásticamente la administración de sistemas: Puppet en 10 min.), pensada para que en muy poco tiempo te quedes con una idea básica y con los beneficios que hay detrás de cada una de estas herramientas.
En este caso, le toca el turno a herramientas como Nexus o Artifactory (que tienen versiones gratuitas y de pago) y son gestores de repositorios de Maven.
Maven y la gestión de librerías
Como ya comenté en Simple y rápido. Entiende qué es Maven en menos de 10 min, aunque solamos conocer a Maven por permitirnos compilar el código, esta herramienta hace muchísimas más cosas.
Algo en lo que también destaca Maven es en la gestión de las librerías.
Una librería es un conjunto de recursos, funciones, métodos, código ya implementado, que podemos reutilizar cuando desarrollamos software.
Cuando programamos, no reinventamos la rueda. Si podemos, tendemos a reutilizar código, recursos que nos ahorren tiempo y nos faciliten el desarrollo.
Así podremos centrarnos en otras cosas más difíciles y específicas de nuestra nueva aplicación.
Por ejemplo, lo típico es que necesitemos un sistema de logs para registrar los fallos que puedan surgir al ejecutar la aplicación y poder solucionarlos.
Esto es algo que se utiliza muy a menudo en todos los desarrollos software, y lo más común es que no nos interese programar un sistema de logs propio para nuestro software. En su lugar, podemos utilizar uno que ya esté hecho, probado y suela usar todo el mundo. Lo más probable es que haya alguna librería que implemente algo así y que podamos utilizar en nuestro software.
Puede que queramos también hacer pruebas unitarias. Y no nos vamos a poner a programar un framework, algo que nos permita crear y ejecutar las pruebas. Para eso ya tenemos a jUnit, y podemos incorporar esta librería a nuestro desarrollo.
Todo esto son ejemplos de librerías externas, que crean organizaciones, entidades, personas en todo el mundo.
No obstante, puede que dentro de nuestra propia organización haya algún código que tengamos que utilizar en varios proyectos, y sea recomendable transformarlo en una librería propia de la organización.
En lugar de tener que estar buscando e instalando manualmente las librerías para nuestros proyectos, con Maven podemos indicar en el pom.xml (el archivo de configuración de Maven para el proyecto) qué librerías necesita nuestro proyecto, y él se encargará de buscarlas para que podamos utilizar los métodos, recursos de esas librerías al programar, al compilar etc.
¿Y dónde busca Maven estas librerías? En los repositorios de librerías.
Si te fijas, cuando nos descargamos Maven, vemos que es una herramienta que ocupa muy poco espacio en disco para lo mucho que hace.
¿Dónde tiene Maven las librerías, dónde las busca? Para entender cómo gestiona Maven las librerías o incluso cómo compila, es bueno ver cómo se organiza, cuál es su arquitectura.
Maven se organiza a través de repositorios, donde van a estar esas librerías que hemos comentado antes.
En el esquema más simple de Maven tendríamos un repositorio local en cada ordenador donde tengamos instalado Maven (Maven se encarga de crearlo y gestionarlo) y un repositorio remoto y público, llamado Maven Central.
En Maven Central están almacenadas casi todas las librerías que puedas necesitar a la hora de desarrollar software.
Partiendo de esto, a la hora de compilar el código o cuando queramos utilizar (instalar) las librerías, Maven haría lo siguiente:
1 – En el pom.xml del proyecto, en la sección de dependencies, indicamos las librerías que usa nuestro proyecto y que están alojadas en Maven central.
2 – Cuando doy la orden de compilar el código o instalar las librerías, Maven buscará en mi repositorio local si están esas librerías. Si no están ahí, se irá a buscarlas al Maven central, las descargará e instalará en el repositorio local.
Luego compilará el código utilizando esas librerías de Maven central que están el repositorio local, o ya podremos usar los métodos que proporcionan en nuestro código.
Por ejemplo, la siguiente vez que Maven compile, hará el mismo proceso, pero será más rápido, porque al tener esas librerías instaladas ya en el repositorio local, no le hará falta descargarlas.
¿Y dónde entran herramientas tipo Nexus y Artifactory?
Como vemos, esto ya es muy útil y nos ahorra mucho tiempo y preocupaciones.
No obstante, pensando ya en una empresa, lo cierto es que no nos interesa estar dependiendo siempre de algo externo a la organización.
Y esto sobre todo, si queremos utilizar librerías propias de la empresa. En este caso, ¿qué hacemos? ¿Las subimos a Maven Central, permitiendo así que todo el mundo las use y las vea? ¿Las colgamos en un sitio para que cada desarrollador las vaya instalando como buenamente pueda? ¿Las subimos al control de versiones? ¡No, por favor!
Entre otras cosas, los gestores de repositorios como Nexus o Artifactory se utilizan para esto: no tener que depender de algo externo siempre y poder mantener controladas las librerías propias de la empresa.
Así, con un Nexus o un Artifactory, el esquema anterior pasaría a ser el siguiente:
En este caso, al compilar o usar las librerías, Maven primero buscará en el repositorio local, si no están ahí buscará en el Nexus y si no se irá a Maven Central y las instalará en el Nexus.
Las librerías propias de la empresa las subiremos directamente al Nexus.
Este tipo de repositorios también se utilizan como cachés. La idea de tener un Nexus o Artifactory, es que sean repositorios de librerías internos en la organización. Al estar en una red local, el acceso al Nexus será más rápido que tener que conectarme a Maven Central para descargar las librerías.
Además, ese Nexus es compartido por toda la organización, por todo el equipo de desarrollo.
En ese sentido, si alguien del equipo tiene que compilar el código, y ciertas librerías de Maven Central no están en el Nexus, su Maven hará que se descarguen e instalen esas librerías en Nexus.
Cuando otra persona vuelva a compilar el código, ya no tendrá que bajarse las librerías de Maven Central, porque el Maven de otro desarrollador ya lo hizo. Así también ahorramos tiempo.
Y otra cosa muy útil, si mi proyecto tiene muchas dependencias internas, es decir, cuando compilo este módulo se genera un artefacto que utilizo como base de la compilación de otro módulo etc.. Estos artefactos intermedios se guardarán en Nexus, permitiendo así, que otro desarrollador al compilar no tenga que volver a generarlos y su Maven pueda cogerlos de ahí.
¿Qué papel juegan estas herramientas en la integración continua?
Tanto herramientas como Maven, como tener gestores de repositorios, son elementos clave para la integración continua.
– En este caso, un gestor de repositorios como Nexus, acelera la compilación de Maven (por todo lo que ya hemos comentado, no tenemos que volver a invertir tiempo en bajarnos librerías de Maven Central, actúa como caché etc).
– Además, tenemos separado lo que es el código (en el control de versiones), de las librerías (tenemos un repositorio interno de la organización para gestionar librerías). ¡No caigas en la tentación de subir las librerías al control de versiones, no es para eso!
– Podemos utilizar gestores de repositorios como Nexus o Artifactory para guardar los artefactos finales de nuestra aplicación, para guardar los artefactos que desplegaremos a los diferentes entornos: testing, pre-producción, producción etc.
Así tendremos copias de seguridad, y tendremos control sobre qué artefactos están desplegados (recuerda el tema de la trazabilidad, muy importante).
– Se integran muy bien con servidores de integración continua, tipo Jenkins.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Pingback: Bitacoras.com
Muy interesante, gracias por esta informacion.
queria preguntarte, sin embargo, si le repo de Nexus es interno o externo. La explicacion da a entender que es externo, lo cual seria lo mas logico para evitar «publicar» nuestras librerias. Pero el grafico aun dice «externo a la organizacion», lo cual da a pensar que esta en la nube.
Podrias aclararme este punto por favor?
Saludos de un Argentino desde Alemania.
Un placer 😉
La idea es que el Nexus sea gestionado por la organización, para que las librerías no vayan directamente a Maven Central, no vayan pasándose de desarrollador a desarrollador, y se puedan almacenar los artefactos generados en las compilaciones en el Nexus.
Normalmente el Nexus se instala en un servidor interno de la organización, pero si la conexión es rápida, no veo problema en que el Nexus esté en la nube. Lo principal es que se gestione por la empresa.
Saludos
Genial el post, se entiende muy bien. Gracias y un saludo!
Hola buena noche!!
Pregunta… estoy investigando la relación entre nexus y BPMN…?
Muy bueno el post.. tengo una duda… esta arquitectura sirve para el ambiente de desarrollo.. pero como sería en un ambiente de producción en un servidor linux.. Se debe instalar maven y el repositorio.. para que los war ubiquen las librerías o como sería.. recien empiezo a trabajar con maven
HOla Leidy P., en un ambiente de producción ya llevas el componente compilado, el que o tiene las librerías dentro de paqueta (war o era en el caso de java), o estan compartidas y pre-instaladas en el servidor de aplicaciones.
Hola Leidy P., primero gracias por el artículo.
Me podrías ayudar? Es que estoy realizando un pipeline en Jenkins para el ambiente de producción con los siguientes jobs en orden:
1- Primer job del ambiente de producción se debe bajar el último artefacto exitoso del artifactory?
2- Después se podrían lanzar las pruebas unitarias?
3- Análisis de código mediante sonarqube.
4- Subir el artefacto exitoso
5- Despliegue en server
6- Pruebas de aceptación
Es correcto o le falta alguna información?
Cualquier ayuda o comentario será de gran ayuda.
Muchas gracias de antemano,
Ana te agradezco mucho tus post. Estoy empezando mis andanzas como desarrollador y todos éstos conceptos explicados de forma clara y conciza me ayudan mucho
Cordial saludo
Tengo una inquietud. Maven adicionalmente tambien lo podria configurar como repositorio central y acceder por scp, manteniendo un ambiente interno, propio de la organización, ¿cual es la ventaja de usar Nexus o Artifactory ? ¿seria lo mismo?
Muy buenos tus articulos. Tengo una duda, eun articulo anterior dices que todo debe estar cargado en el repositorio de codigo y mencionas librerias de 3ros. Aqui hace una acotacion que dice «¡No caigas en la tentación de subir las librerías al control de versiones, no es para eso!». Siento que te contradices o yo no estoy entendiendo correctamente. Muchas gracias por tus posts
¿Los compilados que se resguardan en Nexus pueden suplir la función del tag que se crea en SVN?
Gracias, muy buena información
Hola Jgarzas, muchas gracias por la información, me ha aclarado cosas.
Una pregunta, para que funcione la descarga de dependencias en ese orden, (local, nexus, maven central) habrá que configurar en cada equipo los settings.xml, es correcto?, o donde debemos hacer esto.
Gracias, un saludo.
Buena tarde, muchas gracias por la explicación, 10 de 10.