¿Cómo trabajar con el Repositorio de Artefactos asociado a la Plataforma Pre-Cloud?

Contenido

¿Por qué tengo que utilizar el repositorio de artefactos?

En la gestión de dependencias con un repositorio, se presentan una serie de retos que se deben tener en cuenta para poder gestionar con éxito su administración, si no, se puede caer en los siguientes problemas:

  • Anarquía e improvisación en la definición de repositorios
    • Existencia de repositorios dedicados por proyecto
  • Descontrol en la gestión de artefactos
    • Duplicidad de artefactos ¿Cuál es el bueno?
    • Ausencia de criterios para organizarlos
    • Idénticos artefactos con diferentes coordenadas
    • Artefactos subidos manualmente innecesariamente
    • No se respetan las coordenadas del fabricante
  • Problemas de licenciamiento de artefactos
    • Existencia de artefactos publicados cuya licencia no lo permite
    • ¿Porqué no se usan patrones de inclusión/exclusión?
  • Anarquía en el uso de Maven para modelar los pom.xml por parte de los proveedores

En nuestra instancia del repositorio, se ha realizado un esfuerzo para normalizar el uso y dar solución a los problemas anteriormente planteados:

  • Definición de una jerarquía de repositorios
    • Único punto de acceso a los artefactos
    • Localizar artefactos en diferentes repositorios
  • Clasificación de los artefactos
  • Extensión del procedimiento de subida de artefactos
    • Medidas de control
  • Definición de buenas prácticas de uso
    • No mezclar artefactos internos y de terceros en el mismo repositorio
    • Establecer una convención de coordenadas para artefactos internos
    • Gestión de dependencias
      • Especificar sólo las dependencias que se necesitan
      • Especificar el ámbito de aplicación de cada dependencia

Se espera, que con estas medidas, se minimicen los problemas asociados al uso de un repositorio, así como garantizar la reproducción sistemática de las compilaciones con los mismos resultados.

 

¿Cómo solicito una modificación en el repositorio de artefactos?

La administración funcional del repositorio de artefactos se realiza desde la Oficina de Impulso DevSecOps.

Para realizar cualquier modificación del mismo, ya sea una subida de un artefacto nuevo, solicitar la inclusión de un repositorio remoto o cualquier otra acción, se debe poner un ticket NAOS con la siguiente categorización:

  • Operación: Realizar petición
  • Servicio: DSO - Impulso DevSecOps
  • Componente: Soporte de las herramientas de apoyo DevSecOps
  • Elemento: (Sin determinar)

o puedes pulsar sobre el siguiente enlace directo para "Solicitar la subida de un Artefacto".

¿Qué tengo que poner en la petición si quiero subir librerías al repositorio?

Tienes que tener en cuenta que existen diferentes casuísticas:

Librería de tercero existente en repositorio público

Una librería de terceros, es toda aquella que no está desarrollada por el proyecto ni tampoco por ningún organismo del ámbito de la Consejería (aunque para el proyecto, sea una librería de terceros, tienen un tratamiento especial) que pueda existir en un repositorio público.

Para este caso, no se deberá subir la dependencia. Hay que indicar la URL del repositorio remoto en la que se encuentra, para poder resolver la dependencia a través del nuestro. La información se debe proporcionar en la plantilla que se facilita en el campo "Repositorio o URL descarga" y también se deben indicar las coordenadas (esto es, groupid, artifactid y versión) de la librería o librerías que interesa/n de dicho repositorio. Esto es debido a que se pueden establecer diferentes patrones de inclusión/exclusión en el repositorio para evitar posibles conflictos con otros.

Librería de tercero NO existente en repositorio público (o desconozco el repositorio)

En este caso, se debe cumplimentar en la plantilla la información con las coordenadas de la librería (groupid, artifactid y versión), así como toda la información que se pueda proporcionar en la plantilla, que puede ser:

  • Descripción: para qué se utiliza la librería, qué funcionalidad proporciona, etc. No tiene por qué ser exhaustivo. Simplemente una frase indicando la funcionalidad puede ser suficiente.
  • Licencia: Si se conoce el tipo de licencia, se indicará.
  • POM: Si se incorpora el pom de la librería o es autogenerado.

Se intentará localizar la librería en algún repositorio público, verificando que se trata de la misma. En dicho caso, se procederá a incluir dicho repositorio (puede aplicarse patrones de exclusión) como válido para la descarga de dependencias de terceros.

En caso de que se localice y al comparar, no coincidan los hashes para las mismas coordenadas, se pedirá confirmación al proyecto de cual utilizar. En caso de optar por utilizar la del repositorio remoto, se procederá a incluir el repositorio. En caso de optar por utilizar la proporcionada, se dará de alta en el repositorio de librerías de forma controlada.

En caso de que no se localizase, se dará de alta en el repositorio de librerías de forma controlada.

Librería existente en un repositorio de otro organismo de la Consejería

En este caso, se procederá de forma similar al caso "Librería de tercero existente en repositorio público", con la salvedad de que se aplicarán patrones de inclusión. Es decir, solo se traerán de dicho repositorio, las librerías que cumplan con el patrón de inclusión que se defina y que puede variar según si es:

Librería desarrollada dentro del ámbito de la Consejería

Se hace referencia a librerías que probablemente hayan sido desarrolladas en el marco de un Sistema de Información perteneciente a la Consejería, es decir, aquellas que tengan un groupID similar a:

  • es.juntadeandalucia.
  • es.jda.
  • es.ja.
  • etc

Para esta librería el patrón de inclusión será a nivel de groupID. Es decir, se incluirán todos los artefactos que compartan groupID.

Librería no desarrollada dentro del ámbito de la Consejería

Se hace referencia a librerías que probablemente NO hayan sido desarrolladas en el marco de un Sistema de Información perteneciente a la Consejería. Bien puede tratarse de una librería que se ha importado en su repositorio por alguna razón. 

Para esta librería el patrón de inclusión será a nivel de artefactID. Es decir, se incluirán todos los artefactos que compartan groupID:artifactID . Es decir, las diferentes versiones del artefacto en cuestión.

¿Qué pasa si incluyo algún otro repositorio adicional en mi pom.xml o configuración local?

Es posible que no se resuelvan algunas dependencias, ya que cuando el proyecto se intente compilar desde la herramienta de integración continua, la herramienta está configurada para hacer de "espejo" de cualquier repositorio especificado en el pom.xml, al repositorio de artefactos centralizado, por lo que cualquier otro repositorio no se tendrá en cuenta. Si es necesario incluir un nuevo repositorio para realizar la compilación, por favor, contacta con la Oficina de Impulso DevSecOps y solicita la inclusión tal y como se describe en el apartado ¿Cómo solicito una modificación en el repositorio de artefactos?

También van a existir verificaciones adicionales que tras la detección de un repositorio "no autorizado" en los pom.xml, pare los mecanismos de automatización, impidiendo continuar con la compilación del proyecto.

¿Qué pasa si no tengo visibilidad al servicio NAOS?

Dicha visibilidad tiene que ser solicitada al equipo de implantación NAOS, que es el encargado de gestionar la administración general en NAOS. Mientras se concede el acceso, para no demorar la petición, es posible enviar toda la información necesaria a la Oficina de Impulso DevSecOps.

El asunto del correo dependerá de la necesidad que se solicite:

  • Si necesitas subir un artefacto el asunto será: "[RepositorioArtefactos] Subir un artefacto".
  • Si necesitas actualizar un artefacto el asunto será: "[RepositorioArtefactos] Actualizar un artefacto".

En este último caso, el técnico procederá a crear la petición NAOS correspondiente y pondrá como interesado al solicitante (el remitente del correo) para que pueda estar informado de las actuaciones que se llevan a cabo.

Índice