Seleccionando y utilizando un repositorio de artefactos privado: Nexus OSS

Imagen con repositorio y librerías

En este post vamos a tratar el tema de los repositorios de artefactos privados. Para ello, vamos primero a recordar lo que es un repositorio, la diferencia entre uno de código y uno de artefactos. A su vez, vamos a comparar las diferencias entre un repositorio público y uno privado así como los motivos por los que elegimos un repositorio privado. Terminaremos con las diferentes opciones que encontramos, el porqué hemos seleccionado Nexus OSS y también veremos un ejemplo de su uso con Maven.

Qué es un repositorio

Un repositorio es como una carpeta en la que almacenamos archivos de nuestro proyecto. En el caso concreto que trabajamos, es donde almacenamos los archivos compilados de las librerías que deseamos importar en otros proyectos, compartiendo así código entre estas de manera sencilla. También tiene la ventaja de poder decidir qué versión de la librería deseamos utilizar, pudiendo volver a una anterior en caso de que sea necesario.

Repositorio de código o de artefactos

Un repositorio de código es lo que todos conocemos, donde almacenamos nuestro código en remoto por seguridad, por poder compartirlo con otros o simplemente por buenas practicas. Ejemplos clásicos serían Github, Bitbucket o Gitlab. Un repositorio de artefactos, en cambio, es donde almacenamos archivos binarios o paquetes compilados derivados de nuestro código, como un archivo .aar de una librería Android, por ejemplo.

Público vs privado

Los repositorios pueden ser públicos o privados. La diferencia estriba en quién puede acceder a cada uno. Los repositorios públicos pueden ser accedidos por cualquiera, mientras que a los privados sólo pueden acceder aquellos usuarios que posean las claves de autenticación apropiadas. Uno nos permite compartir con el mundo, mientras que otro nos permite compartir solo con un grupo concreto de personas.

Motivos de elegir uno privado

Un repositorio privado nos es de gran utilidad cuando buscamos compartir código entre proyectos, pero no deseamos que ese código sea público. Aunque en general abogamos por el código abierto, en ocasiones, por requisitos del proyecto, podemos estar trabajando con código que no puede hacerse público. Si a esto sumamos que dicho código sea requerido en varios proyectos para el mismo cliente por ejemplo, nos vemos obligados a hacer uso de un repositorio privado para alojarlo.

Así mismo, puede utilizarse un repositorio privado junto a uno público, dado que tienen diferentes objetivos como indicábamos en el punto anterior.

Opciones

Existen muchas opciones a la hora de elegir un repositorio privado, pero se reducen notablemente si añadimos los requisitos de querer implementarlo en nuestra propia máquina y de tener acceso al código fuente, permitiéndonos realizar las modificaciones que creamos oportunas. A continuación se muestran las tres opciones que hemos considerado más apropiadas:

Artifactory OSSLogo JFrog Artifactory

Herramienta para la gestión de paquetes del ecosistema de JFrog. Sencillo de implantar. Puede implantarse mediante docker. Sólo soporta paquetes de Maven, Gradle e Ivy. Más datos aquí.

Nexus OSSLogo NexusOSS Sonatype

Es un producto de Sonatype para la administración de librerías de software. Sencillo de implantar. Puede implantarse mediante docker. Soporta Bower, Docker, Git LFS, Maven, npm, NuGet, PyPI, Ruby Gems, Yum, APT, Conan*, R*, CPAN*, Raw (Universal), P2*, Helm*, ELPA*, Go. Más información aquí.

GitlabLogo GitLab

Conocida herramienta utilizada como repositorio de código en su forma más básica, pero que incluye múltiples herramientas de DevOps en su interior. Integra herramientas como integración continua o gestor de incidencias, e incluye la opción de almacenar y distribuir paquetes de Maven y NPM, entre otros.

Elección: Nexus OSS

De las tres opciones anteriores, Nexus OSS parece la opción que nos ofrece un mejor equilibrio entre sencillez y número de tecnologías soportadas.

Ejemplo de uso: Maven

El soporte para Maven viene dado sin realizar ni una sola modificación adicional cuando instalamos Nexus OSS. Vamos a ilustrar cómo podemos exportar una librería Android a nuestro repositorio Nexus y cómo podremos importarla después en otro proyecto.

Exportar

Indicamos las credenciales necesarias para nuestro repositorio privado. Dado que vamos a introducir nuestras credenciales, nos interesa que el archivo no se publique junto con nuestro código en nuestro repositorio de código. Para ello, creamos en la carpeta raíz del proyecto una nueva carpeta nexus, y dentro de ésta, un archivo nexus.properties. En el nexus.properties que acabamos de crear introducimos el siguiente contenido:

No olvidemos añadir este archivo al .gitignore del proyecto.

En el build.gradle de la librería:

Una vez terminada la configuración, para publicar la librería solo es necesario abrir la terminal de Android Studio (junto al logcat y demás herramientas, generalmente en la parte inferior de la interfaz) y ejecutar gradlew upload:

Importar

Introducimos las credenciales necesarias para nuestro repositorio privado. Igual que en el ejemplo anterior, en el directorio raíz del proyecto añadimos una carpeta nexus y dentro de ésta un archivo nexus.properties con lo siguiente:

Una vez más, no olvidemos añadir este archivo al .gitignore del proyecto.

Indicamos dónde debe buscar la librería. En el build.gradle general del proyecto:

Indicamos la librería y la versión deseada de ésta. En el build.gradle del proyecto donde deseemos importar la librería:

Con esta configuración, la próxima vez que sincronicemos los archivos gradle la librería se importará y podremos hacer uso de ella.



¿Te gusta este post? Es solo un ejemplo de cómo podemos ayudar a tu empresa...

Queremos tu opinión :)